Hacker News Reader

Comment by dolni | Hacker News Reader

Unfortunately, I think Wayland really botched things. That's a shame because it would have been a great improvement. Wayland and friends have taken far too long to build and the tradeoffs to me, an end user, are not convincing.

I tried to use Sway for a few months (as a regular user of i3) and I ran into too many frustrating issues to want to keep with it.

The greatest problem with the Wayland protocol is how much work a compositor has to do. Requiring every window manager to also have to take on tasks like processing keyboard and mouse input is a massive tradeoff for what Wayland offers.

IMO, we needed something not far off what X11 does. Really, X11 was fine but could use some rearchitecture for modern times and a purge of all the 80s drawing cruft nobody uses anymore. And address the input security stuff.

View on HN

>The greatest problem with the Wayland protocol is how much work a compositor has to do. Requiring every window manager to also have to take on tasks like processing keyboard and mouse input is a massive tradeoff for what Wayland offers.

No, not really. Everything that Wayland does is stuff that X11 compositors were already doing. With those the compositor is already taking on all processing of input, and the X11 server is only creating an additional unnecessary step by passing all the input through. Thus why that extra step was removed in Wayland.

The Wayland protocol is fine and provides the modern features expected (“every frame is perfect”).

But X is two things: a protocol and a de facto standard server that window managers could easily interface with.

I wonder if we’d be in a different place if Wayland as well as offering the protocol also offered a de facto standard server (not simply a reference implementation in weston) with a window manager protocol that more or less forwards on client <-> server messages that a window manager would care about. Client buffers shared with the server can also be shared with the (separate) window manager process which then shares its composited buffer with the server for final rendering.

Somebody could design that but it is not clear why you would. You do not need a separate process for that.

It seems like the problem with Wayland is things that used to be solved by merging some code into X are now a big social synchronization problem, ie. get everybody to agree on a protocol.

You still had the same problems in X. It was a bad idea to try to get protocol code merged into X unless you could get everyone to agree on it. Because ultimately, in either case it is still the same set of people who will be using any new protocols.

Yes, that's a large part of it.

What we needed was a server and a standard library. Not a barebones protocol for everyone to implement with a different set of bugs.

wlroots showed up too late to the game. Now we have GNOME, KDE, wlroots, and maybe some other implementations floating around out there.

Doing so requires writing a server and library that everyone can agree on, which probably will not happen and is probably one of the main reasons they did not do it in the first place.

Despite the whining of anti-systemd people, it worked for systemd.

I fail to see why it would not have worked for Wayland.

Please see one of my other replies here. When implementing an X11 compositor those parts were already done separately anyway, and this is actually the entire point of X11 compositing. So the trend with X11 was already going away from the direction that you suggest.

There is a remote possibility that some person comes along and builds a server and library that will work for everybody. But such things would probably be very large, much larger than systemd. Actually, the closest thing to what you describe is probably a web browser and HTML5, but building a desktop on that seems to be not popular aside from Chrome OS.

I believe it is a more fundamental “problem” due to the bazaar vs cathedral model. The linux ecosystem simply can’t just say X or Y will be the way forward like apple can, so some inefficiency is inherent in standardization.

As long as X11 fans are going to complain without actually doing something, things are going to stay that way. Xorg developers had put it on life support years ago, and somehow nobody has stepped up to to their work.

> X11 was fine

People with deep knowledge of this area (like Keith Packard) stated the exact opposite many times (that this mess cannot be simply cleaned up and they really did have to start from scratch), but whatever.

Here's one of those articles (I think, but it's been years and I don't want to re-read it just to check):

https://lwn.net/Articles/491509/

I am not an X11 "fan". I use what works best for me.

I put a lot of effort into using Sway and the experience sucked.

> People with deep knowledge of this area (like Keith Packard) stated the exact opposite many times (that this mess cannot be simply cleaned up and they really did have to start from scratch), but whatever.

I never advocated keeping X11 and just doing cleanup. But the solution probably should look more like X11 than it does.

For all that deep knowledge we have a project a decade old, with relatively low adoption and a number of critical blunders along the way (no forethought given to apps that need global keybinds, no forethought to screen capture).

Wayland is shaping up to be a fragmented mess instead of the successor standard that the Linux desktop needed.

>no forethought given to apps that need global keybinds

Please see this pull request for a description of some of the current challenges with getting global shortcuts to work: https://github.com/flatpak/xdg-desktop-portal/pull/711

>no forethought to screen capture

The plan for a while has been to put screen capture in Pipewire, this is already working for apps that support it.

In any case, X11 also does not have any forethought in relation to hotkeys or screen capture. Technically it has no API for either of those, it has APIs that allow all applications to intercept all keys, and to allow all applications to read the contents of any window. Those APIs can be used to do hotkeys and screen capture in a rudimentary and somewhat broken way but they are not ideal. Just copying those (or an API that looks like those) into Wayland would be an unwise idea.

>> no forethought to screen capture

> The plan for a while has been to put screen capture in Pipewire, this is already working for apps that support it.

> In any case, X11 also does not have any forethought in relation to hotkeys or screen capture

IHMO screen capture and screen sharing are more basic functionality in 2022 than frame perfect. The reason is that if every frame is not perfect we can still understand what happens on our screens. If I can't make screenshots and I can't share the screen I can't work so I will use something else. X11, Windows, Mac, etc.

X11 eventually solved those problems (actually the solution derives by trusting every client of the server) and Wayland will solve them too. But as Wayland started in a world where screenshots and screen sharing were already work tools, one of the very first questions should have been: how do we design both a secure system and one that allows screenshots and screen sharing? If it was asked it wasn't given the right priority.

Having apps to collaborate with Pipewire (which was added later on if I'm not wrong) is bad design. The screen is there, I want to be able to grab it and share it no matter which app is on screen. Those pixels are mine, right?

>how do we design both a secure system and one that allows screenshots and screen sharing?

That did already happen, Weston had a built in screenshot tool. Pipewire was adopted because it was an improvement on the Weston design.

> The greatest problem with the Wayland protocol is how much work a compositor has to do. Requiring every window manager to also have to take on tasks like processing keyboard and mouse input is a massive tradeoff for what Wayland offers.

Why is it unreasonable to ask that from a window manager in the general case? The protocol should provide for every basic feature suitable for the problem domain. But these things can be refactored out to third-party libs like wlroots, making a simple window manager implementation similarly easy as under X.

> The greatest problem with the Wayland protocol is how much work a compositor has to do.

Sounds not like a very modular/orthogonalized approach, and also limiting the choice of the user.

It is as modular as any compositor wants to make it, for example Weston has a plugin system.

Regarding the issue of "choice", please read this page: http://www.islinuxaboutchoice.com/

I mean, if you allow every compositor to implement its own plugin system, then you end up with a lot of fragmentation and you effectively lock the user into one particular compositor.

So then you have to come up with a plugin system which everyone wants, which is probably not even possible because the definition of "plugin" is so vague that it could mean anything. If you ask me, fragmentation is just the default state of things in open source.

Yes, the default state is the state you get if you don't put any work into it. It is the "easy" state. Defining a good plugin system is not easy, true.

I remember at the time the Compiz developers were trying to get everyone else to either base their compositor on Compiz, or build in support for Compiz plugins. That might have been feasible if there was a working design, but Compiz plugins were very hacky and the code was a mess. IIRC the only desktop that actually did it was Unity, and that was discontinued. So you can see some of the troubles with that approach.

Reply on news.ycombinator.com