11 ms·

Separating the Wayland compositor and window manager

344 points by dpassens 6mo ago

inatreecrown2 6mo ago
Loving the Canoe window manager concept/screenshot. I long for such a simple UI and will try out river on my thinkpad.
jauntywundrkind 6mo ago
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 6mo ago
  >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
  - gzread 6mo ago
    The Xorg codebase still includes some of those old drivers and is structured to allow them to exist.
    - jauntywundrkind 6mo ago
      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 6mo ago
        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.
        jauntywundrkind 6mo ago
        X's drivers still wrap the kernels drivers in its own abstraction layer. It's vastly deeper than what Wayland does.
    - pmarin 6mo ago
      Just to be clear the hardware abstraction layer used by wayland and any current Xserver is exactly the same.
  - wmf 6mo ago
    That's what the anti-Wayland people want: for things to work exactly as they did in the 90s. It's not an accident.
- ChocolateGod 6mo ago
  > 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. It's also possible to use hardware planes to get the actual graphics device to composite for you directly from its video memory, effectively reducing latency to the lowest possible.
asveikau 6mo ago
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 6mo ago
  You can do that already with libraries such as wlroots or Smithay
  - MarsIronPI 6mo ago
    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 process, so this works fine) and telling it how to position windows. Whereas on Wayland, this is not possible without re-implementing a standalone compositor process, because otherwise architecturally it doesn't work. Emacs can't both do the drawing and be drawn.
    - tazjin 6mo ago
      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 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-pkgs/reka https://code.tvl.fyi/tree/tools/emacs-pkgs/reka This one could technically be written in plain Emacs Lisp, but I'm happy to use something that already has all the XML codegen stuff for Wayland figured out. Dynamic modules work pretty well, fwiw.
      - 6mo ago
mikkupikku 6mo ago
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 6mo ago
  You could use xlibre, although some people say it's a joke
  - anthk 6mo ago
    Just use Xenocara and stop reusing LLM slopware.
    - LeFantome 6mo ago
      Does Xenocara run on anything other than OpenBSD?
      - bandrami 6mo ago
        Void had a port in the works at one point
  - messe 6mo ago
    The reactionary fork started by an anti vax nutcase? Yeah. It's a joke at best. At worst it'll foster an utterly toxic community.
- gf000 6mo ago
  Yeah I'm sure coding agents will be able to accurately find some non-obvious bugs in such a big and complex code base as X server.
  - mikkupikku 6mo ago
    Yes, I think so too.
oofbaroomf 6mo ago
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.
- locusofself 6mo ago
  BSP?
  - rvrb 6mo ago
    Binary space partitioning
- arikrahman 6mo ago
  I encountered similar setbacks with hyprland (https://github.com/ArikRahman/hydenix https://github.com/ArikRahman/hydenix), and I eventually wound up preferring scrollable tiling managers. I restarted from scratch with niri, and have found it to be a stable platform to develop against. Here's my current dotfiles (https://github.com/ArikRahman/dotfiles https://github.com/ArikRahman/dotfiles)
- lloeki 6mo ago
  > tile windows to equal areas instead of BSP by default hy3? https://github.com/outfoxxed/hy3 https://github.com/outfoxxed/hy3 (I'm an ex i3/now sway user and hy3 is the only way I can bear using hyprland)
Babkock 6mo ago
[dead]
wild_egg 6mo ago
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.
- badgersnake 6mo ago
  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.
  - bandrami 6mo ago
    Sort of. If your software wants to do something like "know where the pointer is" it won't work on sway.
    - Gigachad 6mo ago
      Why would I want software to know where my pointer is other than when the pointer is over the software's window?
      - bandrami 6mo ago
        Well, in my case, because the VCF on my synth sets its cutoff frequency based on the pointer's Y position and its resonance based on the pointer's X position
        badgersnake 6mo ago
        Sure, but that is pretty niche. My point was it’s pretty low friction for most people and certainly to try it. But obviously be pragmatic, if it doesn’t work for you because you have a particular requirement, or even if it doesn’t offer any improvement over what you have then don’t use it.
davispeck 6mo ago
[flagged]
- koolala 6mo ago
  Are you human? If yes sorry for the offensive question. Your account is new.
  - davispeck 6mo ago
    [flagged]
    - koolala 6mo ago
      Hi thank you sorry. Welcome to HN comments! Glad to have your voice here.
      - pwdisswordfishy 6mo ago
        You have been bamboozled.
SilentM68 6mo ago
Insightful article. I don't recall ever viewing an easy-to-follow lesson, tutorial or book for that matter that clearly explained the various components of a Linux Desktop environment. Always had to follow complicated and obscure guides to do this and that, when solving issues, but seldom did any explain their functions clearly.
- elfalem 6mo ago
  Same. This was the first material I came across that clearly and concisely explained DEs in a way that just clicked immediately.
Lerc 6mo ago
So that's a Wayland ex-window manager then?
_flux 6mo ago
To me, this is the first time Wayland feels like it's not a waste of time. The display server does not need to have the complexity of window managing on top the surface management. I certainly share the author's sentiment: > Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance. Although I'm not sure if it was the least resistance per se (as a social phenomenon), but just that it's an easier problem to tackle. Or maybe the authors means the same thing. (That and the remote access story needs to be fixed. It just works in X11. Last time I tried it with a system that had 90 degree display orientation, my input was 90 degrees off from the real one. Now, this is of course just a bug, but I have a strong feeling that the way architecture Wayland has been built makes these kind of bugs much easier to create than in X11.)
- jbritton 6mo ago
  On X11, the window manager handles the window decorations. So splitting them is going to involve some possibly non-trivial messaging and config.
  - vidarh 6mo ago
    That's purely convention. It doesn't need to be the case. There's no functionality that enforces or depend on that.
- hedgehog 6mo ago
  Remote access on X11 is a mess and I won't miss it, at least on Wayland everyone is funneled through EGL or Vulkan and there's a reasonable path to layering remote access on top of that.
  - GuB-42 6mo ago
    X11 remote access have worked really well for me. And the best part is that it worked even when the client machine has no graphical subsystem installed. I can launch GUI applications remotely with a non-privileged account and it shows on my machine as if it was native. Wayland can use RDP and some other remote desktop protocols, but it is not what I want, I want a window, not a desktop. There is Waypipe now, I heard it works fine now, but I am still doing "ssh -X", because it just works. The problem with Wayland is that it is very much "batteries not included". To all the things that worked well in X11, the response has been "it can be done, our protocol is very flexible, ask the guys writing the compositor", not "that's how is done". The result, Wayland is 18 years old and it is only starting to work well, with some pain points still remaining, and display forwarding is one of them. It is funny you mention a "reasonable path" by the way, as it is exactly that problem, I don't want a "reasonable path", I want it to work, and after 18 years, I think it is a reasonable expectation. To their credit, it seems we are getting there: waypipe, and now window managers, we may finally have feature parity.
csb6 6mo ago
Wasn't one of Wayland's key design features combining the window manager and compositor? I am not too familiar with its history but surely there have been presentations or papers about the Wayland designers' reasoning for doing so.
- wmf 6mo ago
  When the window manager is a separate process with async communication between the WM and display server things can get out of sync for a frame or two which leads to visual artifacts. In Wayland the window manager works synchronously with the compositor so that it's never out of sync.
  - csb6 6mo ago
    Yeah, that makes sense. It seems like instead of introducing another IPC protocol like this project does, there could be a compositor that loads different window managers as plugins. Then everything is in the same process and there is no need for async communication. Of course a crash in the window manager would take down the compositor, but this is already true for Wayland compositors that combine both.
    - sly010 6mo ago
      ... or the WM loads the compositor, or the WM links to a compositor library (i.e. wlroots). The point is there are options... Honestly, every time this topic comes up, I feel like the person complaining just doesn't want to put in the work and they are angry that they don't get an easy win. And maybe that's a good thing. Do we really need more half baked WMs?
    - WhyNotHugo 6mo ago
      > 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).
hparadiz 6mo ago
Lots of weird misinformation in the comments here. Wayland doesn't choose anything. It leaves the compositor to decide where to position a window and whether or not that window receives key presses or not. The program can't draw wherever it wants or receive system wide keystrokes or on behalf of another program. When appropriately implemented the screenshot system is built directly into the compositor. It's an API that let's a program request read access to a part of the screen and the compositor provides upon approval. It's much more secure that way and it works perfectly fine these days. Unfortunately not every compositor implements this. However if you really really really wanna side step this you can look at keyd - https://github.com/rvaiya/keyd https://github.com/rvaiya/keyd A project that has a daemon run in the background as a root service and that can provide an appropriate shim to pass key strokes to anything you want. And just to be clear the appropriate secure model is to have a program request to register a "global" hot key and then the compositor passes it to the appropriate program once registered. This is already a thing in KDE Plasma 6 and works just fine.
- yjftsjthsd-h 6mo ago
  > Unfortunately not every compositor implements this. That's kind of a big sticking point. When GNOME, KDE, and eg. Sway all have different screenshot APIs, the (eco)system doesn't work.
  - NekkoDroid 6mo ago
    The thing is: they mostly do implement xdg-desktop-portal's screenshot API since that does also handle permission management. In effect the modern desktop is wayland (window communication), pipewire (audio/video), and xdg-desktop-portal (compositor/environment requests) which all kinda have to be worked with for a desktop application.
kyorochan 6mo ago
River was really great even before this split, so I'm very excited to see what happens in the space in the future. I switched to Niri while waiting for it to happen, and I'll probably switch back at some point. If you were an Xmonad user I feel pretty confident in saying River is the Wayland WM for you.
- twiclo 6mo ago
  I'm still on Xmonad mainly because I've only tried hyprland and it couldn't handle the master/slave stack the way xmonad does. On River, when I create a new window will it be inserted above the current selected window even if the current window is the master? Also, when it was split up what did he call his window manager? Looks like the River repo is just for his display server/compositor
  - angus-g 6mo ago
    It has become river-classic: https://codeberg.org/river/river-classic https://codeberg.org/river/river-classic
imiric 6mo ago
I'm very excited about river. I switched to niri a few months ago, and while I like it for the most part, it feels too... busy for my taste. It defaults to a bunch of animations and decorations, all of which I've turned off. I'm happy with my current setup (aside from Wayland quirks[1]), but river's design and simplicity are very appealing. It reminds me of the philosophy of bspwm/sxhkd which I used for years on X11. I do need scrollable tiling now that I've tried it, and I'm happy that there are a couple of options to choose from with river. [1]: Seriously, why does copy/pasting sometimes simply not work?? I often have to copy twice for it to succeed. It's not related to Xwayland -> Wayland apps, and viceversa, or with copying from closed windows, etc. I don't use nor want a clipboard "manager". I just want my clipboard to work consistently. I've read many reports of this same bug on different distros and DEs, and nobody has figured it out. It's infuriating that such a basic feature is half-broken in a project that is 17 years old now!
sourcegrift 6mo ago
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.
- Asooka 6mo ago
  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"?
  - hparadiz 6mo ago
    It's biggest hurdle is having to explain even to tech people on HN that it's actually a good idea to have a UI where a user can approve a screen sharing request. You'd think for folks that claim to care about security that'd be a prime concern. It really is so weird how difficult that is for people to grasp. The implementation is likewise not complicated. Seriously how hard is it to draw a box selector and show an okay / cancel box.
    - yjftsjthsd-h 6mo ago
      If everyone appears to be missing something that's so easy to understand and implement, perhaps they're not missing it. They could have a different security/threat model than you're using. They could be expressing frustrations with being forced to manually approve something every time. They could be hitting dumb bugs in the implementation. There could be different people clamoring for more security and less intrusive security.
hedora 6mo ago
Traditionally, X11 didn’t have compositors, and didn’t need the extra round trip wayland exists to remove. I wonder if there’s space for a project like xlibre (or x.org, if it were revived) to update the x11 protocol to fill whatever gap compositors were meant to fill. For what it’s worth, I’ve been moving all my machines to lxde. Apparently, I accidentally switched back to a compositor free desktop without noticing. High framerate, vsync/tear-free and high dpi work fine. So does fractional scaling, but I disable it. Personally, I’d rather these hypothetical x11 devs focused on reverse engineering hdmi vrr (blocked by lawyers at the moment), and HDR / expanded color spaces.
- em-bee 6mo ago
  you are looking for https://en.wikipedia.org/wiki/Compiz https://en.wikipedia.org/wiki/Compiz note that compiz is also a windowmanager, so already then compositor and window manager were one unit.
  - yjftsjthsd-h 6mo ago
    The compositor and window manager could be one unit. But you can also just slap picom on with any other window manager and that's fine.
    - hedora 6mo ago
      I guess this kind misses the point. I was an early compiz user (wobbly windows, fire effect and all), but, at this point I just don’t miss it (literally: I thought I was running a compositor for the last ~5 years, and just… wasn’t.) The X windows paradigm was fine, and still works great with modern hardware.
- baobun 6mo ago
  > For what it’s worth, I’ve been moving all my machines to lxde. Any gotchas or regrets? Haven't used it in many years and now considering going all in on making it (scaffolding of) next DE. So looking at the same move.
bandrami 6mo ago
As predicted, we will re-invent X11 one feature at a time. Maybe someday soon a Wayland window will be able to know its own screen position.
- fc417fc802 6mo ago
  Last I checked the idealists weren't even willing to commit to a virtual 2D rectangular grid of pixels of arbitrary width and height. I think we'll be waiting a while (or more likely using a soft fork of the spec).
  - bandrami 6mo ago
    Ah, but now instead of one old difficult-to-maintain way of allowing an application to draw on a rectangle on the screen, we have five (and counting!) new and somewhat incompatible ways to do it. Progress.
    - fc417fc802 6mo ago
      Don't worry, I will personally see to solving this problem once and for all. https://xkcd.com/927/ https://xkcd.com/927/
  - Sharlin 6mo ago
    I'm sure we'll shift to hex-grid displays any day now. After all, hexagons are bestagons.
- pjmlp 6mo ago
  Except that it won't matter any longer, for most folks GNU/Linux is good enough as headless operating system for embedded and server deployment. Anything else will be taken by derivatives like Android, ChromeOS, or the VMs on top of Windows/macOS.
akagusu 6mo ago
Well, it only took 15 years to someone to fix one of many Wayland design flaws and start to make it feel usable. Now it will take another 15 years for people to settle down in a set of common protocols instead of writing their own extension protocols and others 15 years for window managers to mature at the same level of the X11 window managers. Then, people who think they know better than everyone else will throw Wayland away and start from zero all over again.
- ChocolateGod 6mo ago
  If you reinvented Wayland, there's little reason you would t get the same thing. The "limitations" are political, not technical.
- pjmlp 6mo ago
  Which is why WSL and Virtualiztion Framework have become the best way to have the Year of Desktop Linux, I really don't bother any other way. I thought I still did as my travel netbook died, but then I ended up in UEFI mess, regardless of the distro, and decided in the end to give that role to a Samsung tablet with DEX support instead.
- Zardoz84 6mo ago
  I don't know in what parallel world do you live, but current Wayland it's pretty usable and useful for normal users.
  - akagusu 6mo ago
    I live in the real world where Wayland breaks by design the workflow of lots of people and Wayland people refuse to acknowledge that.
    - prmoustache 6mo ago
      The same way x11 broke the workflow of a lot of people coming to Linux or BSD for decades and the same way I can't use a windows or Mac computer without swearing. You can't expect that everyone will ever be happy, it has never been the case and definitely wasn't when x11 was the default choice. Despite all that, nothing prevents you to stay on X11 so you have absolutely zero reason to complain.
stainlu 6mo ago
[flagged]
- pkulak 6mo ago
  I feel like the word "protocol" is tripping you up. This isn't meant to be some standard that gets a bunch of traction in other projects. It's a protocol for the the River compositor; as the name suggests. Before this there was, I believe, river-layout-v3. It's all just getting taken to the next level; from layout to full window management.
- thayne 6mo ago
  > If Sway, Hyprland, and others each implement their own WM separation protocol I think that's pretty unlikely. The smaller compositors actually collaborate fairly well, and if sway, hyprland, niri, KDE etc. decide to implement this, I think they will probably work with river to create a standardized protocol that works across compositors. That has happened before. Hyprland is maybe more likely to do their own thing than the other, but if a standardized protocol caught on I think they would follow that. Gnome though... I don't think there is a great chance they implement something like this even if several other compositors implement a standardized protocol for it.
phendrenad2 6mo ago
I'm currently using an old window manager that I dug out of the depths of history. 1.0 was released in 1985. 2.0 shortly after. 3.0 a few years later. But version 3.1 was when things really got good. It's been great ever since.
- xyzsparetimexyz 6mo ago
  Vagueposting is a serious offence
ximm 6mo ago
I don't get the frustration with wayland (the protocol) in the comments. This project shows that having a separate window manager was always possible. First we got wlroots as a library that did most of the heavy lifting, and now we got river as an even higher level abstraction. Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get all of this for free, so we shouldn't complain if other people don't do the work that we could do just as well.
- deleted 6mo ago
  [deleted]
- throw_a_grenade 6mo ago
  I'd guess it's because of the general attitude of the project's community, specifically GNOME people and their “my way or highway” style of answering questions e.g. about CSD or other non-critical stuff, not directly related to core protocol. If they were a bit more accommodating to reasonable requests from outside, they'd get less backlash in comments. There's plenty of exemplar behaviour elsewhere in adjacent communities, they could have taken hint multiple times. That they provide this stuff for free would be a good argument if the stuff wasn't pushed down people's throats with no working alternative and Xorg being discontinued.
  - FooBarWidget 6mo ago
    And how would they be able to "push stuff down people's throats" if people could walk away towards alternatives? When such alternatives don't exist, that's exactly how "they do stuff for free and nobody else is putting in the work to make something else" looks like. The problem isn't they "pushing stuff down your throats", it's nobody else (including you) making alternatives that you like better. You are voluntarily ingesting their stuff because your only alternative is starving.
    - suby 6mo ago
      > And how would they be able to "push stuff down people's throats" if people could walk away towards alternatives? It's a forcing of their narrow opinion on what should be allowed onto the ecosystem at large, because all of these things are connected. You can leave to a different DE/distro, but if every DE is doing its own thing for global hotkeys or whatever, then software in the ecosystem is going to be hacky/bespoke or have an unreasonable maintenance burden. Even if you in particular can move elsewhere the ecosystem is still held back. We only recently got consensus on apps being able to request a window position on screen, which is something x11, macos, and windows all allow you to do. CSD and tray icons are other examples of things found everywhere else that they did not want to support. Some applications are just broken without tray icon support. This bleeds over into work for folks releasing software for Linux in general. By not supporting SSD they were pushing the burden of drawing window decorations onto every single app author, and while most frameworks will handle this, it's not like everyone is using qt or gtk. App authors will get bug reports and the burden of releasing software on Linux needlessly climbs again. Hard to convey how unreasonable I feel their stance was on tray icons / SSD. It should be the domain of the DE from a conceptual but also practical point of view, even from just the amount of work involved. It reminds me of LSP's enabling text editors to have great support for every language. And again, Gnome was the odd man out in this, they want extra attention and work when Linux is the lowest desktop marketshare by far, and they themselves are not the overwhelming majority but they are large enough that you really do need to make sure your software runs well on Gnome even if you want to support Linux. People think Gnome push stuff down your throat because they have the power and influence to impact the ecosystem, and they use that power and influence to die on absolutely absurd hills.
itvision 6mo ago
Yay, https://gitlab.freedesktop.org/wayland/wayland/-/issues/233 https://gitlab.freedesktop.org/wayland/wayland/-/issues/233 I've been heard!
- codethief 6mo ago
  For people like me who get hit by a login wall: https://web.archive.org/web/20250102002250/https://gitlab.freedesktop.org/wayland/wayland/-/issues/233 https://web.archive.org/web/20250102002250/https://gitlab.fr...
throwthro0954 6mo ago
As a 25 year user of Linux I love wayland since cutting over to it about 5 years ago. No tearing ever, which I always had to battle with with X. Certain developers that must interact with the Wayland stack will have to do more work now, and some projects may not still be viable, I get it. I've been following the comments in Linux forums for years. But users exist too, and here is one data point for you.
- bjoli 6mo ago
  I am still a bit sad that window shading isn't supported. I wonder if I am going to continue saying this until I am like all those people 20 years ago complaining about things they liked in CDE not being available in more modern DEs.
  - gf000 6mo ago
    What do you mean by window shading?
    - pjmlp 6mo ago
      Basically something that us grey beards like in several window managers, it is not supported in GNOME since the version 3.0 reboot, and relates to minimizing a window to the title bar. You can move the title bar around, and depending on the window manager either double clik to drop down again its contents, or by leaving the mouse pointer for a few seconds hover it, it will temporarly reveal its contents. https://en.wikipedia.org/wiki/WindowShade https://en.wikipedia.org/wiki/WindowShade
      - chriswarbo 6mo ago
        Yeah, it took me a while to discover that it was removed from KWin. (I eventually ended up reading the sources). It didn't help that KWin also does 3D effects, so all of my Web searches for "shading" were returning results for "shader" :-(
        6mo ago
sylware 6mo ago
One bloat and kludge zealot... those guys are the enshitific*tion/planned obsolescence daemons.
egberts1 6mo ago
Still waiting for that magical single login, activating many window managers across multiple PCs. Also, protect screenshot with permissions.
trekkie99 6mo ago
Really like River. Written in zig btw, which is something to potentially consider given the language’s adolescence. By default river ships with rivertile as its wm which is quite limited (no monocle layout or per tag configuration). Rivercarro is a fork of rivertile that adds these settings and others so I’d recommend starting there. I also just really enjoy doing all the configuring by default with a shell script.
lproven 6mo ago
FWIW I wrote about this last month on El Reg: https://www.theregister.com/2026/02/11/river_wayland_with_wms/ https://www.theregister.com/2026/02/11/river_wayland_with_wm...
DVRC 6mo ago
So far this is one of the most interesting approaches to Wayland compositor implementation. I always felt that the "monolithic design" (compositor + window manager) is a step backwards, and that many compositors neglected features like server side decorations (which make easier to have a consistent look & feel). The NeWS book at page 35 has a picture explaining the structure of the CMU Andrew Window System: the window manager on top of the "base window system" (assuming protocol and logic), which sat on the graphic library, and applications connected to it through sockets. A limit was that the window manager was fixed, so you couldn't change its policy/look and feel without having the sources and recompiling it (and here I wish the source code was available). Wayland it's kinda similar, but most of the graphic layer is moved from the server into each application (where each one use its own). Unless you have a compositor that is designed to be extensible out of the box, a set of widgets will be needed if you don't ship a desktop environment, and each one is a separate system process (for example: toolbar, clipboard manager, status bar, wallpaper). Another limitation is its "static" protocol, in the sense that you cannot extend the compositor at runtime loading extensions (you have the XML which is used to generate the stubs for the implementation in the compositor AFAIK). This can prevent applications that use them to run on compositors that don't implement them. On the other hand, systems like NeWS, GMW (a window system from Kyoto University, ASTEC and Omron) and the one described by Rob Pike in "A concurrent window system" are interesting for these reasons: - runtime extension loading code: new functionalities to the server can be added when needed - code as a protocol: instead of sending "raw data" and requests, equivalent pieces of code are sent, allowing for compression and to offload a portion of the logic to the server (or even have applications that run inside the server). This can also allow to have applications that run on remote machines, which download the code for the interface to the server. - concurrency: their programming model is structured around "lightweight processes" (or equivalent), which allow to decompose the interaction in independent tasks, which can eventually interact by sending messages/events or sharing resources. I think it's worth re-investigating this kind of design, considering also the technological advancement (like the evolution of graphic hardware, multicore CPUs, touchscreens, ecc) and challenges (including security). It would be interesting something like NeWS but a bit more abstract and capable of supporting whatever graphic model you wish.

344 points by dpassens 6mo ago

Loving the Canoe window manager concept/screenshot. I long for such a simple UI and will try out river on my thinkpad.

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 6mo ago
>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
- gzread 6mo ago
  The Xorg codebase still includes some of those old drivers and is structured to allow them to exist.
  - jauntywundrkind 6mo ago
    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 6mo ago
      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.
      - jauntywundrkind 6mo ago
        X's drivers still wrap the kernels drivers in its own abstraction layer. It's vastly deeper than what Wayland does.
  - pmarin 6mo ago
    Just to be clear the hardware abstraction layer used by wayland and any current Xserver is exactly the same.
- wmf 6mo ago
  That's what the anti-Wayland people want: for things to work exactly as they did in the 90s. It's not an accident.
ChocolateGod 6mo ago
> 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. It's also possible to use hardware planes to get the actual graphics device to composite for you directly from its video memory, effectively reducing latency to the lowest possible.

asveikau 6mo ago

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 6mo ago
You can do that already with libraries such as wlroots or Smithay
- MarsIronPI 6mo ago
  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 process, so this works fine) and telling it how to position windows. Whereas on Wayland, this is not possible without re-implementing a standalone compositor process, because otherwise architecturally it doesn't work. Emacs can't both do the drawing and be drawn.
  - tazjin 6mo ago
    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 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-pkgs/reka https://code.tvl.fyi/tree/tools/emacs-pkgs/reka This one could technically be written in plain Emacs Lisp, but I'm happy to use something that already has all the XML codegen stuff for Wayland figured out. Dynamic modules work pretty well, fwiw.
    - 6mo ago

mikkupikku 6mo ago

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 6mo ago
You could use xlibre, although some people say it's a joke
- anthk 6mo ago
  Just use Xenocara and stop reusing LLM slopware.
  - LeFantome 6mo ago
    Does Xenocara run on anything other than OpenBSD?
    - bandrami 6mo ago
      Void had a port in the works at one point
- messe 6mo ago
  The reactionary fork started by an anti vax nutcase? Yeah. It's a joke at best. At worst it'll foster an utterly toxic community.
gf000 6mo ago
Yeah I'm sure coding agents will be able to accurately find some non-obvious bugs in such a big and complex code base as X server.
- mikkupikku 6mo ago
  Yes, I think so too.

oofbaroomf 6mo ago

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.

locusofself 6mo ago
BSP?
- rvrb 6mo ago
  Binary space partitioning
arikrahman 6mo ago
I encountered similar setbacks with hyprland (https://github.com/ArikRahman/hydenix https://github.com/ArikRahman/hydenix), and I eventually wound up preferring scrollable tiling managers. I restarted from scratch with niri, and have found it to be a stable platform to develop against. Here's my current dotfiles (https://github.com/ArikRahman/dotfiles https://github.com/ArikRahman/dotfiles)
lloeki 6mo ago
> tile windows to equal areas instead of BSP by default hy3? https://github.com/outfoxxed/hy3 https://github.com/outfoxxed/hy3 (I'm an ex i3/now sway user and hy3 is the only way I can bear using hyprland)

Babkock 6mo ago

[dead]

wild_egg 6mo ago

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.

badgersnake 6mo ago
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.
- bandrami 6mo ago
  Sort of. If your software wants to do something like "know where the pointer is" it won't work on sway.
  - Gigachad 6mo ago
    Why would I want software to know where my pointer is other than when the pointer is over the software's window?
    - bandrami 6mo ago
      Well, in my case, because the VCF on my synth sets its cutoff frequency based on the pointer's Y position and its resonance based on the pointer's X position
      - badgersnake 6mo ago
        Sure, but that is pretty niche. My point was it’s pretty low friction for most people and certainly to try it. But obviously be pragmatic, if it doesn’t work for you because you have a particular requirement, or even if it doesn’t offer any improvement over what you have then don’t use it.

davispeck 6mo ago

[flagged]

koolala 6mo ago
Are you human? If yes sorry for the offensive question. Your account is new.
- davispeck 6mo ago
  [flagged]
  - koolala 6mo ago
    Hi thank you sorry. Welcome to HN comments! Glad to have your voice here.
    - pwdisswordfishy 6mo ago
      You have been bamboozled.

SilentM68 6mo ago

Insightful article. I don't recall ever viewing an easy-to-follow lesson, tutorial or book for that matter that clearly explained the various components of a Linux Desktop environment. Always had to follow complicated and obscure guides to do this and that, when solving issues, but seldom did any explain their functions clearly.

elfalem 6mo ago
Same. This was the first material I came across that clearly and concisely explained DEs in a way that just clicked immediately.

Lerc 6mo ago

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

_flux 6mo ago

To me, this is the first time Wayland feels like it's not a waste of time. The display server does not need to have the complexity of window managing on top the surface management. I certainly share the author's sentiment: > Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance. Although I'm not sure if it was the least resistance per se (as a social phenomenon), but just that it's an easier problem to tackle. Or maybe the authors means the same thing. (That and the remote access story needs to be fixed. It just works in X11. Last time I tried it with a system that had 90 degree display orientation, my input was 90 degrees off from the real one. Now, this is of course just a bug, but I have a strong feeling that the way architecture Wayland has been built makes these kind of bugs much easier to create than in X11.)

jbritton 6mo ago
On X11, the window manager handles the window decorations. So splitting them is going to involve some possibly non-trivial messaging and config.
- vidarh 6mo ago
  That's purely convention. It doesn't need to be the case. There's no functionality that enforces or depend on that.
hedgehog 6mo ago
Remote access on X11 is a mess and I won't miss it, at least on Wayland everyone is funneled through EGL or Vulkan and there's a reasonable path to layering remote access on top of that.
- GuB-42 6mo ago
  X11 remote access have worked really well for me. And the best part is that it worked even when the client machine has no graphical subsystem installed. I can launch GUI applications remotely with a non-privileged account and it shows on my machine as if it was native. Wayland can use RDP and some other remote desktop protocols, but it is not what I want, I want a window, not a desktop. There is Waypipe now, I heard it works fine now, but I am still doing "ssh -X", because it just works. The problem with Wayland is that it is very much "batteries not included". To all the things that worked well in X11, the response has been "it can be done, our protocol is very flexible, ask the guys writing the compositor", not "that's how is done". The result, Wayland is 18 years old and it is only starting to work well, with some pain points still remaining, and display forwarding is one of them. It is funny you mention a "reasonable path" by the way, as it is exactly that problem, I don't want a "reasonable path", I want it to work, and after 18 years, I think it is a reasonable expectation. To their credit, it seems we are getting there: waypipe, and now window managers, we may finally have feature parity.

csb6 6mo ago

Wasn't one of Wayland's key design features combining the window manager and compositor? I am not too familiar with its history but surely there have been presentations or papers about the Wayland designers' reasoning for doing so.

wmf 6mo ago
When the window manager is a separate process with async communication between the WM and display server things can get out of sync for a frame or two which leads to visual artifacts. In Wayland the window manager works synchronously with the compositor so that it's never out of sync.
- csb6 6mo ago
  Yeah, that makes sense. It seems like instead of introducing another IPC protocol like this project does, there could be a compositor that loads different window managers as plugins. Then everything is in the same process and there is no need for async communication. Of course a crash in the window manager would take down the compositor, but this is already true for Wayland compositors that combine both.
  - sly010 6mo ago
    ... or the WM loads the compositor, or the WM links to a compositor library (i.e. wlroots). The point is there are options... Honestly, every time this topic comes up, I feel like the person complaining just doesn't want to put in the work and they are angry that they don't get an easy win. And maybe that's a good thing. Do we really need more half baked WMs?
  - WhyNotHugo 6mo ago
    > 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).

hparadiz 6mo ago

Lots of weird misinformation in the comments here. Wayland doesn't choose anything. It leaves the compositor to decide where to position a window and whether or not that window receives key presses or not. The program can't draw wherever it wants or receive system wide keystrokes or on behalf of another program. When appropriately implemented the screenshot system is built directly into the compositor. It's an API that let's a program request read access to a part of the screen and the compositor provides upon approval. It's much more secure that way and it works perfectly fine these days. Unfortunately not every compositor implements this. However if you really really really wanna side step this you can look at keyd - https://github.com/rvaiya/keyd https://github.com/rvaiya/keyd A project that has a daemon run in the background as a root service and that can provide an appropriate shim to pass key strokes to anything you want. And just to be clear the appropriate secure model is to have a program request to register a "global" hot key and then the compositor passes it to the appropriate program once registered. This is already a thing in KDE Plasma 6 and works just fine.

yjftsjthsd-h 6mo ago
> Unfortunately not every compositor implements this. That's kind of a big sticking point. When GNOME, KDE, and eg. Sway all have different screenshot APIs, the (eco)system doesn't work.
- NekkoDroid 6mo ago
  The thing is: they mostly do implement xdg-desktop-portal's screenshot API since that does also handle permission management. In effect the modern desktop is wayland (window communication), pipewire (audio/video), and xdg-desktop-portal (compositor/environment requests) which all kinda have to be worked with for a desktop application.

kyorochan 6mo ago

River was really great even before this split, so I'm very excited to see what happens in the space in the future. I switched to Niri while waiting for it to happen, and I'll probably switch back at some point. If you were an Xmonad user I feel pretty confident in saying River is the Wayland WM for you.

twiclo 6mo ago
I'm still on Xmonad mainly because I've only tried hyprland and it couldn't handle the master/slave stack the way xmonad does. On River, when I create a new window will it be inserted above the current selected window even if the current window is the master? Also, when it was split up what did he call his window manager? Looks like the River repo is just for his display server/compositor
- angus-g 6mo ago
  It has become river-classic: https://codeberg.org/river/river-classic https://codeberg.org/river/river-classic

imiric 6mo ago

I'm very excited about river. I switched to niri a few months ago, and while I like it for the most part, it feels too... busy for my taste. It defaults to a bunch of animations and decorations, all of which I've turned off. I'm happy with my current setup (aside from Wayland quirks[1]), but river's design and simplicity are very appealing. It reminds me of the philosophy of bspwm/sxhkd which I used for years on X11. I do need scrollable tiling now that I've tried it, and I'm happy that there are a couple of options to choose from with river. [1]: Seriously, why does copy/pasting sometimes simply not work?? I often have to copy twice for it to succeed. It's not related to Xwayland -> Wayland apps, and viceversa, or with copying from closed windows, etc. I don't use nor want a clipboard "manager". I just want my clipboard to work consistently. I've read many reports of this same bug on different distros and DEs, and nobody has figured it out. It's infuriating that such a basic feature is half-broken in a project that is 17 years old now!

sourcegrift 6mo ago

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.

Asooka 6mo ago
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"?
- hparadiz 6mo ago
  It's biggest hurdle is having to explain even to tech people on HN that it's actually a good idea to have a UI where a user can approve a screen sharing request. You'd think for folks that claim to care about security that'd be a prime concern. It really is so weird how difficult that is for people to grasp. The implementation is likewise not complicated. Seriously how hard is it to draw a box selector and show an okay / cancel box.
  - yjftsjthsd-h 6mo ago
    If everyone appears to be missing something that's so easy to understand and implement, perhaps they're not missing it. They could have a different security/threat model than you're using. They could be expressing frustrations with being forced to manually approve something every time. They could be hitting dumb bugs in the implementation. There could be different people clamoring for more security and less intrusive security.

hedora 6mo ago

Traditionally, X11 didn’t have compositors, and didn’t need the extra round trip wayland exists to remove. I wonder if there’s space for a project like xlibre (or x.org, if it were revived) to update the x11 protocol to fill whatever gap compositors were meant to fill. For what it’s worth, I’ve been moving all my machines to lxde. Apparently, I accidentally switched back to a compositor free desktop without noticing. High framerate, vsync/tear-free and high dpi work fine. So does fractional scaling, but I disable it. Personally, I’d rather these hypothetical x11 devs focused on reverse engineering hdmi vrr (blocked by lawyers at the moment), and HDR / expanded color spaces.

em-bee 6mo ago
you are looking for https://en.wikipedia.org/wiki/Compiz https://en.wikipedia.org/wiki/Compiz note that compiz is also a windowmanager, so already then compositor and window manager were one unit.
- yjftsjthsd-h 6mo ago
  The compositor and window manager could be one unit. But you can also just slap picom on with any other window manager and that's fine.
  - hedora 6mo ago
    I guess this kind misses the point. I was an early compiz user (wobbly windows, fire effect and all), but, at this point I just don’t miss it (literally: I thought I was running a compositor for the last ~5 years, and just… wasn’t.) The X windows paradigm was fine, and still works great with modern hardware.
baobun 6mo ago
> For what it’s worth, I’ve been moving all my machines to lxde. Any gotchas or regrets? Haven't used it in many years and now considering going all in on making it (scaffolding of) next DE. So looking at the same move.

bandrami 6mo ago

As predicted, we will re-invent X11 one feature at a time. Maybe someday soon a Wayland window will be able to know its own screen position.

fc417fc802 6mo ago
Last I checked the idealists weren't even willing to commit to a virtual 2D rectangular grid of pixels of arbitrary width and height. I think we'll be waiting a while (or more likely using a soft fork of the spec).
- bandrami 6mo ago
  Ah, but now instead of one old difficult-to-maintain way of allowing an application to draw on a rectangle on the screen, we have five (and counting!) new and somewhat incompatible ways to do it. Progress.
  - fc417fc802 6mo ago
    Don't worry, I will personally see to solving this problem once and for all. https://xkcd.com/927/ https://xkcd.com/927/
- Sharlin 6mo ago
  I'm sure we'll shift to hex-grid displays any day now. After all, hexagons are bestagons.
pjmlp 6mo ago
Except that it won't matter any longer, for most folks GNU/Linux is good enough as headless operating system for embedded and server deployment. Anything else will be taken by derivatives like Android, ChromeOS, or the VMs on top of Windows/macOS.

akagusu 6mo ago

Well, it only took 15 years to someone to fix one of many Wayland design flaws and start to make it feel usable. Now it will take another 15 years for people to settle down in a set of common protocols instead of writing their own extension protocols and others 15 years for window managers to mature at the same level of the X11 window managers. Then, people who think they know better than everyone else will throw Wayland away and start from zero all over again.

ChocolateGod 6mo ago
If you reinvented Wayland, there's little reason you would t get the same thing. The "limitations" are political, not technical.
pjmlp 6mo ago
Which is why WSL and Virtualiztion Framework have become the best way to have the Year of Desktop Linux, I really don't bother any other way. I thought I still did as my travel netbook died, but then I ended up in UEFI mess, regardless of the distro, and decided in the end to give that role to a Samsung tablet with DEX support instead.
Zardoz84 6mo ago
I don't know in what parallel world do you live, but current Wayland it's pretty usable and useful for normal users.
- akagusu 6mo ago
  I live in the real world where Wayland breaks by design the workflow of lots of people and Wayland people refuse to acknowledge that.
  - prmoustache 6mo ago
    The same way x11 broke the workflow of a lot of people coming to Linux or BSD for decades and the same way I can't use a windows or Mac computer without swearing. You can't expect that everyone will ever be happy, it has never been the case and definitely wasn't when x11 was the default choice. Despite all that, nothing prevents you to stay on X11 so you have absolutely zero reason to complain.

stainlu 6mo ago

[flagged]

pkulak 6mo ago
I feel like the word "protocol" is tripping you up. This isn't meant to be some standard that gets a bunch of traction in other projects. It's a protocol for the the River compositor; as the name suggests. Before this there was, I believe, river-layout-v3. It's all just getting taken to the next level; from layout to full window management.
thayne 6mo ago
> If Sway, Hyprland, and others each implement their own WM separation protocol I think that's pretty unlikely. The smaller compositors actually collaborate fairly well, and if sway, hyprland, niri, KDE etc. decide to implement this, I think they will probably work with river to create a standardized protocol that works across compositors. That has happened before. Hyprland is maybe more likely to do their own thing than the other, but if a standardized protocol caught on I think they would follow that. Gnome though... I don't think there is a great chance they implement something like this even if several other compositors implement a standardized protocol for it.

phendrenad2 6mo ago

I'm currently using an old window manager that I dug out of the depths of history. 1.0 was released in 1985. 2.0 shortly after. 3.0 a few years later. But version 3.1 was when things really got good. It's been great ever since.

xyzsparetimexyz 6mo ago
Vagueposting is a serious offence

ximm 6mo ago

I don't get the frustration with wayland (the protocol) in the comments. This project shows that having a separate window manager was always possible. First we got wlroots as a library that did most of the heavy lifting, and now we got river as an even higher level abstraction. Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get all of this for free, so we shouldn't complain if other people don't do the work that we could do just as well.

deleted 6mo ago
[deleted]
throw_a_grenade 6mo ago
I'd guess it's because of the general attitude of the project's community, specifically GNOME people and their “my way or highway” style of answering questions e.g. about CSD or other non-critical stuff, not directly related to core protocol. If they were a bit more accommodating to reasonable requests from outside, they'd get less backlash in comments. There's plenty of exemplar behaviour elsewhere in adjacent communities, they could have taken hint multiple times. That they provide this stuff for free would be a good argument if the stuff wasn't pushed down people's throats with no working alternative and Xorg being discontinued.
- FooBarWidget 6mo ago
  And how would they be able to "push stuff down people's throats" if people could walk away towards alternatives? When such alternatives don't exist, that's exactly how "they do stuff for free and nobody else is putting in the work to make something else" looks like. The problem isn't they "pushing stuff down your throats", it's nobody else (including you) making alternatives that you like better. You are voluntarily ingesting their stuff because your only alternative is starving.
  - suby 6mo ago
    > And how would they be able to "push stuff down people's throats" if people could walk away towards alternatives? It's a forcing of their narrow opinion on what should be allowed onto the ecosystem at large, because all of these things are connected. You can leave to a different DE/distro, but if every DE is doing its own thing for global hotkeys or whatever, then software in the ecosystem is going to be hacky/bespoke or have an unreasonable maintenance burden. Even if you in particular can move elsewhere the ecosystem is still held back. We only recently got consensus on apps being able to request a window position on screen, which is something x11, macos, and windows all allow you to do. CSD and tray icons are other examples of things found everywhere else that they did not want to support. Some applications are just broken without tray icon support. This bleeds over into work for folks releasing software for Linux in general. By not supporting SSD they were pushing the burden of drawing window decorations onto every single app author, and while most frameworks will handle this, it's not like everyone is using qt or gtk. App authors will get bug reports and the burden of releasing software on Linux needlessly climbs again. Hard to convey how unreasonable I feel their stance was on tray icons / SSD. It should be the domain of the DE from a conceptual but also practical point of view, even from just the amount of work involved. It reminds me of LSP's enabling text editors to have great support for every language. And again, Gnome was the odd man out in this, they want extra attention and work when Linux is the lowest desktop marketshare by far, and they themselves are not the overwhelming majority but they are large enough that you really do need to make sure your software runs well on Gnome even if you want to support Linux. People think Gnome push stuff down your throat because they have the power and influence to impact the ecosystem, and they use that power and influence to die on absolutely absurd hills.

itvision 6mo ago

Yay, https://gitlab.freedesktop.org/wayland/wayland/-/issues/233 https://gitlab.freedesktop.org/wayland/wayland/-/issues/233 I've been heard!

codethief 6mo ago
For people like me who get hit by a login wall: https://web.archive.org/web/20250102002250/https://gitlab.freedesktop.org/wayland/wayland/-/issues/233 https://web.archive.org/web/20250102002250/https://gitlab.fr...

throwthro0954 6mo ago

As a 25 year user of Linux I love wayland since cutting over to it about 5 years ago. No tearing ever, which I always had to battle with with X. Certain developers that must interact with the Wayland stack will have to do more work now, and some projects may not still be viable, I get it. I've been following the comments in Linux forums for years. But users exist too, and here is one data point for you.

bjoli 6mo ago
I am still a bit sad that window shading isn't supported. I wonder if I am going to continue saying this until I am like all those people 20 years ago complaining about things they liked in CDE not being available in more modern DEs.
- gf000 6mo ago
  What do you mean by window shading?
  - pjmlp 6mo ago
    Basically something that us grey beards like in several window managers, it is not supported in GNOME since the version 3.0 reboot, and relates to minimizing a window to the title bar. You can move the title bar around, and depending on the window manager either double clik to drop down again its contents, or by leaving the mouse pointer for a few seconds hover it, it will temporarly reveal its contents. https://en.wikipedia.org/wiki/WindowShade https://en.wikipedia.org/wiki/WindowShade
    - chriswarbo 6mo ago
      Yeah, it took me a while to discover that it was removed from KWin. (I eventually ended up reading the sources). It didn't help that KWin also does 3D effects, so all of my Web searches for "shading" were returning results for "shader" :-(
      - 6mo ago

sylware 6mo ago

One bloat and kludge zealot... those guys are the enshitific*tion/planned obsolescence daemons.

egberts1 6mo ago

Still waiting for that magical single login, activating many window managers across multiple PCs. Also, protect screenshot with permissions.

trekkie99 6mo ago

Really like River. Written in zig btw, which is something to potentially consider given the language’s adolescence. By default river ships with rivertile as its wm which is quite limited (no monocle layout or per tag configuration). Rivercarro is a fork of rivertile that adds these settings and others so I’d recommend starting there. I also just really enjoy doing all the configuring by default with a shell script.

lproven 6mo ago

FWIW I wrote about this last month on El Reg: https://www.theregister.com/2026/02/11/river_wayland_with_wms/ https://www.theregister.com/2026/02/11/river_wayland_with_wm...

DVRC 6mo ago

So far this is one of the most interesting approaches to Wayland compositor implementation. I always felt that the "monolithic design" (compositor + window manager) is a step backwards, and that many compositors neglected features like server side decorations (which make easier to have a consistent look & feel). The NeWS book at page 35 has a picture explaining the structure of the CMU Andrew Window System: the window manager on top of the "base window system" (assuming protocol and logic), which sat on the graphic library, and applications connected to it through sockets. A limit was that the window manager was fixed, so you couldn't change its policy/look and feel without having the sources and recompiling it (and here I wish the source code was available). Wayland it's kinda similar, but most of the graphic layer is moved from the server into each application (where each one use its own). Unless you have a compositor that is designed to be extensible out of the box, a set of widgets will be needed if you don't ship a desktop environment, and each one is a separate system process (for example: toolbar, clipboard manager, status bar, wallpaper). Another limitation is its "static" protocol, in the sense that you cannot extend the compositor at runtime loading extensions (you have the XML which is used to generate the stubs for the implementation in the compositor AFAIK). This can prevent applications that use them to run on compositors that don't implement them. On the other hand, systems like NeWS, GMW (a window system from Kyoto University, ASTEC and Omron) and the one described by Rob Pike in "A concurrent window system" are interesting for these reasons: - runtime extension loading code: new functionalities to the server can be added when needed - code as a protocol: instead of sending "raw data" and requests, equivalent pieces of code are sent, allowing for compression and to offload a portion of the logic to the server (or even have applications that run inside the server). This can also allow to have applications that run on remote machines, which download the code for the interface to the server. - concurrency: their programming model is structured around "lightweight processes" (or equivalent), which allow to decompose the interaction in independent tasks, which can eventually interact by sending messages/events or sharing resources. I think it's worth re-investigating this kind of design, considering also the technological advancement (like the evolution of graphic hardware, multicore CPUs, touchscreens, ecc) and challenges (including security). It would be interesting something like NeWS but a bit more abstract and capable of supporting whatever graphic model you wish.