> 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.)
There were probably other ways to fix those issues, but it would still be a fair amount of churn.
X11's extension mechanisms can - and has - been used to enable backwards incompatible protocol changes. E.g. BigRequest changes the length and format of every single protocol request.
Very few client libraries are only capable of speaking "the existing" protocol if you take that to mean the original unextended X11 protocol.
Adding an X11 extension that when enabled cleans up a lot of cruft would not have been a problem.
> where ideally the window manager would make choices about things before the process continues
Nothing stops you from introducing an extension that when enabled requires the client to wait for a new notification type before continuing, or re-defines behaviour. That said, using my own custom window manager, I don't know what you mean here. My WM does decide the initial window placement and size, and it's the clients damn problem if it can't handle a resize before I allow the window to be mapped.
The X protocol is crusty in places, but it is very flexible. People haven't fixed these things because they chose to invent compatibility hindrances that weren't real when their response was to invent an entirely new protocol with no compatibility at all.
On a tangent, also very ironic that X (the successor of Twitter) has the exact same logo as X (the window system). It's like Elon Musk just Googled for the first X logo that came along and appropriated that and nobody seems to notice or care.
When there was the 90deg off bug, was that a bug in the compositor or in wlroots?
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.
Or maybe it’s desktop environments pulling the ladder up behind them.
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.
They took a firm principled stance against screenshots to start with, which set them up for the COVID WFH wave. Then we've got this questionable design that seems hard to make accessible since accessibility is a security risk and we're heading right into Agentic AI which will be interesting. I've been avoiding the Wayland ecosystem for as long as I can after the initial burn and it'll be curious to see how well it supports bringing in new AI tooling. Maybe quite well, I gather that Pipewire is taking over the parts of the ecosystem that Wayland left for someone else and maybe the community has grown to the point where it has overcome the poor design of Wayland's security model by routing around it.
My guess is the frustration is coming from a similar perspective because it is a bit scary seeing Wayland getting picked up everywhere as a default and the evidence to date is they don't really consider a user-friendly system as a core design outcome. Realistically Wayland is 2 steps forward even if there is a step back here or there. The OSS world has never been defined by a clean and well designed graphics stack.
As ordinary user, I actually don't care about any of this. However, from another perspective, I think this is a bad thing—open source projects have become product-centered, defaulting to the assumption that users are ignorant fools. This isn't how community projects should behave, but those projects is not that community-driven anyway.
After all, for a long time, so-called security has only been a misused justification—never letting users make mistakes is just a pretty excuse, meant to keep users from being able to easily access something, and eventually from ever accessing it at all.
I'm not a fan of ADA ambulance chasers on principle, but I wouldn't shed a tear see them be able to go after the bigcos that made this mess (e.g. IBM).
Next, it was accessibility APIs and I guess copy paste is still flaky.
Now, it’s window managers.
What’s next, Remote Desktop?
The whole reason given for wayland’s replacement of x11 was that those things are all fundamentally bad ideas.
It’s been 15 years. Linux desktops are more fragmented than ever, and they’re still going forward with mass deletion of legacy x11 applications.
The only benefits to end users are things like HDR, or backporting a compositor feature or two, which X11 could easily be extended to support.
Instead we get two decades of the digital equivalent of book burning for reasons no one understands.
And variable refresh rate, better fractional scaling (and per-monitor scaling), atomic updates, native touch & gestures. And the isolation/sandboxing is important. The problem is Wayland didn't have portals in the beginning (hence the screenshot issue).
Wayland isn't the problem. The pace at which distros (and GNOME, lets be real who is behind the push here) started stripping out X11 was too fast, and too early.
> for reasons no one understands
Reasons are sadly typical for FOSS: from the start the devs were focused on their favorite use cases with no communication with end users to figure out theirs.
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.
because the devs actually have implemented things that i cared about
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.
Wayland is 17 years old. At this point, it's almost more frustrating to have one of its bigger architectural problems potentially addressed, precisely because it shows that it was always possible, and the people pushing for its adoption just... didn't bother doing the things that would make it easier to adopt.
wlroots is a library for a complete display server + window manager.
It does not separate the two.
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.
As the sibling comment said, with WSL becoming better and better, it's a dangerous game to play.
The "limitations" are political, not technical.
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.
If you were an Xmonad user I feel pretty confident in saying River is the Wayland WM for you.
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
Simple example of how impactful this separation has been for me.
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)
Anything else will be taken by derivatives like Android, ChromeOS, or the VMs on top of Windows/macOS.
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.
Furthermore, getting stuff like VRR on Wayland working is way easier than X.org. And, Wayland also supports HDR.
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.
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 haven't touched xorg.conf in decades. I suppose you might have to do it to configure some unique setup, but for me this hasn't been an issue in a long time.
Now with Wayland, instead of having to touch a single config file, we have to learn how each compositor/WM is configured, and do it there instead. It hardly seems like an improvement in that regard, IMO.
Unfortunately you will never find yourself in a situation to actually use a mixed dpi X11 setup (you lose your homogeneous desktop) and Wayland is better at spoofing it (for whatever reason fractional scaling works better in Wayland).
http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/
My favorite quote from that writeup.
"If you think this idea is a bit stupid, shed a tear for the future of the display servers: this same mechanism is essentially how Wayland compositors —Wayland being the purported future replacement for X— cope with mixed-DPI setups."
That’s not a reason to do it of course, for me the driver was support for multiple monitors with different scaling requirements.
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.
Meanwhile if you have root you're still free to do so directly.
X11 can't do high refresh rates every time that I've tried to do so.
It will take years to reach the feature set of X11. And for what? From my perspective as both a developer and a user, I see no tangible benefits.
On top of that, it breaks software I rely on professionally. Code that worked perfectly fine under X11.
Meanwhile, I can still build and run Windows programs I wrote 30 years ago on Windows 11.
I am not saying all of the design is corporate-controlled. But a ton of propaganda is associated with how wayland was advertised, until some folks had enough with it and decided to stop buying the "xorg is dead" routine these corporations push on:
https://github.com/X11Libre/xserver
It will be interesting to see what will happen though. The GTK devs said they will help kill off xorg with GTK5. KDE also wants to kill xserver. It would be kind of cool if that would not happen - imagine if a non-corporate controlled ecosystem would emerge. Not likely to happen, but it would be a lot of fun. As well as more real competition with wayland. Wayland broke its biggest promise: that it is a viable alternative to the xorg-server. I don't want to lose any feature, so it is a drawback for me.
But already a majority of Linux desktop users have stopped using it. And it will be 90% in the next 2-3 years. GNOME, KDE, Budgie, and COSMIC are effectively Wayland only now and XFCE and Cinnamon will be Wayland native before then.
The GTK5 devs do not have to “kill off” X11. But it is not really worth their time either.
Keep using Xorg, or Xlibre, or Phoenix. It should keep working.
But don’t mind if the rest of us keep building on Wayland.
By the way, I use Niri, a very cool and absolutely non-corporate Wayland compositor. Not sure how that fits into your narrative.
> 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.
Whatever ideological debates there are underneath the X vs. Wayland divide, ultimately what I care about is things working as well as or better than other mainstream operating systems, and Wayland seems to deliver on that.
Each driver spells the TearFree / vsync option differently in the config. They probably should have just enabled it by default, since there is no downside.
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.
https:/github.com/X11Libre/xserver
Or build on River as this article suggests.
I don't really get why would it be a good idea to somehow mandate a specific architecture design from the standard.
Every "flexible" API turns into a leaky mess unless someone is paid to write the dullest test suite in existance, and nobody is. Mandating one design is ugly, but pretending composition is free is a fairy tale.
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.
It's not easy and the major compositors (Gnome, KDE) are NOT wlroots based, making this point mostly moot anyway.
This protocol at least has a chance of using a custom WM with an advanced compositor (which wlroots is not).
I'm glad River is trying to create a bigger base here; this is way cool. And it sort of proves the value of Wayland: someone can just go do that. Someone can just make a generic compositor/display-server now, with their own new architecture and plugin system, and it'll just work with existing apps.
We were so locked in to such a narrow limited system, with it's own parallel abstraction layer to what the kernel now offers (that didn't exist when X was created). It's amazing that we have a chance for innovation and improvement now. The kernel as a stable base of the pyramid, wlroots/sway as a next layer up, and now River as a higher layer still for folks to experiment and create with. This could not be going better, and there's so much more freedom and possibility; this is such a great engine for iteration and improvement.
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.
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.
note that compiz is also a windowmanager, so already then compositor and window manager were one unit.
However if you really really really wanna side step this you can look at 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.
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.
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.
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!
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.
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
https://www.theregister.com/2026/02/11/river_wayland_with_wm...
I've been heard!
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!
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.
