343 points by dpassens 7 days ago | 222 comments on HN
| Moderate positive
Contested
Low agreement (3 models)
Editorial · v3.7· 2026-03-15 22:40:35 0
Summary Digital Access & Participation Champions
This technical blog post announces the separation of Wayland compositor and window manager in the River project, framed as democratizing software development by dramatically lowering barriers to entry for window manager creation. The content champions human rights through free knowledge dissemination, open-source collaboration, improved working conditions for developers, and enabling broad participation in technical cultural production. The author explicitly advocates for removing artificial technical barriers and creating conditions where individuals can exercise creativity and autonomy in professional software work.
Rights Tensions1 pair
Art 19 ↔ Art 29 —Content maximizes freedom of expression and technical knowledge sharing in open-source software, while acknowledging design limitations and protocol constraints that define boundaries of what the system supports (duties and limitations).
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!
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.
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.
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.
Separating the compositor and window manager feels like one of those ideas that seems obvious in hindsight, but the protocol/state-machine design here shows why it took real work to make it practical.
Lowering the barrier for writing Wayland window managers without forcing everyone to build a full compositor seems like a big win.
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.
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.)
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.
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.
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.
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.
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!
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.
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.
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.
The technical design here is solid -- avoiding per-frame roundtrips while still getting frame-perfect rearrangement is genuinely hard to get right. But the bigger question nobody's asking: does river-window-management-v1 have a path to becoming a cross-compositor standard, or will it stay River-specific?
The Wayland ecosystem's fragmentation problem is that each compositor defines its own extension protocols. If Sway, Hyprland, and others each implement their own WM separation protocol (or don't), we end up with WMs that only work on one compositor -- which is exactly the X11 situation but worse, because at least X11 WMs shared ICCCM/EWMH.
The fact that 15 WMs already target this protocol is encouraging, but they're all River-specific. The real test is whether the ext-window-management protocol can get traction in the broader Wayland ecosystem. wlroots gives compositors shared infrastructure at the library level, but shared protocols at the IPC level is what actually enables the ecosystem River is trying to create.
>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
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.
Not only a loss but a key disabler. Having used to having the same customized window manager for decades it's impossible to change to Wayland until there's a fully equivalent interface for managing windows so that everything works as I want from mouse clicks to keyboard shortcuts. Maybe it could be an existing window manager adding support for River, or Wayback layer that reimplements an X11 desktop root on top of a minimal Wayland compositor, but none of the current Wayland compositors even scratch the surface of this.
There's a type of input called "DeviceEvent" which is a bit lower level than "Window event". It also occurs even if the window isn't "active".
Windows and X11 support this, but Wayland doesn't except for mouse movement. I noticed my program stopped working on Linux after I updated it. Ended up switching to Window Events, but still kind of irritating.
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.
I've been on wayland since KDE had it available (like the KDE 5 days) because it offered fractional HiDPI scaling that wasn't buns. As a laptop user, it has been one of the best features of Wayland.
Furthermore, getting stuff like VRR on Wayland working is way easier than X.org. And, Wayland also supports HDR.
Well, that's exactly what the article is about. Wayland put all together into one process I order to avoid unnecessary context switch. This protocol aims to keep the performance advantages of Wayland without giving up on separation of graphics c server and window manager.
I encountered similar setbacks with hyprland (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)
My reason for switching from i3 to sway (about 8 years ago) is DPI support. High DPI is a pain in Xorg, and essentially impossible with heterogeneous monitors.
The migration was a one way thing. Lots of things are smoother and simpler, and not having to ever again touch Xorg.conf has improved my quality of life.
To this day, I still have different monitors with different scale factors.
I'm with you. I haven't had major issues with X11 for a good couple of decades. Ever since I didn't have to manually edit xorg.conf, I forget when that happened.
Granted, my requirements were simple, a laptop and occasionally one external monitor, though the issues I did run into were related to graphics drivers and NVIDIA shenanigans, but not to X11.
Now that I'm on Wayland, I do feel that visuals are slightly more responsive and crisper, but honestly, it wasn't worth replacing a bunch of my programs, significantly altering my workflow, and dealing with numerous new issues I didn't have to deal with before.
Unfortunately, the momentum is now fully with Wayland, and it's only a matter of time until X11 stops being supported altogether. The XLibre project is a noble idea, but a few contributors can't maintain an entire ecosystem on their own.
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"?
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.
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.
X11 has some tricky, imposible to fix (within the confines of the existing protoco) issues because of the seperation between Xserver and window manager. Things like (IIRC) initial window placement and what nots, where ideally the window manager would make choices about things before the process continues, but the reality of distributed systems makes everything hard. Combining some things into an integrated process fixes that, but comes with other issues.
There were probably other ways to fix those issues, but it would still be a fair amount of churn.
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).
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.
> 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.
Content exemplifies freedom of expression by presenting detailed technical analysis, design rationale, and project documentation. Author freely shares knowledge, solicits community feedback, and argues for architectural decisions.
FW Ratio: 57%
Observable Facts
Author publishes complete technical documentation including design constraints, state machine diagrams, and architectural decisions.
Page contains direct links to issue tracker and GitHub, enabling public discussion and feedback.
Author references FOSDEM 2026 talk, indicating public presentation of ideas without restriction.
Content includes invitation for community feedback: 'If you are developing a window manager and have a use-case that river does not yet support please open an issue.'
Inferences
Publishing detailed technical work without commercial intermediaries exemplifies freedom to seek, receive, and impart information and ideas.
Open feedback mechanisms and issue tracking demonstrate commitment to enabling others' expression and input.
Transparent documentation of design decisions respects readers' right to receive comprehensive information.
Content exemplifies participation in cultural and scientific advancement through freely sharing technical knowledge and enabling others to participate in software development (a key contemporary form of cultural production).
FW Ratio: 57%
Observable Facts
River project is open-source, enabling anyone to study, modify, and improve the work.
Author has written detailed technical documentation explaining design decisions and rationale.
Content shares '6+ years of experience working on river and slowly refining the architecture over time,' transferring accumulated knowledge.
Donation information acknowledges cultural contribution model: 'If my work on river adds value to your life please consider setting up a recurring donation.'
Inferences
Open-source software development is contemporary form of cultural and scientific participation available to all.
Detailed documentation enables others to build upon and advance the technical work.
Sharing learned patterns and architectural decisions with community contributes to collective scientific advancement.
Content demonstrates and encourages freedom of association through collaborative open-source development. Author explicitly notes 15 window managers already written for river, showing successful coalition.
FW Ratio: 57%
Observable Facts
Author mentions '15 window managers already written for river,' indicating organized community of developers.
Content describes river-window-management-v1 protocol as enabling independent developers to contribute.
Gallery showcases named window manager projects (Canoe, reka, tarazed, rhine), suggesting attribution and recognition of collaborators.
Author states 'Wayland currently does not come close to the diversity of X11 window managers. I believe that separating the Wayland compositor and window manager will change this,' indicating vision of enabling broader association.
Inferences
Creating architectural conditions that allow independent participation encourages freedom of association.
Recognition of multiple window manager projects demonstrates respect for autonomous groups.
Open protocol design enables developers to associate around shared technical standards without hierarchical control.
Content advocates for freedom of thought and conscience by promoting open-source development where individuals can exercise technical creativity and make architectural decisions based on conviction.
FW Ratio: 60%
Observable Facts
Author presents detailed technical rationale for design decisions without censorship or limitation.
Content explicitly invites disagreement: 'I am open to exploring custom shaders... please open an issue and we will figure out how to get it supported.'
Author shares personal experience and reflections on architecture choices over 6+ years.
Inferences
Detailed technical exposition demonstrates freedom to articulate and defend intellectual position.
Open invitation for alternative approaches respects others' freedom of thought and conscience in technical design.
Content advocates for social and cultural rights through promoting intellectual participation in technology development and enabling professional development as a software engineer.
FW Ratio: 50%
Observable Facts
Author states 'Separating the Wayland compositor and window manager greatly lowers the barrier to entry for writing a Wayland window manager,' explicitly enabling skill development.
Content notes 'with the new river-window-management-v1 protocol writing a basic but usable Wayland window manager over the weekend is now very possible,' enabling rapid professional development.
Author describes improved developer experience: 'Window manager crashes do not cause the Wayland session to be lost. Window managers can be restarted and switched between. Debugging a window manager is much less of an ordeal.'
Inferences
Lowering technical barriers enables broader participation in intellectual and cultural work of software development.
Emphasizing developer experience and learning opportunity demonstrates commitment to people's right to develop their talents.
Making professional development more accessible supports social participation and cultural contribution.
Content advocates for inclusive participation in software development by removing technical barriers. Emphasizes dignity of developers and accessibility of tools.
FW Ratio: 60%
Observable Facts
Author states 'Separating the Wayland compositor and window manager greatly lowers the barrier to entry for writing a Wayland window manager.'
Page displays no authentication walls, paywalls, or access restrictions.
Author explicitly invites community contribution with phrase 'If you are developing a window manager and have a use-case that river does not yet support please open an issue.'
Inferences
Lowering barriers to participation supports human dignity and equal opportunity in technical work, aligning with Preamble values of equality and dignity.
The free and open discussion format respects readers' right to access and engage with information without intermediaries.
Content promotes democratic participation in technology development by lowering barriers and enabling equal participation in decision-making about software architecture.
FW Ratio: 50%
Observable Facts
Author invites public issues and discussions: 'If you are developing a window manager and have a use-case that river does not yet support please open an issue and we will figure out how to get it supported.'
Issue tracker is referenced as the source for understanding planned features: 'The best way to get a sense of what features are planned to be added in the future is to look at the accepted label on our issue tracker.'
Content describes stable protocol that 'we do not break window managers,' indicating commitment to stakeholder interests.
Inferences
Open issue tracking enables equal opportunity for community members to participate in governance decisions.
Commitment to protocol stability demonstrates consideration of public interest over unilateral changes.
Lowering barriers to window manager development democratizes participation in shaping desktop experience.
Content addresses education through enabling learning and professional development in software engineering. Making window manager development accessible over a weekend enables educational engagement.
FW Ratio: 57%
Observable Facts
Article provides comprehensive technical education about Wayland architecture, protocol design, and implementation constraints.
Author states 'with the new river-window-management-v1 protocol writing a basic but usable Wayland window manager over the weekend is now very possible,' enabling learning projects.
Content references FOSDEM talk, indicating dissemination through educational venues.
Author invites open issues and community learning: 'If you are developing a window manager and have a use-case that river does not yet support please open an issue and we will figure out how to get it supported.'
Inferences
Detailed technical documentation serves educational function and enables self-directed learning.
Making professional development achievable over a weekend reduces barriers to education in software engineering.
Collaborative issue-driven development serves as mentorship mechanism for new developers.
Content addresses work and favorable conditions through improving developer experience and enabling people to work in technical fields with reduced barriers and improved working conditions (avoiding Wayland session loss, remote debugging required for monolithic compositors).
FW Ratio: 50%
Observable Facts
Author states 'Window manager developer experience is also greatly improved. A window manager crash does not cause the Wayland session to be lost. Window managers can be restarted and switched between.'
Content notes 'anyone who has written a Wayland compositor knows the pain of debugging issues that only reproduce when running on bare metal (i.e. using DRM/KMS directly), one might be forced to ssh in from a different computer to figure out what has gone wrong.'
Author mentions 'funding support' and donation options, acknowledging the need for sustainable conditions for developers.
Inferences
Improving debugging and developer conditions directly addresses favorable working conditions for technical workers.
Recognizing need for financial support acknowledges importance of just compensation for intellectual work.
Reducing barrier to entry enables more people to access technical work.
Content does not address privacy explicitly, but the discussion of system architecture touches on data flow and kernel-level operations that have privacy implications.
FW Ratio: 50%
Observable Facts
Page displays no cookies, tracking pixels, or analytics disclosures.
Content discusses low-level system architecture including input event routing without discussing data privacy.
Inferences
The technical discussion of input event routing acknowledges information flow through systems, though does not explicitly address privacy protections.
Absence of tracking mechanisms on the blog structure provides minimal practical protection of privacy.
Content implicitly supports rest and leisure by promoting software that improves user experience and developer experience, reducing frustration and stress.
FW Ratio: 50%
Observable Facts
Author emphasizes 'frame-perfect rendering, good performance' and low latency, improving user experience quality.
Window manager diversity gallery showcases options for different visual styles and user preferences.
Inferences
High-performance, feature-rich software enables users to accomplish tasks more efficiently, leaving more time for rest.
Improving developer experience reduces occupational stress and enables better work-life balance for technical workers.
Content does not explicitly address duties or limitations on rights, though design constraints could be interpreted as acknowledgment of competing interests.
FW Ratio: 50%
Observable Facts
Author notes limitations: 'The river-window-management-v1 protocol does not support use-cases that deviate from the traditional, 2D desktop paradigm. This means no VR support for example.'
Open-source model implies acceptance of licensing terms and community norms.
Inferences
Explicitly naming protocol limitations demonstrates acknowledgment that not all possible uses are supported, implying duties to respect design choices of others.
Open-source licensing establishes social contract with limitations on use.
No privacy policy or data handling disclosure visible on page content.
Terms of Service
—
No Terms of Service referenced in page content.
Identity & Mission
Mission
+0.15
3 19 20
Author explicitly states motivation to lower barriers to entry for free software development and democratize participation in open-source projects, supporting Article 19 (free expression) and Article 20 (freedom of assembly/association).
Editorial Code
—
No explicit editorial code or ethics statement present.
Ownership
—
Personal blog by Isaac Freund; no corporate or institutional ownership indicated.
Access & Distribution
Access Model
+0.20
19 27
Content is freely accessible with no paywall or authentication requirement. Promotes open-source software development and free knowledge sharing.
Ad/Tracking
—
No advertisements or tracking mechanisms visible in page content.
Accessibility
—
No accessibility features or statements visible in page content.
Open-source licensing and free public blog enable broad participation in cultural and scientific advancement. Author shares both code and knowledge freely.
Open-source project structure and international collaboration (FOSDEM reference, global developer community) implicitly support conditions for rights fulfillment.