Phoenix: A modern X server written from scratch in Zig
git.dec05eba.com
git.dec05eba.com
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.
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.
> 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.
X11 is backwards compatible, you do not have to "keep up" with its changes.
wlroots seemingly isn't. This is a significant issue when it comes to relying on most 3rd party libraries.
also, for dwl, the issue is that the initial author (not the guy that wrote that notice) is sorta mia, and he has control of the repo on codeberg, so we'd probably need to fork to be safe, and he may not want to take on project lead. (he checks every patch for merge conflicts with one another and upgrade breakages, god bless him lol)
That's certainly one way to say "no longer developed".
Usually things which are "no longer developed" do not have (at least) three implementations in development.
Turns out, the wlroots API is so volatile atm that even the developer of the super small compositor DWL has to throw in the towel for now.
> DWL is more interesting as a learning exercise than something to use.
The same is said about DWM, its xorg counterpart, but I, for one, am a happy user of DWM.
Others are looking to run X11 wm under wayland with wayback, xlibre wants to keep it moving forward, and phoenix wants to replace it with a modern version.
This isn't what abandoned means.
And DWL is not super small. It's hundreds of times larger than a minimal X wm, and couple of times as big as the wm I used.
And it's C. And it'd mean I would lose my session if I want to make changes and restart it.
What you're suggesting would be to put significant effort into replacing something that works with something that in terms of features I care about is strictly inferior.
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.)
Unless you can show me a solution that lets me replace my tiling and floating wm in ca 1500 lines of Ruby, what you're offering me is inferior to what I have with X
You might consider that a bad API, but to me any solution without it is massively inferior and not something I will ever consider.
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.
I don't know what you expect people to prove other than that X and Wayland both have the same problem but since X is so complicated there is only one implementation to begin with, which makes it look like X has solved the problem even though it suffers from exactly the same problem.
Are there non-Xorg X servers for Linux that are usable? Asking because I'd like to try them if they exist
> basic desktop functionality
I feel your pain, but find your idea of "basic" functionality amusing.
That said, `pw-dump` / `pactl` will give you client names, which often match the window titles.
Anyway, I do think I've created what should be considered basic desktop functionality here, a simple hotkey that mutes or otherwise changes the volume only of the focused window. Every desktop should have it.
This is just one of the tools I've made for myself with X which I do not want to do without and this makes Wayland a non-option for me. If I can't use X and can't replicate things like this with Wayland, then maybe I should switch to MacOS at that point because the dream of controlling my own computer seems like it's dying anyway.
I absolutely don't buy this.
libwayland is 40k lines of code. wlroots is 60k loc.
And just to check, sway is about 49k loc.
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.
Wayland doesn't solve any problems I have, and would create new ones, such as having to adapt to new tools or write my own compositor.
Battery life just isn't a relevant consideration for me.
There probably hasn't been much interest in it because screens can easily be powered off remotely, which was not the case in 1992.
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.
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?
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.
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.
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.
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.
I will never buy a car that runs an X-windows server.
I really cannot thing of any existing functionality ever broken by a new release of wayland-protocols, neither by a plain bug nor by a bad interaction. No doubt someone else will be able to recall an example, but it's really not a common thing.
This is partially because the governance model and community mindset is the opposite of what you describe. Inclusion of new protocols in the stable release requires existing, proven implementations and consensus across multiple implementors, making it a high bar. New proposals run a gauntlet where pretty much everyone is looking at the consequences in detail.
In fact a more common criticism of Wayland is that the focus on high quality and the consensus requirement are too strict and have slowed down filling in feature gaps users need filled faster. This argument I think can be successfully defended against - mainly, that it helps avoid the mess X11 became over time -, but at least has some basic merit in reality and is an avatar for genuine user pain.
As for X11, as someone who had to implement a lot of X11 specs over the years, I can tell you that their provenance between X11 itself as well as ICCCM and EMWH had plenty of super dumb ideas and cruft and inconsistencies from lack of foresight and eventually datedness. You don't want to see the towering stack of hacks and heuristics we used to have to ship to make X11 behave somewhat consistently and sane :)
In short, with all due respect, but I think you really don't know what you're talking about. We really should resist this type of narrative reality distortion field on an engineering forum.
That high bar is GNOME having an uppity whenever a Wayland protocol is suggested they don't like, that even if is accepted, if Mutter doesn't implement it then its dead in the water given its the de facto default compositor on unfortunately what people consider "Linux", aka Ubuntu.
e.g. DRM leases that only got changed because Valve has the bigger underwear. Expecting games to implement DBUS (incl. when running under Wine) to access VR headsets just for GNOME is nuts.
The government model needs a change that stakeholders who ship devices to the end users that rely on them have more of a say, whether that's Google, Valve etc. Valve is now backing and pushing KDE into average joe end users is a telling.
Are you implying title bars should be mandatory in all WMs? I'm using DWM on X and I love that I have no title bars. If a program tries to force one on me I disable it or use something else if that's not possible.
This way people like me still have the option to use window managers that don't have title bars. Title bars are useless for power users that know what program they're in and don't need them. To me they're in the way.
>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).
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/
I still don't know how people twist this obvious success into a failure.
Imagine we were talking about web browsers…
There should only be one! No security makes all my extensions work!
That's the situation with Wayland that people are complaining about. I don't need innovation in keyboard and mouse sharing, I need it to work.
Wait, what? I tried this last year. I didn't find any way to do this that wasn't dependent on the WM.
Tho admittedly kiosk-wm (https://github.com/JOT85/kiosk-wm) is much more succinct.
GLFW for my window library.
Wayland is overkill.
I would go straight /dev/fb if it meant I could also antialias and make it pretty and didn’t need a cursor.
I wonder why you think what Valve does has any relevance to my experience or priorities.
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.
People are arguing that fixing the issues in X11 would have been much easier and less work than making wayland. So why could those half of x11 developers who left make wayland while the other half that was left over could not even make one release?
Wait so is this turning Wayland into a client/server model like X11, where eventually it could support existing window managers and other stuff separate from the compositor?
I remember a year or two ago wondering if that would ever happen and I think I only got one reply saying it wouldn't happen because it was unnecessary.
Something like a screen reader needs to talk to an app and query the toolkit for the contents of a window in a semantic way - that's a toolkit feature not a compositor one.
Even back then Qt, GTK and everyone else offered their own API and screen readers needed to integrate with every single one - this didn't really change under Wayland, only the sandboxing makes certain operations harder, but the accessibility story on Linux is not great, and never was.
Above X11, implemented by GTK and everyone else. Right.
However... Wayland makes it impossible to implement EWMH. Which means the enrire EMWH standard needs to be tossed, and everyone needs to make something new.
You can't even get the title of a window, under Wayland. That's private to that process tree.
Wayland requires accessibility be implemented at the application level, not the window manager. And thats guaranteed to make it always broken for a majority of use cases.
> Wayland has no concept of global coordinates or global key bindings. The protocol itself is designed around atomicity which is a nice concept, but is fundamentally in conflict to the need of assistive technologies to control the entire state of the desktop globally. As such, atspi methods like get_accessible_at_point are impossible in Wayland.
But, right now, XLibre[0] is available, ready for use and very active.
iOS/Mac/Android is on completely other level.
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?
The very thing that makes people biased towards X11/Xorg both negatively and positively is that it is a huge monolith and the only X implementation on Linux. The moment you have two implementations, you're gonna get the same complaints against the second X server as Wayland is receiving.
You think this is an indictment to the second implementation and that they shouldn't bother by saying an "analysis was incomplete" but in my opinion it's exactly backwards. This is an argument that eternally perpetuates X11 not because of technical capability but rather because it was there first.
After all, the moment there is any implementation that is second it might miss a single feature that nobody actually uses, but theoretically could be used when combining an old binary with a new X implementation.
But this argument misses the obvious fact that X11/Xorg is already dead since any code change will break existing applications. Meaning X11 has become an unsalvageable fossil.
I think there is a reasonably agreed on set of things that can be removed from X, like server-side drawing primitives, and GLX
It will be obsolete someday, anyways.
X11 is far from obsolete.
If it also runs Wayland apps, many may prefer it actually.
Actually I still have more issues on Wayland than X. Although it is at least starting to swing in the other direction - e.g. KDE's screen recording feature doesn't work on X. The button's still there but if you click it nothing happens.
The only thing maybe worth discussing is video acceleration. this aside, I have been using gnome on Wayland for years and no problems what-so-ever. I really don't know what the fuss is about.
I would prefer that people start moving this legacy nonsense behind and finally start accepting new and better things and focusing on things that have future. Same thing happened with systemd, it improves massively everything Linux, yet some people just want their services started with scripts.
What problems do you have when things don't work for you on Wayland?
* straight up doesn't work on at least one of my laptops (driver problems AFAICT)
* does run on the other one, but crashes at an alarming rate compared to Xorg
* breaks all of my accessibility tools (some have (worse) replacements, some don't)
here is my state of laptops:
* Dell latitude with old Intel 8gen CPU, it works fine (Linux kernel causes problems with PSR, but this has nothing to do with Wayland and disabling it fixes the problem, same thing with cstates)
* Dell latitude with 10gen CPU, works fine.
* Huawei d15 with Ryzen 3000 Apu, works fine.
ok. for accessibility it's fair enough as a critique. I don't use it so can't say. As far as I can tell this hasn't been in focus at all. but most of this is on the toolkit side, not Wayland (even though here one thing is mentioned as Wayland specific, just briefly went through the post)
https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the...
Does it matter? Your claim is that everything works, and I am here to tell you that I am a real person running real machines that do not work. Unless you're planning to fix the particular bugs and missing features that I'm hitting I don't see where the specifics actually matter. (Anyways, the first machine is a https://wiki.archlinux.org/title/Lenovo_ThinkPad_T490 with Intel graphics; this appears to work but is less stable than Xorg. The second machine is a https://wiki.postmarketos.org/wiki/Lenovo_IdeaPad_Flex_3_Chr... that doesn't run Wayland at all, which I grant is bizarre since the stock ChromeOS uses Wayland. You are welcome to point out that this is more than a little off the beaten path, at which point I will of course point out that Xorg somehow handles it just fine.)
> but most of this is on the toolkit side, not Wayland (even though here one thing is mentioned as Wayland specific, just briefly went through the post)
It varies; a11y isn't a single thing. Deep application integration to allow eg. screen readers to work well probably needs toolkit integration. But there are also things like dwell click, which is really helpful when my RSI is flaring up. In X, I just run `mousetweaks --dwell` and it works, and it works in any window manager or desktop environment, with absolutely no help needed from toolkits or applications. In Wayland, it's sometimes available on a per-compositor basis, which I would describe as purely inferior. On which note, observe that you've linked a blog post about a prototype for GNOME. They note that they're open to working with other desktop environments, but 1. that means it doesn't exist as of that blog post, and 2. I've seen how GNOME operates over the years; I fully expect portability to be a very distant second priority, and whatever they export will be an attempt to force everyone else to do everything the way GNOME does, which will go poorly. I have no interest in ever going back to GNOME, so the actual takeaway, AFAICT, is that the a11y situation on Wayland is bad and will remain bad for the foreseeable future.
if this is so, I can admit I'm wrong. so not everything works for everyone.
For myself and members of my family, I can say that absolutely everything works on gnome. And I have several machines, spread over several cpu and gpu generations, and different form factors that confirm this. not only those 3 laptops I mentioned.
Could it be that since you are not using gnome that you are hitting those problems? My experience is exclusively gnome, so maybe this is it?
a11y aside of course... given that this was not really finished. or seriously worked on.
It certainly could be GNOME vs not-GNOME. That doesn't really help me, either way, but it's not hard to imagine that different compositors have entirely different quality levels.
yes gnome has a vision of how the desktop should look like and strong behavior of "my way or the highway", but maybe you get surprised how well it works. especially on fedora.
I assumed wrongly other people (you mostly) use gnome by default, which obviously is not the case. in that case I could see it as a problem since not everyone has red hat resources for desktop development.
I think we are finally at the point where you can say most things work and it's silly to go back to X11, but even so Wayland has clearly been a huge failure.
You can blame the apps all you want, but it's a fact of life, and Wayland has been around for 18 years.
At this point you'd hope they'd pull an early 90s Microsoft: https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...
(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).
As per Windows placement, Firefox won't restore windows on original positions supposedly because of Wayland, somebody please correct me if I'm wrong.
When I only use a scaling factor of 1 on all the screens, it's usable enough, although it still feels sluggish.
I run two different distributions myself, I know a bunch o people on even more different distributions, set of configuration and based on empirical analysis I can assure you that no one has problem with windows placement.
Out of the box I used have more problem with X11 (tearing and font rendering being the most annoyingly common ones) than I have with Wayland.
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.
All the first 3 names were taken. They probably had to bribe even the holders of the Firefox trademark to get it (though the terms were never disclosed).
Edit: Here you go: https://www.zdnet.com/article/mozilla-holds-fire-in-naming-f...
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.
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.
It’s always drama and they’re the center of it.
(I’m joking of course, Merry Christmas)
It's definitely not well designed though.
And I agree about recommending it to beginners. Sure, a for-loop and a simple function look very friendly and easy, but good luck explaining to them why they can't import from a file in a different directory...
> [...]
> 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.
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.
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"
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.
Just use OpenGL. I don't know when this trend to overcomplicate everything using Vulkan began, but I hate it.
Vulkan has substantial advantages for multi-threaded code, as well as exposing the underlying asynchronous nature of running code on the GPU. The kind of thing you want to be able to control with a desktop compositor where controlling vsync and present timing is very important.
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.
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.
KDE from 15 years back was HUGELY better than windows at the time, and frankly, also windows now
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
You can enable this in Win 11 25H2. I have it enabled on my box. Doesn't seem to make that much of a difference, so it's more or less a moot point that it has been using SCSI emulation.
> Windows in early 2025s still need virtio driver injection to boot properly as a VM without IDE emulation
Interesting, in Hyper-V that's a non-issue.
when was it sata became the norm? im thinking circa 2001-ish, and what windows was latest here? im thinking windows xp. lets try remember, did windows xp include sata drivers on the installation medium?? oh wait, it didnt. There wasnt even ahci at the time, and windows xp didnt include a single sata driver for any of the chipsets at the time
> A Window Manager and Window Server don't come by default with Linux... It's always an install-time option on the major distros.
desktop distributions generally come with a desktop environment default selected, or prompt you to choose between a few. one feature that has been there since more or less forever is alt + left/rightclick mouse to move/resize windows, which is significantly better than finding the title bar or corners like. for an operating system called "windows" its pretty hilarious it has the worst window management of them all, dont you think?
> desktop distributions generally come with a desktop environment default selected
You missed the point. "Linux", the kernel, does not come with a WS/WM.
I don't know what "prime time" means here.
edit: apart from, you know. Applications and drivers for random hardware.
It was fine for non-technical users since at least early GNOME 2, if you're ready to help them set up and maintain. Semi-technical users (Windows power users, gamers, &c — people who like to install and configure things, but fear the deep dark abyss of the terminal) were and remain more problematic.
Unity days were the nadir of linux desktop ux — it was when Gnome 2 was gone, and 3 not yet there. Still better than contemporaneous Windows 8, though.
People are always task-oriented, not tool oriented unless they’re nerds.
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.
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.
Overscan is not supported in wlroots yet. Seems the issue is that handling overscan is display driver specific.
But, now I know the keyword to look for.
https://gitlab.com/yjftsjthsd-g/docker_sway-vnc
(This is not a defense of Wayland, just trying to share useful information)
Also that's only really relevant to this running in a container. My point was that you can have headless Wayland.
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.
My desktop is a bit long in the tooth (22.04), but I've long given up on trying to screen shot or screen share from Wayland. I have my Macbook sitting next to it and use it for those things, where it works basically flawlessly.
Kind of waiting for 26.04 to upgrade at this point, but I'm not really expecting any of this to be better yet.
edit: If I had it to do over again, I wouldn't have gone Wayland at 22.04.
I've been an i3 user for almost two decades, but eventually switched to Sway - to this day there's no InputCapture portal, so I can't use Synergy with Sway, forcing me to switch to i3 while I'm working.
It's been over 10 years of things like that. There's always SOMETHING missing.
What's missing?
https://developer.android.com/privacy-and-security/risks/tap...
Any function that is a threat should be behind capabilities.
A program should be able to request moving its windows. The user should ultimately decide what should happen: allow or nah.
That limited capability still has a risk of denial attacks (just throwing up pop-ups that extend beyond the current window’s boundaries), but those can be mitigated in a number of ways (limit the new window’s boundaries to the current window’s, or just limit how many windows can be opened, etc.).
This dilution of responsibility should make you feel much better.
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.
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.
The distribution sprawl I largely see as a detriment to the ecosystem.
So, in theory, we can embrace a rather-minimal X11 implementation that can run the modern UI, including some desktop features missing in Wayland.
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.
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.
With Wayland, you don't even get compatibility with Gnome and KDE. You need conditional compilation to get mouse events if you port to FreeBSD Wayland.
For the medium term, if your goal is to reduce fragmentation, X11 is the portable target, even if you use Wayland.
Run gui apps in your container, local or remote.
Perfect
totally awesome! And once we are done with X11, lets put pulseaudio to the grave! We can all focus on having an audio stack that does realiably stream to many sinks!
And polkit... su and sudo should have been enough
That'll happen first, I think. The trick is that pipewire is actually a fully functional replacement, instead of trying to declare everything out of scope, so with only minor effort people can just switch and everything works.
This is really the main issue with wayland. Yes, it might be more stable these days and work fine for you. We can talk how how it makes writing you own WM needlessly complicated and all that but the one thing that makes wayland unacceptable is its lacking accessibility story. After so many years.
Accessibility is not something you can worry about adding later. It is the first thing you should think about when designing new software.
I've been using wayland for a while now and am very happy with it, but my accessibility needs are pretty basic.
Here is a slightly-hopeful article: https://fireborn.mataroa.blog/blog/i-want-to-love-linux-it-d...
I don't think there's any concrete proof of this. Ideally I think people want accessibility handled by their WM/DE; you're not getting Windows or macOS-quality a11y "for free" unless your desktop embraces it. At which point you might as well make it a separate, aftermarket protocol and slap it into d-bus.
If the Linux ecosystem is going to be fragmented and move past single-point-of-failure, polishing Xorg's accessibility works against the goal of standardized a11y.
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 is interesting to me, why would vsync being enabled mean that the desktop compositor needs to stick around for a full screen app?
In X11 "screen" has a particular meaning, and only supporting a single screen doesn't preclude multi-monitor support or virtual desktops.
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..
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.
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.
[1] https://www.donhopkins.com/home/catalog/unix-haters/x-window...
https://en.wikipedia.org/wiki/Windowing_system#Display_serve...
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.
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...
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.
this might make a good alternative to Xwayland though, which can be exciting.
We can see innovation in this space.
Next I suppose is porting Motif to Windows.
OP if you're the author I suggest you rename to avoid confusion. Don't name it Rails either haha!
(I still think they should've stuck with "Firebird", little danger of confusing a browser with a database system mostly used by Delphi devs)
But I don't see how a X server implementation should avoid name collision with web frameworks.