5 ms·

Looking at the limitations, I hate how fragmented Linux is becoming for apps like this. Completely separate implementations for: - X - Wayland + Gnome Shell

Looking at the limitations, I hate how fragmented Linux is becoming for apps like this. Completely separate implementations for: - X - Wayland + Gnome Shell - Wayland + wlroots-based compositor - Wayland + sway or any other non-wlroots based compositor Is Wayland really that much better that this is worth it? Why can't Wayland be aware of the compositor like X?

alrlroipsp 4y ago
There's XWayland for interop. Besides that, people have been moving away from X11 for years now.
- ranguna 4y ago
  I still question myself as to why
  - bogwog 4y ago
    Have you actually used Wayland? Besides the obvious current issues (compatibility and/or missing features), it is way better. Even something as simple as moving and resizing windows feels noticeably faster and more responsive on Wayland compared to X. I don't use it at the moment because of compatibility issues with some software that I use, but that's not Wayland's fault.
    - NhanH 4y ago
      > Besides the obvious current issues (compatibility and/or missing features) I mean, that's the whole biggest criticism of wayland, 15 years in and it still doesn't work (well?) with the biggest GPU brand. The criticism has always been about whether it is worth it to fragment linux land and throw away a few decades worth of work on X.
      - deleted 4y ago
        [deleted]
      - qu4z-2 4y ago
        My criticism of Wayland has always been that they dropped a spec, forgot to make an actual server, and now every window manager needs to implement support for various extensions separately. It's a fine design if you assume everyone only uses Gnome, but... It's not just throwing away a decade's worth of work on X, it's making everyone redo that work per display manager (thankfully wlroots exists as a kind of Wayland shared library).
dottedmag 4y ago
This is growth pains. Once the the need is understood well enough, a common extension will be written, and Mutter, KWin and sway/wlroots will implement it. This is better for security than X11 free-for-all.
- eptcyka 4y ago
  I agree that Wayland by design can be more secure - but judging from my personal threat model, if malicious code gets to attack X or Wayland, it's already all over.
- yjftsjthsd-h 4y ago
  > a common extension will be written, and Mutter, KWin and sway/wlroots will implement it. Like how they standardized nice simple things like taking a screenshot?
  - dottedmag 4y ago
    https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...
- asveikau 4y ago
  Isn't the use case of apps injecting mouse and cursor events the "security free for all" that Wayland is trying to prevent? Full disclosure, I am a Wayland skeptic. I don't think your focus on X input security is as justified as you probably think.
  - dottedmag 4y ago
    If it is implemented it will most likely go through the xdg-desktop-portal, with a policy controlled by compositor. And most likely it won't be injection of mouse and cursor events, but something higher-level, like focus switching requests.
    - asveikau 4y ago
epse 4y ago
Wait is there a separate implementation for sway and other wlroots? Because sway is wlroots based, that's where wlroots originates?
- awestroke 4y ago
  I might be wrong about Sway not being wlroots based. But there are a lot of compositors that are not based on wlroots
  - yjftsjthsd-h 4y ago
    Yeah, sway is wlroots. But GNOME and KDE are both doing their own thing, so the point is in generally perfectly valid.
vidarh 4y ago
Personally I don't think Wayland will get to a good spot until one compositor "wins" and provides interfaces for modification/extension such as e.g. X-like ability to write window managers without replacing the whole compositor. At this point I see no compelling reason to switch to Wayland for my own part.
TheCycoONE 4y ago
Where were you seeing that. I only glanced through a handful of files, but it appears to be one implementation for me: https://github.com/rvaiya/warpd/tree/master/src/platform/wayland https://github.com/rvaiya/warpd/tree/master/src/platform/way... If there is a distinction, and there might be, "completely separate" is exaggerating. Edit: I see that only wlroot based implementations are supported so far, and of those there are some things broken in wayfire. Perhaps this is what you're referring to?
- awestroke 4y ago
  The wayland implementation does not support Gnome Shell on wayland (arguably the most mainstream combo since it's the default in ubuntu). To support Gnome Shell on Wayland, you need to include a Gnome Shell extension which has some headaches. X is a third implementation. And then there is one additional implementation per Wayland compositor that is not based on wlroots
  - TheCycoONE 4y ago
    Not a full and completely separate implementation though. Just wrappers to mask differences in compositor extensions that haven't been stabilized yet. If there are none the implementation is simply impossible.
3np 4y ago
You can reduce that list from 4 to 3 (sway and others use wlroots. GNOME is the one weird out in Wayland)
- yjftsjthsd-h 4y ago
  Eh. Sway uses wlroots, but KDE is a completely different option that they didn't list so it comes out in the wash.

alrlroipsp 4y ago

There's XWayland for interop. Besides that, people have been moving away from X11 for years now.

ranguna 4y ago
I still question myself as to why
- bogwog 4y ago
  Have you actually used Wayland? Besides the obvious current issues (compatibility and/or missing features), it is way better. Even something as simple as moving and resizing windows feels noticeably faster and more responsive on Wayland compared to X. I don't use it at the moment because of compatibility issues with some software that I use, but that's not Wayland's fault.
  - NhanH 4y ago
    > Besides the obvious current issues (compatibility and/or missing features) I mean, that's the whole biggest criticism of wayland, 15 years in and it still doesn't work (well?) with the biggest GPU brand. The criticism has always been about whether it is worth it to fragment linux land and throw away a few decades worth of work on X.
    - deleted 4y ago
      [deleted]
    - qu4z-2 4y ago
      My criticism of Wayland has always been that they dropped a spec, forgot to make an actual server, and now every window manager needs to implement support for various extensions separately. It's a fine design if you assume everyone only uses Gnome, but... It's not just throwing away a decade's worth of work on X, it's making everyone redo that work per display manager (thankfully wlroots exists as a kind of Wayland shared library).

dottedmag 4y ago

This is growth pains. Once the the need is understood well enough, a common extension will be written, and Mutter, KWin and sway/wlroots will implement it. This is better for security than X11 free-for-all.

eptcyka 4y ago
I agree that Wayland by design can be more secure - but judging from my personal threat model, if malicious code gets to attack X or Wayland, it's already all over.
yjftsjthsd-h 4y ago
> a common extension will be written, and Mutter, KWin and sway/wlroots will implement it. Like how they standardized nice simple things like taking a screenshot?
- dottedmag 4y ago
  https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...
asveikau 4y ago
Isn't the use case of apps injecting mouse and cursor events the "security free for all" that Wayland is trying to prevent? Full disclosure, I am a Wayland skeptic. I don't think your focus on X input security is as justified as you probably think.
- dottedmag 4y ago
  If it is implemented it will most likely go through the xdg-desktop-portal, with a policy controlled by compositor. And most likely it won't be injection of mouse and cursor events, but something higher-level, like focus switching requests.
  - asveikau 4y ago

epse 4y ago

Wait is there a separate implementation for sway and other wlroots? Because sway is wlroots based, that's where wlroots originates?

awestroke 4y ago
I might be wrong about Sway not being wlroots based. But there are a lot of compositors that are not based on wlroots
- yjftsjthsd-h 4y ago
  Yeah, sway is wlroots. But GNOME and KDE are both doing their own thing, so the point is in generally perfectly valid.

vidarh 4y ago

Personally I don't think Wayland will get to a good spot until one compositor "wins" and provides interfaces for modification/extension such as e.g. X-like ability to write window managers without replacing the whole compositor. At this point I see no compelling reason to switch to Wayland for my own part.

TheCycoONE 4y ago

Where were you seeing that. I only glanced through a handful of files, but it appears to be one implementation for me: https://github.com/rvaiya/warpd/tree/master/src/platform/wayland https://github.com/rvaiya/warpd/tree/master/src/platform/way... If there is a distinction, and there might be, "completely separate" is exaggerating. Edit: I see that only wlroot based implementations are supported so far, and of those there are some things broken in wayfire. Perhaps this is what you're referring to?

awestroke 4y ago
The wayland implementation does not support Gnome Shell on wayland (arguably the most mainstream combo since it's the default in ubuntu). To support Gnome Shell on Wayland, you need to include a Gnome Shell extension which has some headaches. X is a third implementation. And then there is one additional implementation per Wayland compositor that is not based on wlroots
- TheCycoONE 4y ago
  Not a full and completely separate implementation though. Just wrappers to mask differences in compositor extensions that haven't been stabilized yet. If there are none the implementation is simply impossible.

3np 4y ago

You can reduce that list from 4 to 3 (sway and others use wlroots. GNOME is the one weird out in Wayland)

yjftsjthsd-h 4y ago
Eh. Sway uses wlroots, but KDE is a completely different option that they didn't list so it comes out in the wash.