This definitely doesn't match my memory, and I was there :) Most of the good reasons remain unavailable in X11 to this day.
There definitely were some attempts to advance X11 that post-date Wayland, most notably the proposals by Keith Packard, but they never got much traction.
You two here don't mention any of the reasons. It is hard to discuss this when there are no specifics, so what was needed, and what was not added?
I ran XMonad for 15 years, but recently switched to river and am loving it.
fwiw, Xorg already had this, since you can set the DPI for each display through RandR/xrandr. In both X11 and Wayland it's up to the toolkit to actually detect the setting and rasterise accordingly.
Wayland actually went backwards in this respect by using "integer scales" (eg, 1, 2, 3) instead of fine-grained DPIs (eg, 96, 192, 288), so using a scale of 1.5 would result in downscale blur (toolkit sees scale as 2, then the compositor scales it down to 75%), whereas in Xorg you could just set the DPI to 144, and the toolkit could theoretically render at the correct resolution. As far as I know Qt was the only toolkit to actually do this automatically, but that's not X11's fault.
Wayland has at least since fixed this in the form of "fractional scaling" [1], but here's [0] an old thread on HN where I complained about it and provided screenshots of the resulting blur.
[0] https://news.ycombinator.com/item?id=32021261
[1] Doing some quick searching it seems like this is still unsupported in Gtk3/Gtk4, maybe planned for Gtk5? Apparently Firefox has only just added support (December 2025), 3 years after the fractional scaling protocol was released. Seems ridiculous to me that Wayland failed to get this right from the start.
Well if three independent programs have to coordinate to make it work, then I would state that it do not support it at all.
I guess the "third" program would be something like xrandr, so the Wayland analogue to that would be wlr-randr (for wlroots compositors), or some other DE-specific tool for configuring screen sizes. Again there's no fundamental difference here.
[0] https://wayland.app/protocols/fractional-scale-v1#wp_fractio...
These days Xinerama is the only mainstream tool for dual head, but there used to be others. Nvidia Twinview was one. I bought my first dual head box in 1996 with two Matrox Millennium cards (although it mainly ran NT4) and those cards later went into my dual Athlon XP machine. That ran SUSE until Ubuntu came out.
Xinerama isn't a sine qua non. It's just easy so it became ubiquitous. Maybe it's time to replace it.
The annoying thing about the other things you mention is that they honestly are not that difficult to fix.
The X server can throw an error (or just silently ignore it) when one client passes the window of another client and button/key events in the mask to XSelectInput(). And the Xinput2 bits that allow for receiving all key and button events can be changed to only send events destined for windows in the same client. There: input snooping is fixed.
Lock screen awareness can be fixed with new requests/events in the MIT-SCREEN-SCREENSAVER extension (or, if that's fraught, a new extension) that allow an app to create a "special" lock-screen window, which the X server will always stack on top, and send all events to. (That new functionality should probably allow for child windows and popups for input methods as well.) This is honestly not hard!
And yes, some applications will break when you do this. But I cannot see how that's not significantly better than creating an entirely new display protocol that everyone has to port to.
There are other issues with X11, of course, mainly in the graphics pipeline (e.g. the compositor should really be in the X server), but it's hard to believe these things couldn't be fixed. It feels like no one really wanted to do that: building something new from scratch that (in theory) didn't have all of the mistakes of X11 would be more fun, and more rewarding. And I get that, I really do. But Wayland has created so much work, so many thousands (tens of thousands? hundreds of thousands? million+?) of developer-hours of work for people that maybe could have been better spent.
So I think Phoenix is a great idea. It's basically "X12"[0]: removing the old cruft and making breaking changes to fix otherwise-unfixable problems. I imagine most modern, toolkit-using X11 applications would work just fine with it, without modification. Some -- perhaps many -- won't... but that's ok. Run a nested, rootless X11 server inside "X12" if they can't be fixed, or until they're fixed.
[0] Yes, I know that an X12-type thing was considered and rejected (https://www.x.org/wiki/Development/X12/), but I still think it's a better idea, after a decade and a half of Wayland still not being able to support everything we need to port Xfce's components and maintain all of their features.
What features is Wayland the protocol missing to allow supporting Xfce?
They convinced their employers Wayland would be better?
> Xscreensaver/lock screens on Qubes are still broken.
Most people aren't nation-state-level targets and don't worry about security to that degree. But they do like global hotkeys.
For local state, it's easier to just install a wireless camera and watch your screen from behind: it leaves no trace on your computer (you may spot it wireless connection, if you lucky). Moreover, they are more interested in your communication devices (your smartphone) than in your desktop.
Foreign states may exploit your notebook builtin "anti-theft" system, Intel Management Engine ("intel" is very good name for a CPU ;-), bugs in NVidia firmware (fonts, OpenGL, etc), bugs in hardware (create a second display to mirror image from primary display to, even when physical display is not attached, for example), etc.
However, I saw that my Firefox window was spied by Chromium window few years ago (I recorded it on Youtube), so this problem in X11 is real.
It is when you are essentially putting bars in front of your windows while leaving the front door unlocked, i.e. you are making things worse in the name of security while not actually providing any additional security.
> Yeah, but with how we’re moving towards running each (desktop) application in its own cgroup, thus restricting what syscalls any given application can do
Who is we? I don't want or need any of that on my free software system.
Also, this level of security is wanted even on a "I don't want my sister to look at my stuff" level, no need to go nation-state level.
I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else. Yes, X provided functionality that now WMs get to implement themselves - since the developers of Xorg worked closer to Gnome and Qt people, and Gnome and Qt people were OK with this, this didn’t feel like a horrible trade off. And given the diversity of Wayland window managers today, I don’t think it mattered all too much.
> I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else.
"I think the owners of the Internet infrastructure would be the best people to choose what websites I'm allowed to visit"
No, the users have spoken and continue to speak up that Wayland doesn't serve their use cases.
It is the same, yet some uppercase characters are not supported when entered via a yubikey. This has been marked as a WONTFIX. This is rather sad, because I can enter the same password in a TTY with no issues.
The most active implementation (particularly in the early days) is probably wlroots, started by Drew deVault (again in his free time), who is often quite vocal against corporate control.
In fact the large desktop environments, which are much more under "corporate control", were comparitavely slow to adapt wayland IIRC.
So instead of repeating this accusation, maybe actually give some evidence?
I thought everybody knew Wayland was started by some people working on Xorg already; I did not mean to imply otherwise. Many or all were paid for their work. They believed Wayland was a better approach, and, AFAIK, at some point switched to be paid full-time to work on Wayland instead of X. Which, sounds a lot like they convinced their employer (or a new employer) to pay them to work on Wayland instead of X. Do you believe this is a fair summary of the situation?
Sorry for my combatitive before. I definitely interpreted your previous post differently and I think your clarification is a fairer assessment of the situation. I would still argue that the majority of people implementing the wayland protocol are not paid by their employers to do so (this might now have changed a bit with smithay, which is sponsored by system76 I believe).
Then you'd be wrong. Freedesktop is essentially RedHat and friends.
My understanding from the outside is that this didn't happen, that Wayland is a spec without a reference implementation - that they didn't actually build anything and are leaving the difficult part up to everyone else.
I remember people complaining about the GTK file picker not having a preview for more than a decade, and at some point it sort of became a meme.
When it finally got added, the PR was like a 2-300 lines.
The "isolating windows from each other" stuff in Xlibre for example is the Xnamespace extension, which requires a static config file up front and lets X clients within the namespace interact as before. This may have some utility for specific scenarios (dunno, kiosks maybe?), but is nothing like Wayland's default security model.
Similarly, enabling TearTree in the modesetting driver and having another backbuffer in the driver is a huge crutch vs. having a proper architecture where the compositor can own presentation timing. For one it makes adaptive sync/VRR a lot trickier.
These things are overall not equivalent.
few years after even that wasn't required.
Yeah it missed some features I could theoretically use in 2025 but I didn't had different DPI/refresh rate displays back then and those could probably be put into X11 protocol just fine
It learned no lessons from X11. It made most things harder to write and pushed more things that really every WM needs and doesn't care much to implement differently to WMs making them harder.
For example, stuff like "WM need to manage raw inputs, so they can have more power over them" is cute on paper but in reality most of them don't want to because there is no benefit to reinventing that part. Sure, that part in X11 could be better, maybe it should have better interface for WMs to configure common options in common way without getting into input-driver-specific options, but that just required rework of the idea, not throwing it into the bin and replacing with near entirely worse framework that wastes everyone time.
I think one of the intrinsic problems with relying on developers being paid by their employers is they can easily become personally disinvested from the thing they're maintaining; they get paid well, the day-to-day grind gets stale, they get interests and hobbies other than computing but keep working on the thing because it's their job. Eventually they find that just buying a Mac is an easier lifestyle at home, and gradually maintaining X transforms from something they do out of passion for the project into something which is just a job. So they look for ways to make their job easier, hit on the classic "instead of maintaining old thing it'll be more fun to make our own", and because they are now untethered from the needs of real users they only need to make sure the new thing supports the bare minimum to keep their employer happy. They no longer care how real users feel, any use case that isn't required in the checklists approved by management get deliberately abandoned. So we end up with Wayland lacking common sense desktop features in demand by users for years because it's simply not convienent for the developers who are now dispassionate 9-5ers.
I prefer to take my chances with enthusiasts keeping X working on shoestring budgets. Maybe a few more years of development of coding models will make ongoing maintenance easier going forward and I'll never have to switch. I'm willing to make that bet. If it turns out that in 5 years I am forced to switch, at least by then Wayland will be five years more mature, and maybe my cynicism will even be proven wrong by then and Wayland will be good by then (but I'm not holding my breath for that.) Anyway, I have nothing to lose by using X as long as humanly possible.
One example would be Free Pascal and Lazarus, while there is some commercial support, the overwhelming majority of the development is community-driven and ironically both have a much better history of preserving backwards compatibility than most open source projects backed by larger companies.
Of course exceptions exist for both situations, but as a general rule i find if some project makes a big deal about the company behind them (or even worse, there is a company with the same name as the project) then i tend to look for more community-driven alternatives.
But this is all ok, I think the main problem is that somehow too many in Linux community did not see that the technical arguments for Wayland were not actually too convincing and that giving up decades of compatibility across UNIX systems and beyond is a mistake.
Read this including my response.
A lot of X features are actually Xorg features and they only work because there is a single implementation that everyone tried to integrate with.
Turns out the moment there are two implementations, which is hard on X and easy on Wayland, you can no longer rely on targeting a single implementation for direct integration anymore.
This means a lot of non-X but Xorg features need a protocol extension in Wayland, because things are being standardized that previously were exclusive to Xorg.
It looks like the core X11 protocol spec [1] defines all that's needed, specifically the GetInputFocus, QueryTree and GetProperty messages. You might also want some things from the EWMH spec [2] (e.g. _NET_WM_NAME for UTF-8 or _NET_WM_WINDOW_TYPE to identify top-level application windows) but none of this seems like an implementation-specific X.Org feature.
[1] https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html
Vulkan, various node replacements come to mind.
Wayland at this point has existed almost as long as X11, longer if you only count the Linux years, yet its still not quite there.
After a quick scan, Arcan seems to be pushing a microkernel approach, with some clients providing display server capabilities and others talking to them via shared memory. This will have the same problem as all other microkernels - nice for research, but the extra completely outweights the marginal benefits over a monolithic thing that generally has a smaller API surface to maintain.
For VRR the issue is how current desktop compositors render their output, though it should be technically possible to make a Xorg desktop compositor to use separate outputs for each monitor (may need to use Vulkan with custom barriers for vsync though, this is something i've only ). The alternative is to not use a desktop compositor at all, which is what i'm doing (since i also dislike the desktop lag introduced by desktop compositors). I have a 165Hz VRR monitor that i used it for a bit (even connected a separate 60Hz monitor for a bit) and worked fine, though eventually i disabled the VRR functionality since at 165Hz tearing is almost imperceptible (and it never bothered me even on 60Hz monitors anyway) while my monitor is one of those that have some annoying flickering with VRR enabled. In any case, the issue is with the setup and desktop compositor used, not with Xorg itself.
Of course from a user's perspective all these most likely do not make much of a difference.
For HDR there is no support for it Xorg though. Personally, the main use for HDR would be either some movie or playing a game, i.e. fullscreen apps, and switching to another virtual terminal running a Wayland compositor (or just Gamescope) just for those is perfectly fine - having to press ctrl+alt+f1/f2 instead of alt+tab is not a deal big enough to change the entire desktop setup i've been using for many years :-P.
The future of WMs is, IMO, Arcan - https://arcan-fe.com/ - but that's an ambitious project and I don't blame the main developer for deliberately going out of his way to avoid advertising it before it's ready. In the meanwhile, Wayland and X11 both more-or-less work with the occasional major pain in the ass.