undefined | Better HN

0 pointsLiskni_si4y ago0 comments

waymonad has a somewhat more active fork here: https://github.com/L-as/waymonad, but it's still just a one-man show that got picked up at ZuriHac 2021 and then failed to gather sufficient momentum.

As a maintainer of xmonad upstream, I'm watching the waymonad project to see where it goes, but I have some concerns about its architecture which I'd love to see addressed before we'd officially endorse people to try switching. This is a copy of a message I sent to fellow xmonad developers a couple months ago:

> We should certainly take a look sooner or later. From a quick glance, I have some concerns about the general design of it:

> It's a compositor and window-manager in one. This is typical for Wayland, but there are lots of disadvantages:

> * Restarting the WM is just like restarting X: session over. Unacceptable for xmonad/waymonad, as we don't reload config, we recompile and restart. Someone is apparently working on making Wayland compositors restartable, in general: https://indico.freedesktop.org/event/1/contributions/20/, though.

> * Another consequence of the WM and compositor being one is that they share memory leaks and GC pauses and signal handlers and whatnot. As much as I love Haskell, I'd prefer frames from an FPS shooter to be presented on screen by something else. Oh and did I mention the compositor/WM also handles input, making any GC pauses doubly painful?

> * Aside from operational issues, this also means all of that needs to be implemented. There's https://github.com/swaywm/wlroots/ (used by waymonad), a library that supposedly lets individual Wayland compositors implement less code, but it doesn't seem to be nowhere near what X gives us: we take care of window management and all the input/output handling is taken care of by other tools with their own configuration and tools. It simply doesn't seem to work that way in the Wayland world. There are other options like implementing a shell plugin for Weston, or possibly other libraries, I don't really understand the landscape.

> I may be wrong on some of these, as I didn't actually try to compile and run the thing.

> Anyway, I am convinced it'd be best if the compositor and WM were separate processes, ideally maintained by separate teams. You know, that old “do one thing and do it well” philosophy. And I have no idea how difficult would it be to make things work this way. If someone were to work on this, discovering the answer to this question would be one the first things to do.

I should probably clarify the wlroots handling IO thing: what I meant is that with Xorg, there are command-line tools like setxkbmap, xinput, xset, xmodmap, xcape, xrandr, autorandr and possibly others that a user can use to interact with the X server and tweak stuff, and from what I understand these don't have equivalents in the Wayland world that would work across WMs/compositors. I could be wrong, though, perhaps wlroots does have a standard protocol for such things and such tools already exist?

0 comments

3 comments · 1 top-level

ongy4y ago· 2 in thread

Hey,

I'm the (mostly negligent) original author of waymonad.

Minor GC stalls are not an issue for reasonable framerates right now. Major stalls are in the order of a single frame. Which I considered acceptable, but YMMV.

I fully agree on the issue with restarting. I had some ideas about how to improve that, but never got around to doing any of that. wlroots was my choice, because I like the guys and worked with them on the project. Other libraries (most relevant probably libweston) are a bit more "fully featured" but also slightly less flexible.

Liskni_siOP4y ago

> I fully agree on the issue with restarting. I had some ideas about how to improve that

Can you perhaps share some of those ideas? Might be something I haven't thought about. :-)

> wlroots was my choice, because I like the guys and worked with them on the project. Other libraries (most relevant probably libweston) are a bit more "fully featured" but also slightly less flexible.

Is that still the case today? I mean, I haven't really spent any considerable time researching the Wayland landscape, but I was under the impression that wlroots gained considerable momentum in recent years while weston is still just the reference compositor, but not really used in any well-known Wayland compositor.

ongy4y ago

I've been out of the scene for a couple years now (essentially since I switched from student to full time), but it's mostly the goals. wlroots is the de-facto standard library used by almost everything but the big 3 DEs. But it's still designed and intended to be mostlyl bare bones, and doesn't have a scenegraph or other nice things. OTOH it got stuff like damage tracking and I think there were plans to add an optional library on top for some scenegraph stuff.

My main idea around persistance was a wrapper core code, that loads the higher level library. So we could switch out the library as object inside the main code. At the same time, I'd have used this chance to experiment with hot-path loops that avoid the Haskell runtime, but run in native code. To avoid the previously mentioned GC stalls.

Though in practice, that gets closer to the X model, where we split the display server and window manager with a proper API. We'd still have more control on what we want async and what we want sync. And it'd be up to experimenting how much of the display manager should be exposed as library functions or just driven from the outside.

Other ideas like serializing state and passing that in some way could work to some degree, but are probably not worth it. Maybe with some help from CRIU stuff, but I'm unsure about OS portability of that.

In general, the big learning I'd like people to take, which is mostly unrelated: don't try to do multi-seat. xmonad has a neat design, and the attempt to add multi-seat broke so much stuff. It's not worth it for a probably <.1% feature.

1 more reply

j / k navigate · click thread line to collapse