Hacker News Reader

Comment by nsajko | Hacker News Reader

The elephant in the room that most people miss in these discussions is that these problems aren't so much bugs with any specific part of the Wayland stack as they are limitations core to the Wayland design.

It's not going to get better, because Wayland is a broken/malicious architecture: the protocol basically does nothing useful, leaving essential interfaces such as screen recording for individual "compositors" to define and implement mutually incompatibly. This means that nontrivial applications don't really target Wayland, rather they only target a finite set of Wayland compositors (or other, completely separate software stacks) that they have support for.

This sort of works in favor of "big" DEs like Gnome, but for the rest of the ecosystem it would mean death by fragmentation.

View on HN

This is correct, and is in fact more worrying than simply a bad implementation.

If there was a bad implementation, it could be fixed. Wayland, on the other hand, does not even specify a way to do things like screen recording, screen capture, automation software (e.g. wmctrl), or other miscellaneous screen features (e.g. Redshift) which effectively means that there is no way to do these things at all.

The official Wayland response is that these features need to be implemented by the individual window managers, but the absence of a standard or protocol specifying them means that (a) many window managers will not implement them and (b) those that do will do so in incompatible ways. Which means that a program like a screen recorder, that was previously agnostic to window managers, now must explicitly support each window manager separately, and even then it may not be possible to use everywhere.

X was a gargantuan mess, and it had to go. The by cutting it out, we've also cut out the only commonality, the lowest common denominator software, sitting between widget libraries and the video drivers. There is now no common interface to access a wide variety of important system functions, and no one has a plan going forward. Wayland refuses to step up.

> The official Wayland response is that these features need to be implemented by the individual window managers

Ever since finding out Wayland is more like a library or spec (wasn't clear and I'm not really into the specifics) that the individual window managers implement, dropping the whole client/server and separation of display and window manager that X11 has, I've been kinda wondering in the back of my mind how long it'll be until someone designs a new system on top of Wayland to bring back that architecture... One that includes these missing APIs that window managers can use, making the new system the common target.

A few years ago?

https://gitlab.freedesktop.org/wlroots/wlroots

> missing APIs

They are not missing, they just were moved from the kitchen sink of X to things like xdg-portal and pipewire. This also helps with things like sandboxing for flatpak apps, where you want apps to ask for permission to record the screen.

> https://gitlab.freedesktop.org/wlroots/wlroots

No, that's what I was thinking of but couldn't remember the name of. I'm imagining separating the window manager like in X, making them interchangeable without having to hook in everything else.

> This sort of works in favor of "big" DEs like Gnome, but for the rest of the ecosystem it would mean death by fragmentation.

Yeah, it encourages more consolidation, e.g. many projects build on wlroots. Not really different from how it has been before (reuse X and this WM and this compositor and ...). The only difference is that instead of a giant X and the kitchen sink and 50 different small projects on top, you now have a small wayland + xdg-portals + one of gnome/kde/wlroots to build on.

> nontrivial applications don't really target Wayland, rather they...

That sounds like a good thing. Instead of hacking X inputs (e.g. xdotool or xcape, just grabbing any input and window) in a horribly insecure and nonstandard way we now get proper standardized components like the above mentioned portals. So no, they don't target "complete separate software stacks", rather the complete opposite.

> we now get proper standardized components

This is exactly the thing that's missing and it's practically impossible to hack on top of Wayland now, because any new standard that appears would be just another competing standard (ref. xkcd).

Except that we got screen recording and all that, so it is seems very much possible.

> any new standard that appears would be just another competing standard

That seems to contradict what you just argued. Adding a new standard is hard and needs buy-in from at least one of gnome/kde/wlroots. So instead of "there are now 15 standards" you have a much more pressure to agree on just one.

I think calling waylaid malicious is insane. What’s malicious and ignorant is this comment.

I’m pretty sure wayland just follows the small core with plugins strategy. If you prefer the kitchen sink way then whatever. There are official extensions to the protocol here https://gitlab.freedesktop.org/wayland/wayland-protocols and there is also the Wlroots library that can be used to implement a compositor. So, no, those smaller projects are not being “persecuted”

Right. The problem with projects like systemd and wayland isn't technical, it's social.

Will this bullshit false information ever die? Please check out the project again, because apparently you failed to understand it.

Like, you do realize that the “core” protocol set is ever growing and there has been a standard for screen capture for well over a year now to the point where even discord and the like just works on every wayland implementation? There is usually a bit of experimentation done individually to see what sticks and later a core/accepted protocol is proposed that is shared by everyone.

Out of curiosity: How do you get screen sharing on Discord? I've been trying to get it running for some time now, but wasn't able to. (arch, gnome)

Do you mean the web client or the electron app? The former should work if the browser itself is compiled with the necessary flags (at least chrome, chromium, firefox), and I believe they are mostly packaged this way nowadays.

The electron app is not yet working as per the arch linux wiki.

Other compositors need to stop fighting and copy GNOME's protocols.

Controversial comment but it seems quite valid. I have never once seen any kind of debate about why the Gnome spec is not workable. It's all open source and widely integrates with the wider ecosystem.

Wayland might not be the place for such specs and another common standard should be adopted.

For one thing, the client-side vs. server-side decorations schism is philosophical and has no right answer. But the community simply doesn't have the resources to implement both so AFAIK the GNOME/CSD side mostly pretends SSD doesn't exist and the SSD side complains about being oppressed.

Even if all current Wayland compositors adopted Gnome's protocol extensions, that wouldn't really solve anything; because another compositor could appear next week and choose to abide by pure Wayland, ignoring Gnome's quasi-standard. Where does that leave app authors?

Apps can say that they support Real Wayland not Vanilla Wayland.

Reply on news.ycombinator.com