Live data from Hacker News

Separating the Wayland compositor and window manager

isaacfreund.com

71–80 of 228 posts

Re: Separating the Wayland compositor and window manager

#71

At this point, take all the lessons of wayland, plan everything in advance rather than incrementally deciding basic things like screenshotting and then build something new, superseding wayland so that power users like me and app developers will stop clinging to X. Right now I have no confidence in wayland and I know I'm not alone.

It is 18 years old (started in 2008 IIRC) and just now approaching something usable. So on the one hand it is a really old project whose original design considerations became obsolete a decade ago - I remember people were very bothered by the performance loss of needing several process switches with the X11 damage model in order to push an update to the screen, but on today's multi-core hardware that is basically free and everyone is using browser engines and writing their GUI in javascript anyway. But on the other, do you really want to spend another 10-20 years rewriting the Linux GUI stack from scratch only to reimplement "Wayland with best established extensions"?

Re: Separating the Wayland compositor and window manager

#72
post #3

The fact that Wayland can't just substitute out pluggable WMs without changing a bunch of other unrelated infrastructure is IMO one of the biggest user-facing losses relative to X11. Anybody who is working to improve that is doing god's work as they say.

It's a damper on development of new WMs and DEs, too. I have ideas for my own desktop I'd like to explore at some point, and if I do it'll almost certainly be X11 based initially because it's so much more quick and easy to wrap one's head around and get the iteration loop up and running with. I'm not anti-Wayland and I think X11 has enough issues that it's worth transitioning over to something better but this is a cr…

The xserver may not be completely dead either:

https:/github.com/X11Libre/xserver

Re: Separating the Wayland compositor and window manager

#74
post #3

The fact that Wayland can't just substitute out pluggable WMs without changing a bunch of other unrelated infrastructure is IMO one of the biggest user-facing losses relative to X11. Anybody who is working to improve that is doing god's work as they say.

Honestly, probably the best Linux GUI stack would look like a root Wayland server (not running as root ofc), inside which are nested a per-user Wayland servers (which can be switched between rendering to a monitor or offscreen for a remote login), inside which is nested an X11 server (which is freed from having to care about hardware), inside which runs a normal window manager.

Re: Separating the Wayland compositor and window manager

#75

I've never used a system with Wayland (been on i3 for ~15 years) but every time a project like this comes up, I have to wonder why Wayland is even a thing. So many hoops to jump through for things that should be simple. Sure, X11 has warts but I can make it do basically anything I want. Wayland seems like it will always have too much friction to ever consider switching.

Many theories. A simple one is that corporations wanted more control. See systemd's rise - not related to wayland as such, but to corporate-driven influence.

I am not saying all of the design is corporate-controlled. But a ton of propaganda is associated with how wayland was advertised, until some folks had enough with it and decided to stop buying the "xorg is dead" routine these corporations push on:

https://github.com/X11Libre/xserver

It will be interesting to see what will happen though. The GTK devs said they will help kill off xorg with GTK5. KDE also wants to kill xserver. It would be kind of cool if that would not happen - imagine if a non-corporate controlled ecosystem would emerge. Not likely to happen, but it would be a lot of fun. As well as more real competition with wayland. Wayland broke its biggest promise: that it is a viable alternative to the xorg-server. I don't want to lose any feature, so it is a drawback for me.

Re: Separating the Wayland compositor and window manager

#76
post #43

Earlier quoted context omitted.

That's not the same thing. It's way easier to write an X11 window manager than to write a Wayland compositor, even with something like wlroots, because the window manager can speak the same protocol that clients speak, and it runs as a separate process. As a concrete example, Emacs' EXWM package works by implementing an X11 client library in Emacs Lisp, then using it to talk to the X server (which is a separate proce…

EWM implements a Wayland compositor as a native thread spawned by a dynamic module in Emacs, it's a full compositor within the Emacs process: https://codeberg.org/ezemtsov/ewm So it is architecturally possible (but infeasible in plain Emacs Lisp). For river (the thing this article is about) I wrote an Emacs WM, but also opted for a dynamic module for the Wayland protocol parts: https://code.tvl.fyi/tree/tools/emacs-p…

Oh, reka looks interesting. Thanks for linking it. I don't disagree with you about dynamic modules, I just think that EWM's architecture shouldn't be necessary. (In which I think we agree?)

Re: Separating the Wayland compositor and window manager

#77
post #67

Earlier quoted context omitted.

> It seems like instead of introducing another IPC protocol like this project does It doesn't introduce a new IPC, it uses the Wayland protocol with the river-window-management-v1 extension. The extension mainly defines new objects and verbs for them, but it's the same protocol. Separate process means that the window manager can be written in any language (even, e.g.: Python).

Interpreters for Python, Lua, etc. can be embedded so using them does not require a separate process.

What about Emacs? That's the usecase I care about. Until I can get Emacs to manage my Wayland windows ala EXWM, I'm sticking to X.

Re: Separating the Wayland compositor and window manager

#78
post #3

The fact that Wayland can't just substitute out pluggable WMs without changing a bunch of other unrelated infrastructure is IMO one of the biggest user-facing losses relative to X11. Anybody who is working to improve that is doing god's work as they say.

It's a damper on development of new WMs and DEs, too. I have ideas for my own desktop I'd like to explore at some point, and if I do it'll almost certainly be X11 based initially because it's so much more quick and easy to wrap one's head around and get the iteration loop up and running with. I'm not anti-Wayland and I think X11 has enough issues that it's worth transitioning over to something better but this is a cr…

Check out Louvre. Wayland compositors may not be as hard as you thought.

Or build on River as this article suggests.

Re: Separating the Wayland compositor and window manager

#79
post #74
post #3

The fact that Wayland can't just substitute out pluggable WMs without changing a bunch of other unrelated infrastructure is IMO one of the biggest user-facing losses relative to X11. Anybody who is working to improve that is doing god's work as they say.

Honestly, probably the best Linux GUI stack would look like a root Wayland server (not running as root ofc), inside which are nested a per-user Wayland servers (which can be switched between rendering to a monitor or offscreen for a remote login), inside which is nested an X11 server (which is freed from having to care about hardware), inside which runs a normal window manager.

Pretty close to Wayback.

Re: Separating the Wayland compositor and window manager

#80
post #66

Earlier quoted context omitted.

Works fine for me with 144/120 with the second as 60.

X11 can't fix climate change.

You joke, but the wayland protocol leaves this up to the compositor. Nothing in the protocol prevents your desktop environment from doing this.
Post reply on HN