Discussion

asveikau: 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.

preisschild: You can do that already with libraries such as wlroots or Smithay

jauntywundrkind: super interested to hear more on this.i'm a little thrown, because the Wayland diagram doesn't feel quite right. the compositor does lie between the kernel and the apps, but IIRC the apps have their own graphics buffers from the kernel that they are drawing into directly. the compositor then composites them together. to me, that feels more like the kernel is at the center of the diagram here: the wayland compositor is between the kernel and the output / input.i don't think it has a huge impact on the discussion here. but this is such a key difference versus X, that i think is hugely under-told: Wayland compositors all rely on lots of kernel facilities to do the job, where-as X is basically it's own kernel, has origins where it effectively was the device driver for the gpu, talking to it over pci, and doing just about everything. when people contrast wayland versus X as wayland compositors needing to do so much, i can't help but chuckle, because it feels like the kernel does >50% of what X used to have to do itself; it's a much simpler world, using the kernel's built-in abstractions, rather than being multiple stacked layers of abstractions (kernels + X's own).it means that the task of writing the display-server / compositor is much much much simpler. it's still hard! but the kernel is helping so much. there's an assumed base of having working GPU drivers!author appears to super know their stuff. alas the FOSDEM video they link to is not loading for me. :(one major question, since this is a protocol, how viable is it to decompose the window management tasks? rather than have a monolithic window manager, does this facilitate multiple different programs working together to run a desktop? not entirely sure the use case, but a more pluggable desktop would be interesting!

pmarin: >i don't think it has a huge impact on the discussion here. but this is such a key difference versus X, that i think is hugely under-told: Wayland compositors all rely on lots of kernel facilities to do the job, where-as X is basically it's own kernel, has origins where it effectively was the device driver for the gpu, talking to it over pci, and doing just about everything. when people contrast wayland versus X as wayland compositors needing to do so much, i can't help but chuckle, because it feels like the kernel does >50% of what X used to have to do itself; it's a much simpler world, using the kernel's built-in abstractions, rather than being multiple stacked layers of abstractions (kernels + X's own).Are you an AI bot? Modern X11 server using DRM are more than 20 years old. You are talking about how X11 servers worked in the 90's

yjftsjthsd-h: No, that still requires you to make the whole thing, you just get help. For instance, I've run into a problem where I try some great new compositor that uses wlroots, and even though wlroots has good support for keyboard layouts I can't actually set the layout because the compositor hasn't wired up that functionality.

jaen: The article already addresses that...It's not easy and the major compositors (Gnome, KDE) are NOT wlroots based, making this point mostly moot anyway.This protocol at least has a chance of using a custom WM with an advanced compositor (which wlroots is not).

gzread: The Xorg codebase still includes some of those old drivers and is structured to allow them to exist.

mikkupikku: If Wayland doesn't get this solved then I'll just use X11 forever, with coding agents to keep it running if I have to.

gzread: You could use xlibre, although some people say it's a joke

oofbaroomf: I'm currently using a fully vibe-coded, personal River window manager that works just how I want it to. I switched to it after I realized I couldn't do everything I wanted in Hyprland (e.g. tile windows to equal areas instead of BSP by default).Simple example of how impactful this separation has been for me.

cosmic_cheese: 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 critical weakness in Wayland's design.

Babkock: This comment was written by AI

gf000: How is a WM not just a simple plugin/extension? Find a display server you like and write an extension for it!

cosmic_cheese: That would suffice if I were only looking to build a WM, but my goal is a full (lean) DE.

nolist_policy: Have you guys in this thread even read the post?> The new 0.4.0 release of river, a non-monolithic Wayland compositor, [...] splits the window manager into a separate program. There are already many window managers compatible with river.This is exactly the pluggable WMs in Wayland you are looking for.

gundamdoubleO: We just read titles here

wild_egg: 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.

john01dav: > I can make it do basically anything I wantX11 can't do high refresh rates every time that I've tried to do so.

badgersnake: Sway is basically i3 on Wayland. You pretty much keep your config file (with a few modifications), there really isn’t much friction.That’s not a reason to do it of course, for me the driver was support for multiple monitors with different scaling requirements.

asveikau: Yours? Because I know that mine wasn't.

asveikau: Yes, and I am praising them for tackling the idea. I don't know how you managed to misread me like that. I also read the article before commenting.

hulitu: Huh ? It did in 2000.

jauntywundrkind: Yes exactly. DRM exists, but there's still what I called the X "kernel", all of it's heavyweight abstractions.To the previous a-hole, frak you: not an AI. That's rude as frak. Also, you manage to be incredibly wrong. Even an AI wouldn't overlook such an obvious error; maybe it'd be better to have it replace you. So rude dude! Behave!

pmarin: Just to be clear the hardware abstraction layer used by wayland and any current Xserver is exactly the same.

pmarin: I am sorry if I mistaken you for a bot but the model you are describing have not been implenented by any graphic driver in decades.

Telaneo: It runs just fine at 165 hz for me. Given that xrandr and CRTs have been around for a while, and both have supported high refresh rates for a long while, something seems fishy here.

nine_k: The Wayland standard does not prescribe it (unlike X), and the reference implementations were monolithic for a very long time.Wayland in general had a rather cavalier approach to doing away with things that X users take for granted, like, well, making screenshots. Eventually, under pressure, those in charge agreed that these features are actually very important for real users, so implementations appeared. It's an understandable way to discover the minimal usable subset of features, but the process of it is a bit frustrating for the early adopters.

robinsonb5: > so implementations appearedIndeed - implementations, plural. Incompatible with each other, naturally.

locusofself: BSP?

Lerc: So that's a Wayland ex-window manager then?

gf000: You only need a single implementation that exposes an API for running a WM as an extension.I don't really get why would it be a good idea to somehow mandate a specific architecture design from the standard.

nine_k: We need a compositor that exposes everything as an extension. Preferably in a hot-reloadable, tweakable way, say, using Lua (with JIT). And also exposing its APIs in a way that allows having an analog of xdotool.

rvrb: Binary space partitioning