10 ms·

If Wayland is the future, the future is grim. People often complain that Wayland is taking a long time to catch up to X11, but that actually stems from a deeper

by nsajko 6y ago

If Wayland is the future, the future is grim. People often complain that Wayland is taking a long time to catch up to X11, but that actually stems from a deeper issue: Wayland has a horrible design, for an X11 replacement, a design that leads to massive fragmentation issues across the graphical part of the Linux ecosystem. Implementing a Wayland compositor requires much more effort than implementing an X11 window manager and each new compositor implementation reinvents the wheel many times, leaving users with less options for a desktop environment than on X11. Even worse, Wayland does not standardize on or is hostile to some essential features, meaning that users need to rely on compositor specific behavior for those features, if they are even available. E.g., an application that needs to grab the entire screen will need separate code for each compositor it supports screenshots on, or it must use a protocol outside Wayland to get the screenshot. Quoting Red Hat: > Furthermore, there isn’t a standard API for getting screen shots from Wayland. It’s dependent on what compositor (window manager/shell) the user is running, and if they implemented a proprietary API to do so. An xdotool (an input event automation tool, imagine wanting to inject or intercept input events) replacement is not possible on Wayland (without having separate support for each compositor, of course). These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile), this[0] Reddit comment puts it nicely: > It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. But for some reason we absolutely need this technology on the desktop, like we had not enough pain and lose ends over here without it. But the lack of these features AFAIK also causes big trouble for users with special accessibility needs. Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games. [0] https://www.reddit.com/r/linux/comments/7lb5l7/new_screenshot_alternative_for_wayland/ https://www.reddit.com/r/linux/comments/7lb5l7/new_screensho...

dralley 6y ago
> Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games. https://www.gamingonlinux.com/articles/gnomes-mutter-gets-fullscreen-unredirect-supported-on-wayland.16457 https://www.gamingonlinux.com/articles/gnomes-mutter-gets-fu...
- andreyv 6y ago
  In fast-paced games it is essential to disable vertical synchronization as well, trading possible tearing for less input lag. Does Wayland support this?
  - pas 6y ago
    You can draw to the OpenGL/EGL surfaces directly (Weston 5.0+ has composition bypass).
  - jhasse 6y ago
    Yes.
- nsajko 6y ago
  Yeah, this is exactly what I'm talking about, with the feature only coming in 2020 and being specific to Gnome.
ximm 6y ago
Was the pun intended? https://github.com/emersion/grim https://github.com/emersion/grim
- nsajko 6y ago
  No, it's just awkward and unfortunate wording :)
grandinj 6y ago
And the Remote Desktop stuff needs to talk to each compositor to emplement copy and paste.
severino 6y ago
> Implementing a Wayland compositor requires much more effort than implementing an X11 window manager and each new compositor implementation reinvents the wheel many times, leaving users with less options for a desktop environment than on X11 At least if this helps to reduce fragmentation, so that we can have a decent desktop environment, instead of 4.000 half backed ones, could be something positive for Linux.
cycloptic 6y ago
Check ydotool for an xdotool replacement: https://github.com/ReimuNotMoe/ydotool https://github.com/ReimuNotMoe/ydotool The lack of a common screenshot protocol isn't related to security. The desktops just haven't been able to agree on a common protocol (yet?)
- pmoriarty 6y ago
  ydotool only supports a tiny fraction of xdotool's features. ...and that's unlikely to improve much any time soon, since, according to ydotool's README: "Since Jun, 2019, I have little time to maintain this project"
  - cycloptic 6y ago
    Check the paragraphs below that where the developer asks for help either by donations or by pull requests. I understand you probably don't want to do that because you're fine with xdotool for now, but the options are there should you need them.
    - pmoriarty 6y ago
      Ok, so I can write the features ydotool is missing or pay someone to do it. I guess those options are the same for any software. Either way, ydotool is clearly not a viable replacement for xdotool right now, if it will ever be.
      - cycloptic 6y ago
        It likely won't ever be a drop-in replacement because a lot of X operations don't really make sense in Wayland. (Even in X, xdotool isn't perfect and a lot of its commands won't work if your window manager doesn't support the right hints) Unless you feel like volunteering to make a standard for this, you'll get the best mileage out of using an API specific to your compositor rather than waiting for someone else to come up with a standard. I know GNOME exports its internals with a javascript interface, and Sway has a way to run various commands using a JSON interface too.
noobermin 6y ago
I've added this comment to my favorites; a very succinct description of the problems with Wayland. At this point I wonder if starting from scratch was the right call vs. spending the 12 intervening years trying to (yes) dig into X11 and fix existing issues.
- GekkePrutser 6y ago
  And it doesn't even mention the valuable features of X11 that were considered out of scope for wayland, such as network transparency. It's really super useful being able to just fire up a program on a remote SSH session and get the window on my local computer. Without having to set up VNC and a window manager etc etc on the remote computer. Of course this feature also needs a big review. It needs proper security (though tunneling over SSH fixes a lot of that) and there's too many back-and-forths in the protocol leading to it being really sluggish over high-latency connections. Makes sense as it was mainly invented for X-terminals on a local network. Also, more and more features like fonts are now rendered remotely instead of locally on the user's computer (the server in X terminology). NX and X2go fix that mostly but it would be great to have this in the actual protocol. As well as provisions for smooth video streaming. As well as that, the whole computing industry is moving back from powerful endpoints (PCs) to powerful central computing (now cloud, the mainframes/powerful unix servers in the early days of X). So really, this feature will become more important again. But yeah I would really prefer to see X11 being brought up to date rather than Wayland. Wayland is focused way too much on the local desktop.
  - danhor 6y ago
    X (at least nowadays) isn't very network transparent. Most things are done via shared buffers (it's faster than shoving bitmaps down a socket), with special fallbacks implemented by the clients, so that x forwarding doesn't break.
    - GekkePrutser 6y ago
      I know, also font rendering with anti-aliasing is usually done on the client side now (though the old way with font servers was far from ideal, it was much more bandwidth efficient!).. I know it's not perfect but they do this because the protocol lacks support for smooth video. I'm just advocating a modernised X over moving to Wayland altogether, like the poster I replied to.
Androider 6y ago
The problems Wayland solve are those of yesteryear, sprinkled with the broken dreams that we'd all be running it on Linux phones by now. In that context a strict security model makes sense. Trouble is, that security model makes no sense on today's desktop. In 2020, people aren't downloading and running native applications on desktops, not even (especially?) on Linux. The desktop is now solely a manager of browser windows. Everything that normal folks do is done through the browser, from email to office collaboration. Maybe a few Electron apps sprinkled in (mostly targeted for developers, ironically). Maybe the calculator? That's pretty much it. The most important desktop apps today? Chrome and Zoom. Both which barely work in Wayland. But at least all that non-existent native desktop software can't now spy on my web mail? Too bad screen sharing is now a complete shitshow. Actually worthwhile problems to solve on the desktop are for example high DPI and fractional scaling, rock-solid multi-monitor support, dynamically plugging in and removing displays, mixing displays of varying DPIs, high refresh rates and variable sync etc. The desktop will increasingly become a niche for high-end developer setups.
- transpostmeta 6y ago
  You must realise that many people use desktop applications for their work. The Office suite, the Adobe suite, AutoCAD, ArcGIS: whatever program is in use in the industry you are in.
- nsajko 6y ago
  One more thing: the Wayland security model doesn't make much sense anyway, considering that running untrusted code over a large attack surface and without at least virtualization is probably a bad idea anyway nowadays (and even virtual machines can be escaped from).
  - heftig 6y ago
    The Wayland security model was designed with sandboxed applications in mind. X was not.
    - account42 6y ago
ivanbakel 6y ago
> These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile) That's an unnecessarily abrasive view: the Wayland protocol designers do not hate power users. But allowing programs to constantly take in arbitrary input & output information in the background, as well as simulate arbitrary input to other programs, is an obvious and glaring security flaw. Unfortunately, that forbids general-purpose screenshotting and key-rebinding programs - but there is no sensible middle ground. >Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. I appreciate that the average HN poster, and to a lesser extent the average Linux user, does not do this - but many, many Windows users do. In order to actually break into a mass desktop market, there has to be consideration of the ways people who do not currently use Linux behave. I would even argue that lots of current Linux users are guilty of this - how many Arch users are checking the contents of PKGBUILDs from the AUR? How many Linux users, when searching for the solution to some problem with their desktop, have blindly copy-pasted commands from some support post - or worse still, just downloaded a "fix it" script to run? Wayland is built on sane assumptions, because it also aims to cater to a not-insignificant part of the desktop market. That the response of an X11 supporter is "simply run the correct programs" show how little they have understood the goals and successes of Wayland as a project. It is not X12, and some of us are grateful for that.
- nsajko 6y ago
  OK then, if Wayland is meant for closed and user-hostile platforms, why is it being marketed as a X11 replacement? Why is there a constant FUD-included push to dissmis Xorg in favor of Wayland compositors?
  - cedilla 6y ago
    When you dismiss any reasoning as "userhostile" and "FUD" it will be difficult to understand any change. For the life of me I can't understand why so many people are always convinced that people who develop replacements for decades old frameworks do it only to spite users. But the answer is: X sucks. It's 36 year old software with dozens of extensions. No one wants to write software that uses X, and apparently, per this HN submission, no one wants to maintain X.
Izkata 6y ago
> > It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. Funny, Android has had screenshots for a decade.
- higerordermap 6y ago
  And screen recorder apps, with a special permission IIRC.
nialv7 6y ago
> massive fragmentation issues across the graphical part of the Linux ecosystem This is a fair criticism. It is true that we see each of the compositors rolling its own extensions to the protocol. But I believe wayland is trying to standardize a lot of the protocols which should cover common use cases. > each new compositor implementation reinvents the wheel many times This is not true. There are libraries like wlroots[0] which you can build on top of. You don't have to redo the work that is already done in other compositors. > application that needs to grab the entire screen will need separate code for each compositor it supports screenshots There is the PipeWire[1] effort to support screenshot and screen capture on wayland in a unified way. > Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games. Also not true. On a properly implemented compositor, video games frames shouldn't have longer latency to screen than on Xorg. X server has to do composition too, whether you run a compositor or not. [0]: https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots [1]: https://en.wikipedia.org/wiki/PipeWire https://en.wikipedia.org/wiki/PipeWire
account42 6y ago
The real problem of this "security" nonsense isn't even existing use cases like screenshot or xdotool but rather the cost it imposes on any future power tool that someone might think of but can't implement witout getting every compositor on board.

by nsajko 6y ago

dralley 6y ago

> Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games. https://www.gamingonlinux.com/articles/gnomes-mutter-gets-fullscreen-unredirect-supported-on-wayland.16457 https://www.gamingonlinux.com/articles/gnomes-mutter-gets-fu...

andreyv 6y ago
In fast-paced games it is essential to disable vertical synchronization as well, trading possible tearing for less input lag. Does Wayland support this?
- pas 6y ago
  You can draw to the OpenGL/EGL surfaces directly (Weston 5.0+ has composition bypass).
- jhasse 6y ago
  Yes.
nsajko 6y ago
Yeah, this is exactly what I'm talking about, with the feature only coming in 2020 and being specific to Gnome.

ximm 6y ago

Was the pun intended? https://github.com/emersion/grim https://github.com/emersion/grim

nsajko 6y ago
No, it's just awkward and unfortunate wording :)

grandinj 6y ago

And the Remote Desktop stuff needs to talk to each compositor to emplement copy and paste.

severino 6y ago

> Implementing a Wayland compositor requires much more effort than implementing an X11 window manager and each new compositor implementation reinvents the wheel many times, leaving users with less options for a desktop environment than on X11 At least if this helps to reduce fragmentation, so that we can have a decent desktop environment, instead of 4.000 half backed ones, could be something positive for Linux.

cycloptic 6y ago

Check ydotool for an xdotool replacement: https://github.com/ReimuNotMoe/ydotool https://github.com/ReimuNotMoe/ydotool The lack of a common screenshot protocol isn't related to security. The desktops just haven't been able to agree on a common protocol (yet?)

pmoriarty 6y ago
ydotool only supports a tiny fraction of xdotool's features. ...and that's unlikely to improve much any time soon, since, according to ydotool's README: "Since Jun, 2019, I have little time to maintain this project"
- cycloptic 6y ago
  Check the paragraphs below that where the developer asks for help either by donations or by pull requests. I understand you probably don't want to do that because you're fine with xdotool for now, but the options are there should you need them.
  - pmoriarty 6y ago
    Ok, so I can write the features ydotool is missing or pay someone to do it. I guess those options are the same for any software. Either way, ydotool is clearly not a viable replacement for xdotool right now, if it will ever be.
    - cycloptic 6y ago
      It likely won't ever be a drop-in replacement because a lot of X operations don't really make sense in Wayland. (Even in X, xdotool isn't perfect and a lot of its commands won't work if your window manager doesn't support the right hints) Unless you feel like volunteering to make a standard for this, you'll get the best mileage out of using an API specific to your compositor rather than waiting for someone else to come up with a standard. I know GNOME exports its internals with a javascript interface, and Sway has a way to run various commands using a JSON interface too.

noobermin 6y ago

I've added this comment to my favorites; a very succinct description of the problems with Wayland. At this point I wonder if starting from scratch was the right call vs. spending the 12 intervening years trying to (yes) dig into X11 and fix existing issues.

GekkePrutser 6y ago
And it doesn't even mention the valuable features of X11 that were considered out of scope for wayland, such as network transparency. It's really super useful being able to just fire up a program on a remote SSH session and get the window on my local computer. Without having to set up VNC and a window manager etc etc on the remote computer. Of course this feature also needs a big review. It needs proper security (though tunneling over SSH fixes a lot of that) and there's too many back-and-forths in the protocol leading to it being really sluggish over high-latency connections. Makes sense as it was mainly invented for X-terminals on a local network. Also, more and more features like fonts are now rendered remotely instead of locally on the user's computer (the server in X terminology). NX and X2go fix that mostly but it would be great to have this in the actual protocol. As well as provisions for smooth video streaming. As well as that, the whole computing industry is moving back from powerful endpoints (PCs) to powerful central computing (now cloud, the mainframes/powerful unix servers in the early days of X). So really, this feature will become more important again. But yeah I would really prefer to see X11 being brought up to date rather than Wayland. Wayland is focused way too much on the local desktop.
- danhor 6y ago
  X (at least nowadays) isn't very network transparent. Most things are done via shared buffers (it's faster than shoving bitmaps down a socket), with special fallbacks implemented by the clients, so that x forwarding doesn't break.
  - GekkePrutser 6y ago
    I know, also font rendering with anti-aliasing is usually done on the client side now (though the old way with font servers was far from ideal, it was much more bandwidth efficient!).. I know it's not perfect but they do this because the protocol lacks support for smooth video. I'm just advocating a modernised X over moving to Wayland altogether, like the poster I replied to.

Androider 6y ago

The problems Wayland solve are those of yesteryear, sprinkled with the broken dreams that we'd all be running it on Linux phones by now. In that context a strict security model makes sense. Trouble is, that security model makes no sense on today's desktop. In 2020, people aren't downloading and running native applications on desktops, not even (especially?) on Linux. The desktop is now solely a manager of browser windows. Everything that normal folks do is done through the browser, from email to office collaboration. Maybe a few Electron apps sprinkled in (mostly targeted for developers, ironically). Maybe the calculator? That's pretty much it. The most important desktop apps today? Chrome and Zoom. Both which barely work in Wayland. But at least all that non-existent native desktop software can't now spy on my web mail? Too bad screen sharing is now a complete shitshow. Actually worthwhile problems to solve on the desktop are for example high DPI and fractional scaling, rock-solid multi-monitor support, dynamically plugging in and removing displays, mixing displays of varying DPIs, high refresh rates and variable sync etc. The desktop will increasingly become a niche for high-end developer setups.

transpostmeta 6y ago
You must realise that many people use desktop applications for their work. The Office suite, the Adobe suite, AutoCAD, ArcGIS: whatever program is in use in the industry you are in.
nsajko 6y ago
One more thing: the Wayland security model doesn't make much sense anyway, considering that running untrusted code over a large attack surface and without at least virtualization is probably a bad idea anyway nowadays (and even virtual machines can be escaped from).
- heftig 6y ago
  The Wayland security model was designed with sandboxed applications in mind. X was not.
  - account42 6y ago

ivanbakel 6y ago

> These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile) That's an unnecessarily abrasive view: the Wayland protocol designers do not hate power users. But allowing programs to constantly take in arbitrary input & output information in the background, as well as simulate arbitrary input to other programs, is an obvious and glaring security flaw. Unfortunately, that forbids general-purpose screenshotting and key-rebinding programs - but there is no sensible middle ground. >Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. I appreciate that the average HN poster, and to a lesser extent the average Linux user, does not do this - but many, many Windows users do. In order to actually break into a mass desktop market, there has to be consideration of the ways people who do not currently use Linux behave. I would even argue that lots of current Linux users are guilty of this - how many Arch users are checking the contents of PKGBUILDs from the AUR? How many Linux users, when searching for the solution to some problem with their desktop, have blindly copy-pasted commands from some support post - or worse still, just downloaded a "fix it" script to run? Wayland is built on sane assumptions, because it also aims to cater to a not-insignificant part of the desktop market. That the response of an X11 supporter is "simply run the correct programs" show how little they have understood the goals and successes of Wayland as a project. It is not X12, and some of us are grateful for that.

nsajko 6y ago
OK then, if Wayland is meant for closed and user-hostile platforms, why is it being marketed as a X11 replacement? Why is there a constant FUD-included push to dissmis Xorg in favor of Wayland compositors?
- cedilla 6y ago
  When you dismiss any reasoning as "userhostile" and "FUD" it will be difficult to understand any change. For the life of me I can't understand why so many people are always convinced that people who develop replacements for decades old frameworks do it only to spite users. But the answer is: X sucks. It's 36 year old software with dozens of extensions. No one wants to write software that uses X, and apparently, per this HN submission, no one wants to maintain X.

Izkata 6y ago

> > It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. Funny, Android has had screenshots for a decade.

higerordermap 6y ago
And screen recorder apps, with a special permission IIRC.

nialv7 6y ago

> massive fragmentation issues across the graphical part of the Linux ecosystem This is a fair criticism. It is true that we see each of the compositors rolling its own extensions to the protocol. But I believe wayland is trying to standardize a lot of the protocols which should cover common use cases. > each new compositor implementation reinvents the wheel many times This is not true. There are libraries like wlroots[0] which you can build on top of. You don't have to redo the work that is already done in other compositors. > application that needs to grab the entire screen will need separate code for each compositor it supports screenshots There is the PipeWire[1] effort to support screenshot and screen capture on wayland in a unified way. > Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games. Also not true. On a properly implemented compositor, video games frames shouldn't have longer latency to screen than on Xorg. X server has to do composition too, whether you run a compositor or not. [0]: https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots [1]: https://en.wikipedia.org/wiki/PipeWire https://en.wikipedia.org/wiki/PipeWire

account42 6y ago

The real problem of this "security" nonsense isn't even existing use cases like screenshot or xdotool but rather the cost it imposes on any future power tool that someone might think of but can't implement witout getting every compositor on board.