Ask HN: Frustrated with Wayland – Misconceptions?
9 comments
There are defined protocol extensions for most/all those features but in some cases they're relatively "new" and haven't been implemented everywhere yet. I think the real problem is just that the Linux desktop is understaffed by an order of magnitude relative to what it's trying to accomplish (which is far too much but people refuse to compromise on scope) and thus development proceeds much more slowly than people would like. Also, defining standard protocols is a political process that cannot be rushed and unfortunately the Wayland community waited way too many years to start on many of the protocols. (e.g. color management just started recently—why didn't they start debating it a decade ago?)
Another, smaller, problem is that the wlroots rebel alliance has deliberately rejected some major decisions like CSD, essentially forking the community into Mainstream Wayland (GNOME/KDE/Weston/etc) and incompatible Rebel Wayland (Sway/etc.). Since a tiny but vocal minority of hackers use Sway, their complaints seem much more significant than they are.
Another, smaller, problem is that the wlroots rebel alliance has deliberately rejected some major decisions like CSD, essentially forking the community into Mainstream Wayland (GNOME/KDE/Weston/etc) and incompatible Rebel Wayland (Sway/etc.). Since a tiny but vocal minority of hackers use Sway, their complaints seem much more significant than they are.
But why do we then aim to replace X11, which is from a user perspective almost feature-complete?
x11 gets some stuff plain wrong. It's a trooper with decent hardware support and an enormously long legacy behind it, but along with that comes really poorly-designed hacks and deeply ingrained desktop failures. Like, the x11 framebuffer for example: add a second display, and it just extends the framebuffer resolution to the largest monitor. If your refresh rates are different, you're also wasting GPU cycles. It can be worked-around in software, but it pretty significantly hobbles the integration possible with a fully-featured desktop.
Or, look at how x11 views synchronization primitives: it doesn't! You need to implement a compositor with an opinionated hack to make it work, which still doesn't work consistently across configurations. Want to use FreeSync? It's blocked by the model x11 uses to abstract displays. Entire classes of usage (eg. gaming, responsive gestures, video editing, HDR pipelines, color calibration, etc.) are inherently limited by what x11 offers.
I do miss the old DEs and their feature-completeness, but getting them to compete with modern MacOS and Windows was like oiling up Hulk Hogan to go fight Floyd Mayweather. Truly the only competitive way forward was abandoning the xorg model and letting DEs define their desktop.
Or, look at how x11 views synchronization primitives: it doesn't! You need to implement a compositor with an opinionated hack to make it work, which still doesn't work consistently across configurations. Want to use FreeSync? It's blocked by the model x11 uses to abstract displays. Entire classes of usage (eg. gaming, responsive gestures, video editing, HDR pipelines, color calibration, etc.) are inherently limited by what x11 offers.
I do miss the old DEs and their feature-completeness, but getting them to compete with modern MacOS and Windows was like oiling up Hulk Hogan to go fight Floyd Mayweather. Truly the only competitive way forward was abandoning the xorg model and letting DEs define their desktop.
It would be fair if you also compared Wayland to X11 in the areas wayland really lacks, which are the ones I originally posted.
It is a strict regression in all of these. In my mind, a modern framework should embrace security first, then accessibility, then architectural beauty. Wayland gets this, from my humble point of view, exactly wrong (architectural beauty, security, accessibility).
Maybe it's time for another re-approach of linux DE's.
It is a strict regression in all of these. In my mind, a modern framework should embrace security first, then accessibility, then architectural beauty. Wayland gets this, from my humble point of view, exactly wrong (architectural beauty, security, accessibility).
Maybe it's time for another re-approach of linux DE's.
I don't really see the problem you are seeing.
> all of the above tools need to be re-written and adapted to each possible compositor
These sorts of tools have always been (re)implemented by each (moderately large) desktop environment anyway. This doesn't seem like something stemming from Wayland or much of a change in general? Any one of these tools needs to be designed, tested, integrated with the rest of the desktop environment, etc. -- this is where the majority of the development effort would(should?) be going. I don't think the effort required to interface with the window manager / compositor is actually that significant, or significantly higher under Wayland.
> all of the above tools need to be re-written and adapted to each possible compositor
These sorts of tools have always been (re)implemented by each (moderately large) desktop environment anyway. This doesn't seem like something stemming from Wayland or much of a change in general? Any one of these tools needs to be designed, tested, integrated with the rest of the desktop environment, etc. -- this is where the majority of the development effort would(should?) be going. I don't think the effort required to interface with the window manager / compositor is actually that significant, or significantly higher under Wayland.
Let's assume you are blind and you rely on a certain set of tools. These tools aren't available after you upgrade to Ubuntu 22.04. Wouldn't you think this is a regression?
Any why do you think those tools need to be rewritten anyway? It's fine to write a set of tools for X11 and for wayland, it's not fine to write a set of tools for X11 and for any desktop environment on Linux. This should be obvious, so I assume I am misunderstanding you?
Also, do you really think TeamViewer, AnyDesk, VNC etc. will all be rewritten for each existing desktop environment? This will lead to less linux users. Why can't I understand your point of view?
Any why do you think those tools need to be rewritten anyway? It's fine to write a set of tools for X11 and for wayland, it's not fine to write a set of tools for X11 and for any desktop environment on Linux. This should be obvious, so I assume I am misunderstanding you?
Also, do you really think TeamViewer, AnyDesk, VNC etc. will all be rewritten for each existing desktop environment? This will lead to less linux users. Why can't I understand your point of view?
The Linux Desktop is a Joke. It's a Potemkin village run by IBM, they'd like to be able to make custom user interfaces for this application or that application but they just don't care about the requirements of the average user. Customer service makes Google look like white glove service.
> Customer service
> Linux
You're not the customer if you get it for free.
> Linux
You're not the customer if you get it for free.
I won't rule out that I don't understand all relevant concepts in wayland yet, if so I'd like to apologize already.
Now to the things which - as per the title - frustrate me. The year of "Linux on Desktop" is almost there, as we all know - jokes aside, Linux really gets more and more traction even outside of developers. And while developers are fine to tinker and modify the system, and do workarounds, regular users don't like that and often even can't help themselves.
So, here is a list of some applications one expects from a modern desktop OS:
- Screenshots
- Screen recorders
- Password managers
- Accessibility helpers:
- Remote desktop software (both server and client)
Now, as far as I understand the wayland model, _all_ of the above must be handled by the compositor, not by wayland itself.
The compositor exists to keep the wayland core small and to not over-generalize concepts to make different window environments, like Gnome, KDE, Xfce etc. work. Instead, each window environment has to implement its own compositor.
This is per se obviously okay. But for all of the above points there is no protocol or standard defined, to the best of my knowledge. That means, and appears to be the reality, that all those functions are either missing or are implemented in a compositor-specific way¹.
This in turn means that all of the above tools need to be re-written and adapted to each possible compositor, or that each window environment provides the required tooling, or that some outside party defines a standard which all compositors implement which facilitates a common API for all of the above.
And this is the frustrating point: we had a really nice ecosystem of tools for all of the above points. Now we don't anymore. And it doesn't appear to me that fixing this is any priority for the wayland team.
Now, please help me: do I miss something important, if so please inform me. Otherwise, what would you propose on how to support the wayland team here? I have the impression that even if someone were to provide high quality, working merge requests for parts of the above, they would be rejected due to "security considerations" or that they don't belong into wayland core.
Some examples of related bug reports or discussions:
* https://gitlab.freedesktop.org/wayland/wayland/-/issues/326 (which links to a very interesting bug in xdg-desktop-portal, where several accessibility-related projects are involved in the comments)
* https://gitlab.freedesktop.org/wayland/wayland/-/issues/233
* https://wiki.gnome.org/Accessibility/Wayland
* https://news.ycombinator.com/item?id=25175894
¹ I think there are some exceptions, like wlroots, but I have a hard time understanding which compositor supports wlroots (is there a list somewhere?)