Hacker News Reader

Comment by cycloptic | Hacker News Reader

There is no real security boundary or privilege separation in that case, the window manager and compositor are getting full access to the screen and the input devices and all the client windows. That's part of the reason why it doesn't make much sense to keep them separated, I know you were joking but it's true: they might as well be threads, it saves you the serialization/deserialization step.

View on HN

In Wayland, a fail-stop bug in the window management logic will now bring down your compositor and every program that was connected to it. In X11, a fail-stop bug in the window management logic only crashes your window manager -- everything else keeps running. This is a really nice property to have -- in general, why make the "blast radius" of a fail-stop bug bigger when we don't need to?

Like, what's the upside of making it so a bug in the window management logic can crash the entire GUI? You claim latency due to no need for serialization/deserialization across process boundaries, and you claim potentially less-complex code. I'm very skeptical about the complexity reduction -- you're replacing the IPC with global state guarded by critical sections which your threads all need to respect. Getting rid of IPC isn't "free" -- you're replacing it with something that could be even worse. So, I'll need to see some actual case studies here.

I agree that there is measurable latency (context switches and all), but if it's a difference of only a few extra microseconds -- i.e. something the user won't notice because computers are insanely fast these days compared to when X11 and window managers were first written -- then I'm disinclined to give up my crash resilience. Do you have data to show that there is noticeable, irreducible performance lag in having a separate window manager process from a compositor?

I don't have any raw data for performance numbers and that wouldn't matter anyway because they may not be relevant to your set up; if you're concerned about that you should run a test comparing them yourself on your specific environment. I'm speaking in terms of code complexity here, if you want to follow the threaded approach then minimum two threads will do the job (one for the scenegraph, one for the sockets), and an X compositor should potentially be doing this anyway to avoid lag caused by slow rendering. The difference is that the X compositor is just storing a copy of large amounts of state from the X server, whereas the Wayland compositor would store the canonical data and wouldn't need to worry about falling out of sync with the X server.

Also, the way that X does it is overly complicated and is unnecessary to have protection against window manager crashes. A similar type of crash protection could be done with a Wayland implementation and it could be done in a much simpler way than moving the entire window manager out into a separate process. You just need to have another process that can hold the client fds and cache a minimum amount of state needed to resume the clients, it wouldn't need to know as much as the X server does to accomplish that task. Prior art is in the Arcan Wayland bridge, other Wayland implementations have not implemented this but they could eventually: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...

> if you're concerned about that you should run a test comparing them yourself on your specific environment.

I mean, X.org runs well enough on my end? I'm not finding myself wanting something with lower input latency.

> The difference is that the X compositor is just storing a copy of large amounts of state from the X server, whereas the Wayland compositor would store the canonical data and wouldn't need to worry about falling out of sync with the X server.

Honestly, if I were to do a ground-up X11 implementation, I'd probably build it around wlroots or similar. Then Wayland clients could interact with it, and I'd be able to preserve all the X11 compatibility and X11-isms I cared about. Like having separate window managers, hotkey daemons, screenshot tools, the slew of X11 command-line clients I know and love today, and so on.

Someone could build a combined Wayland/X server in the same process like that, but why? The only reason you would need to do that would be to run Wayland clients natively on your X server. IMO if you want to use Wayland it is much easier and more valuable to just port those tools. The hotkey daemons, screenshot tools, and command-line clients are pretty small and not that hard for someone to rewrite as a weekend project, people have done a lot of that already. The harder part is the window managers, but if you're a hard-core window manager author used to doing things the X way then you won't see much reason to switch anyway.

If the Wayland/fd.o crowd insists on breaking things I relied on to the point where I have to work weekends to fix everything that used to work, I'm going to spend that time replacing whatever software they wrote that I use with software that I wrote, since at least I won't be breaking my workflow.

I don't understand what you mean. You can still continue using X if that's what you want, people deciding to spend their time developing Wayland doesn't somehow break X or make it worse.

Also just FYI, it seems x.org has merged with freedesktop.org so they are mostly equivalent at this point, being run by the same group of people.

I'm assuming that X.org will go unmaintained after a time, which is fine. But if that means I can't get a usable X server running later on, I wouldn't mind taking a crack at adding a Wayland extension that implemented the X11 protocol.

It's not clear what that would solve, XWayland mostly fulfills that role already. It can't run window managers, but you wouldn't really get that everywhere from adding another Wayland extension either -- doing that would require a lot of additional code and the GNOME and KDE implementations wouldn't want that anyway because they have their own built in window managers. So maybe you could get a hacked up version of Weston that can run X window managers, but why bother dealing with maintaining that instead of just maintaining X? It's unlikely the X server will stop working as long as you have a GPU that supports GL or Vulkan, the glamor/modesetting driver should continue to work there.

In the event that I do need to use something that is Wayland-only, I'd like to have the ability to run it without breaking everything else.

I don't know of any significant applications that are Wayland only. If that ever happened, someone could just make a really simple Wayland server that does the reverse of XWayland.

Reply on news.ycombinator.com