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.

I think most smaller Wayland compositors are using a library (wlroots, smithay) for most (?) of the compositing. If using a library provides a few extra options, while still allowing sharing code, it feel like the API boundary was put in the right place.

When there was the 90deg off bug, was that a bug in the compositor or in wlroots?

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.

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

Or maybe it’s desktop environments pulling the ladder up behind them.

On X11, the window manager handles the window decorations. So splitting them is going to involve some possibly non-trivial messaging and config.

> I don't get the frustration with wayland (the protocol) in the comments.

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.

First they said we couldn’t have screenshots because they were insecure. Then they added them back in.

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.

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.

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

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.

> First we got wlroots as a library that did most of the heavy lifting

wlroots is a library for a complete display server + window manager.

It does not separate the two.

It's a shame because Wayland has made complicated what most contributed to the growth of Linux in the last few years: gaming. I still can't run most of my library on Wayland without the added latency of XWayland. It's great if it's one step back to take a big leap, but this feels like two steps back one step forward without much of a plan for parity.

As the sibling comment said, with WSL becoming better and better, it's a dangerous game to play.

If you reinvented Wayland, there's little reason you would t get the same thing.

The "limitations" are political, not technical.

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.

I don't know in what parallel world do you live, but current Wayland it's pretty usable and useful for normal users.

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

> tile windows to equal areas instead of BSP by default

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)

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)

BSP?

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).

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.

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.

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.

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.

From a user perspective it just works, the online issues are all hypotheticals or very specific scenarios. On wayland my computer just works, my displays can have different dpi scales, my video doesn't tear, and programs don't have full access to record the screen and keylog without asking permission.

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.

The hoop I recently jumped through:

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.

> I can make it do basically anything I want

X11 can't do high refresh rates every time that I've tried to do so.

I completely agree. This feels like the typical “open-source developers rewriting something that already works well, then forcing it on people who never asked for it” kind of project.

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.

Many theories. A simple one is that corporations wanted more control. See systemd's rise - not related to wayland as such, but to corporate-driven influence.

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.

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.

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.

Recently I fixed my X11 tearing by simply running a compositor (compton). Not having a compositor didn't prevent xserver from working but it was tearing. I remember that historically it was a mess, some x11 gpu driver even had a "TearFree" configuration option.

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.

Another datapoint: I'm a 20+ year off-and-on user of Linux who was never able to switch to desktop Linux for daily use because of the graphics issues. After recently deciding to abandon Windows for good and suffer whatever problems I would have with Linux, I was pleasantly surprised by the experience on Fedora/Wayland/Gnome. No issues with high DPI, per-monitor fractional scaling, tearing, bad performance, etc. which have plagued my Linux experiences in the past. There are still minor issues with Nvidia drivers, but this is very likely the fault of Nvidia and not the OSS community.

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.

I haven’t had problems with tearing in x11 for 20 years, with or without compositors, on nvidia, amd or intel.

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.

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.

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.

You only need a single implementation that exposes an API for running a WM as an extension.

I don't really get why would it be a good idea to somehow mandate a specific architecture design from the standard.

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.

[flagged]

[flagged]

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

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

you are looking for https://en.wikipedia.org/wiki/Compiz

note that compiz is also a windowmanager, so already then compositor and window manager were one unit.

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

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.

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

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

>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

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

For people like me who get hit by a login wall: https://web.archive.org/web/20250102002250/https://gitlab.fr...

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"?

Vagueposting is a serious offence

Are you human? If yes sorry for the offensive question. Your account is new.

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

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.