This project would satisfy people who really actually want Wayland, but were upset by transitional pains or interactions they had around it and want to stick with X11 just-cause while getting some similar benefits. This arguably does describe some people but not sure it's a whole lot in the long run.
But who knows, maybe this could also make an easier to maintain XWayland some day, or a nice basis for implementing more esoteric X11 bits down the road vs. the older Xorg codebase.
Like, why simple "copy the screen" got suddenly so complicated? Why every WM suddenly needs a bunch of features that before were just handled by display server, where they belong ? Why some(most) WMs handle title bars but GNOME doesn't ? Why someone decided title bar management is optional to window manager ?
X11 might need to go but Wayland have learned no lessons from it. It's just knee-jerk "if X11 done it this way, let's do it differently"
But hey, you can probably run automotive UIs with your desktop compositor.
And Gnome devs are just being silly at this point.
Notably this deployment doesn't use any of the old-gen automotive Wayland cruft like ivi-shell though. It's pretty much the desktop stack now.
It also vastly improved battery on my Dell Pro laptop. 58% battery used in 7h45m (light compilation day, but no suspend).
This is one of my big problems with Wayland; the fragmentation of Wayland imposes an unacceptable cost to picking the wrong DE, whereas with X all my tools for X still work regardless of my DE.
Not for the client, or if you want to write a wm and is forced to write a compositor.
And actually I'm not even even convinced about the server if talking about a minimal server like this that insists on DRI/GBM, and ditches all the old rendering cruft.
Check out Louvre for example. Or Smithay if you like Rust. And if you want a bit more depth, there is wlroots of course (or the hyprland version). It is not really any harder than writing an X11 WM.
(Well, writing an X11 WM that also includes a built-in compositor is a bit more than just the WM, but I'd say still less than writing a Wayland compositor using wlroots or smithay. For example, xfwm4's compositor is around 5300 lines of C, which is... not nothing, but not crazy either.)
> 2025-08-16: dwl IS CURRENTLY UN-MAINTAINED. AT THE PRESENT TIME, I (@fauxmight) DO NOT HAVE THE TIME OR CAPACITY TO KEEP UP WITH wlroots CHANGES.
It shouldn't be hard, all I want to do is fuzzy match window titles to named audio streams in pipewire, but "Oohh noo that's a security flaw!" say the patronizing Wayland developers who care more about making their own lives as developers simple than supporting basic desktop functionality.
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.
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.
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.
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.
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?
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
Tho admittedly kiosk-wm (https://github.com/JOT85/kiosk-wm) is much more succinct.
>Applications will be isolated from each other by default and can only interact with other applications either through a GUI prompt asking for permission, such as with screen recorders, where it will only be allowed to record the window specified or by explicitly giving the application permission before launched (such as a window manager or external compositor).
Wait, what? I tried this last year. I didn't find any way to do this that wasn't dependent on the WM.
You realize that's worse, right? And to be clearer: core Wayland protocol does not have countless ways. It has zero.
Instead of a single protocol with the strong X11 reference X server the wayland compositors pick and choose between libinput, or libei, or libportal with the InputCapture PR, xdg-desktop-portal with the InputCapture interface, some I've probably missed, or maybe you have nothing at all (weston). It's a gamble if your choice of desktop environment and it's wayland compositor's non-core wayland protocols will match up with those the developer for $software chose. On X11 linux everything that works somewhere works everywhere. With the various waylands if you stay within your desktop's ecosystem you'll probably not notice, but go beyond it and you will.
Each wayland desktop pretty much runs it's own compositor with it's own set of third party libs because the wayland core protocol spec is very minimal. I would say incomplete. ref: https://wayland.app/protocols/
You could fork it. X11 hasn't shipped a major release since 2005, the likelihood of a complete overhaul making it upstream was slim to none even in 2009. X11 developers were better-off focusing on stability, and the Wayland devs moved on. There was no conspiracy to kill either project.
(For me this is specifically on Fedora, and I always switch back to X11 from Wayland.)
The only problem I have is with JetBrains IDEs, which seem to have shaky support. They're usable (meaning you can code), but the experience is so wonky that I basically consider they don't support Wayland.
The reason I switched from i3/x11 is that we've got some 27" 5k screens at work that are basically useless at 100%, and Sway handles different scaling settings flawlessly (except for IntelliJ, which seems lost).
I have not tried this myself, so I can not speak from experience, but if they have removed features that people used, then they are in a similar situation as wayland. So I don't see what the difference then would be. Perhaps your analysis was also incomplete?
If it also runs Wayland apps, many may prefer it actually.
It's a bit like the name 'Apollo'; besides the moon landing project, I know like 2 dev projects called that and also there is a sales SaaS platform with that name.
Surely people should run a search first before choosing a name...
It's symbolic.
I remember people naming new software projects this back in the 1980s for the same reason.
They could at least use PhoenX or FenX to link it with X
It was Project Phoenix (resurrection of the Netscape browser). This resulted in the Firebird browser (Firebird and Thunderbird). But Firebird was an existing database that objected to the name. So, we got Firefox instead.
At least that is how I remember it.
An X11 rewrite with some security baked in is an awesome approach. Will be watching!
I’m all for an X12.
If you take the time to read through that (very partial) list of cruft and footguns in X11 it probably makes it a little easier to understand why a clean-slate approach was able to attract momentum and why many hands-on involved developers were relatively tired of X11. Critics would of course respond that backwards compatibility is worth the effort and rewrites are often the wrong call, etc. It's the Python 2/3 debate and many others.
Just... without all that mess that turned out to be at best +/-, at worst outright negative causing problems for everyone involved. And near all of the "advantages" are "the server is built from scratch" not "the protocol was the limitation"
I remember Usenet.
X11 was built for multi-user terminals a kin to today’s Microsoft VDI garbage.
There’s some good. A lot of bad. And some WTF in there.
For example, in python 2 you could explicitly mark unicode text with u"...". That was actively BLOCKED with python 3.0 which supposedly was about unicode support! The irony was insane, they could of just no-oped the u"". I got totally sick of the "expert" language designers with no real world code shipping responsibilities lecturing me. Every post about this stuff was met by comments from pedantic idiots. So every string had to have a helper function around it. Total and absolute garbage. They still haven't explained to my satisifaction why not support u"..." to allow a transition more easily to 3.
Luckily sanity started prevailing around 3.5 and we started to see a progression - whoever was behind this should be thanked. The clueless unicode everything was walked back and we got % for bytes so you could work with network protocols again (where unicode would be STUPID to force given the installed base). We got u"" back.
By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
> [...]
> By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
So it's a great analogy. Wayland started out proudly proclaiming that it intentionally didn't support features in the name of "security" but everyone should "upgrade" because this was totally better, and has been very slowly discovering that actually all the stuff it willfully dropped was useful and has mostly evolved back to near feature parity with Xorg.
It’s always drama and they’re the center of it.
(I’m joking of course, Merry Christmas)
Also happy winter solstice.
In addition, you can offload OpenGL compatibility to Zink (again leaning into Vulkan).
> pull in a group of long term maintainers.
"Use new cool language" seems to be a prerequisite for this nowadays ...
At least Zig is very compatible with C.
Personally, I have a 3200x2400 e-ink monitor that has a bezel that covers the outer few columns of pixels. I use a custom modeline to exclude those columns from use. And, a fractional scaling of .603x.5 on this now 3184x2400 monitor to get 1920x1200 effective resolution. Zero idea how to accomplish this with wayland-- I do not think it is possible, but if anyone knows a way, I am all ears.
I ran into, at least, ten issues without solutions/work-arounds (like the issue with my monitor) when I tried to switch this year, after getting a new laptop. Reverted to a functional, and productively familiar, setup with X.
I'm still using Wayland because it's what came with my distro (endeavour OS, gnome), but it's really strange how it came broken out of the box.
What's missing?
If you took people who absolutely never tried any computing, and gave them macos, windows, and for example Plasma, they would NOT consider windows or macos to be ready for the desktop. If you go 15 years back, even way more so.
even in the early 2000s, windows was so hilariously crappy that you had to make floppy disks to even get to install the thing. If PCs didnt come preloaded with windows, regular users would never ever be able to install it, versus the relative ease a typical linux distribution was to install. This is also one of the large reasons that when their windows slowed down due to being a piece of shit with 1000000 toolbars, people threw it out and bought a new, despite the fact that a reinstall would have solved it.
A Window Manager and Window Server don't come by default with Linux... It's always an install-time option on the major distros.
> even in the early 2000s, windows was so hilariously crappy that you had to make floppy disks to even get to install the thing.
Windows in the early 2000s installed just fine without a floppy directly from CD or PXE booting.
Windows in early 2023 didn't even detect the network card it needed to download network card drivers. After changing mobos I needed to boot into linux to download network drivers for windows...
Windows in early 2025 still uses SCSI emulation to talk with NVMe and only now the server part got a proper driver
Windows in early 2025s still need virtio driver injection to boot properly as a VM without IDE emulation
"Drivers working out of the box" were never windows strong part
There's some truth to this. I've been installing fresh Windows 11s on family computers this holiday season, and good lord is it difficult to use.
The number of tweaks I had to configure to prevent actively hostile programs from ravaging disk read/writes (HDD pain), freezing and crashing, or invasive popups was absurd.
I don't know what "prime time" means here.
edit: apart from, you know. Applications and drivers for random hardware.
It was not a war "which desktop is easier to use", it was "which system can run stuff I need". And if "the need" was "video games and office stuff", your only choice was windows.
Well they certainly manage them better than x11 and wayland. What a fucking nuts thing to say. Are you rms?
Just think through the many different iterations over the years of what the green button on the deco does, which still isn't working consistently, same as double-clicking the title bar. Not to mention that whatever the Maximize-alike is that you can set title bar double click too (the options being Zoom and Fill, buried in settings somewhere) is different from dragging the title bar against the top of the screen and chosing single tile. Which is different from Control-Clicking the green button. Maybe. It depends on the app.
What a mess.
Both of them miss (without add-ons) convenience niche features I cherish, such as the ability to pin arbitrary windows on-top, but at least the basics in Windows work alright and moreover predictably and reliabily. Window management in MacOS just feels neglected and broken.
There may be many other ways in which MacOS shines as a desktop OS, and certainly in terms of display server tech it has innovated by going compositing first, but the window manager is bizarrely bad.
Doesn't windows conflate window and process? That should kick it to the bottom of the bin by default.
> There may be many other ways in which MacOS shines as a desktop OS
May I suggest examining why your keyboard has a "home" key
I mean, maybe you have, but if you are not fussy then at worst MacOS is quirky and Windows and Linux are identical and merely have different icons.
If you pay a little bit of attention you will notice that on linux things seem more flexible and intuitive.
If you are very finnicky, there is nothing that comes close to X11 window managers when it comes to window management flexibility, innovation and power.
X11 window managers were a mixed bag. While there were a few standouts, most of the variation was in the degree to which they could be configured and how they were configured. There may be fewer compositors for Wayland because of the difficulty in developing them, but the ones that do exist do standout.
At least on this we can agree, but windows never had to reboot the window server in my experience
I say let X11 die, bury it, and never let it rise again.
Then we can all focus on making just one display server as good as possible.
X11 was a single, pretty janky implementation. Wayland is the worst of both worlds -- it's cleaned up a little, but it's still kinda janky. In exchange for a little bit of cleanup, mainly around bitmap fonts, it's no longer a unified protocol.
And to top it off -- it kept the worst part of the X11 protocol, the XKB extension, but got rid of input handling entirely, which means that every platform needs to reach for platform specific code to implement reading from the mouse and keyboard.
Yay.
You cannot possibly use this as an argument in Wayland's favor. X11 sucked because it baked everything, including multiple outdated kitchen sinks, into a single Xorg monolith. Wayland sucks because it factors out everything, including really important features, into optional extensions, ensuring that anything more interesting than "draw pixels to a window" will always be different on every single compositor.
So, in theory, we can embrace a rather-minimal X11 implementation that can run the modern UI, including some desktop features missing in Wayland.
The distribution sprawl I largely see as a detriment to the ecosystem.
Run gui apps in your container, local or remote.
Perfect
As a user you can pass `--release` to `zig build` to request release mode. If the application doesn't want to pick for you, you'll get an error and then you can pick for yourself.
In this case, it looks like the author of Phoenix wants to choose ReleaseSafe as the official release mode of the application.
Phoenix is the name of my hometown, btw.
In X11 "screen" has a particular meaning, and only supporting a single screen doesn't preclude multi-monitor support or virtual desktops.
From the README:
At the moment it can render simple applications that do GLX, EGL or Vulkan graphics (fully hardware accelerated) nested in an existing X server.
glxgears on the other hand does work :)
this might make a good alternative to Xwayland though, which can be exciting.
I'm just thinking why did it take me so long to do the switch. I still keep X around, but not sure how long. Like keeping vim around after switching to nvim few years back..
This is interesting to me, why would vsync being enabled mean that the desktop compositor needs to stick around for a full screen app?
This is true, although entertainingly, the "server" part has always been easily confused.
In X11, the "server" runs on your local machine, and the "client" frequently runs on a remote system.
This is because of its mainframe style history and technically it does make sense, it's just that everybody else does things the other way around.
For the people who weren't around in the ancient mainframe times who end up messing with Linux for the first time, this is confusing for a while.
The way most people think about it, "client" is your local machine and "server" is the remote machine that has lots of applications and is potentially multi-user, but X turns that backwards. The big iron is the client and the relatively dumb terminal is the server.
Add to that that the user manages the ssh connection while the X connection is managed for them...
The server is usually a remote machine, especially back in the time when "client-server" architecture was emerging in mainstream (business) vernacular.
This has been true for decades.
Nevertheless, X11 "server" and "client" have confused very smart and highly technical people. I have had the entertainment of explaining it dozens of times, though rarely recently.
And honestly, still, a server is usually a remote machine in all common usage. When "the server's down", it is usually not a problem on your local machine.
[1] https://www.donhopkins.com/home/catalog/unix-haters/x-window...
https://github.com/marler8997/zigx
https://www.youtube.com/watch?v=aPWFLkHRIAQ
Compared to libX11, it avoids dynamic dependencies, uses less memory, and provides better error messages.
We can see innovation in this space.
Next I suppose is porting Motif to Windows.
XLibre is trying to advance the existing implementation which Xorg abandoned, whereas Phoenix is writing a new, compatible server from scratch.
I doubt the XLibre authors understand the X security model, either – they never do, in forks like this – and they've alienated most of the security researchers who might otherwise clean up after them.
Phoenix and Wayback are much more interesting projects, in my book. Wayback's designed to actually work, and I expect it to be production-ready much sooner; but I expect Phoenix to be the more technically interesting project, since it's deliberately breaking from the X11 spec.
That's all this comes down to. Every single fucking last thread about Wayland on HN is this way. Every fucking last one. Tall about the vocal minority. Just absurdity.
You have accessibility complaints and don't care about the coordinated efforts across toolkits to make a material improvement? Okay. But every single god damn other issue is a distro issue and people on HN insisting their Linux trial 10 years ago is still authoritative today. Fucking ridiculous.
Early contributor to sway and cosmic, most of the Wayland complaints you read are handwave-y bullshit, idk what else to say.
On X, I can run tools like xmacro or xdotool to automate the desktop to my heart's content. On Wayland, this isn't supported "for my security" and my remaining options boil down to either using a tool that works one level of abstraction lower (requires root and/or a daemon), or a tool made exclusively for my DE if one even exists. What used to be a cohesive environment with portable knowledge and tools is replaced by incomplete, broken, or outright missing tools and a complete lack of parity across DEs. For what? Am I supposed to be happy about this?
Moreover, people will condescend to you and insist your setup never worked, nobody ever used it, and nobody cares that it's going away. Plus, they state that you are just being difficult, if not delusional, when you say that you are quite happy with how things are. I mean, your way never worked, so how could it have been your way at all? You must be a troll, troll. Stop trolling.