Phoenix: a Modern X Server Written From Scratch in Zig
Key topics
The Phoenix X server, written from scratch in Zig, has sparked a lively debate around its design choices and naming convention. Commenters are dissecting the decision to disable the compositor for fullscreen applications with vsync disabled, with some arguing it reduces latency, while others point out that Wayland's DRM leasing extension achieves a similar goal. Meanwhile, the project's name has also been called into question, with some claiming it clashes with the well-known Phoenix web framework, while others counter that the name is still valid given the framework's relatively niche popularity. As the discussion unfolds, it becomes clear that this new X server is generating interest and scrutiny from the tech community.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
19m
Peak period
93
0-12h
Avg / period
20
Based on 160 loaded comments
Key moments
- 01Story posted
Dec 24, 2025 at 5:43 PM EST
9 days ago
Step 01 - 02First comment
Dec 24, 2025 at 6:03 PM EST
19m after posting
Step 02 - 03Peak activity
93 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 30, 2025 at 3:45 PM EST
3d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
This is interesting to me, why would vsync being enabled mean that the desktop compositor needs to stick around for a full screen app?
OP if you're the author I suggest you rename to avoid confusion. Don't name it Rails either haha!
[1] https://survey.stackoverflow.co/2025/technology
(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.
0. https://github.com/X11Libre/xserver
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.
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.
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...
Don't ask me. I've been fielding the question for decades. Not much recently though.
This has been true for decades.
https://en.wikipedia.org/wiki/Server_(computing)
Doesn't mean I haven't been asked dozens of times to explain it to very smart people.
But, yes, a server is still usually a remote machine. When "the server's down", it is usually not your local machine. You're logicalling yourself out of humane language.
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...
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.
https://codeberg.org/dwl/dwl
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.
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.
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.
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
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?
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", 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
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": 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.
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.
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 ans 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 male 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.
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.
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.
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 an implementation-specific X.Org feature.
[1] https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html
[2] https://specifications.freedesktop.org/wm/latest/
Vulkan, various node replacements come to mind.
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.
[0] https://news.ycombinator.com/item?id=45858043
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.
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.
https://youtu.be/wo5As8et1G8
https://youtu.be/pqJ-9SUPFwY
I will never buy a car that runs an X-windows server.
I really cannot thing of any existing functionality broken 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. This argument I think can be successfully defended against, but at least has some basic merit in reality.
In short, with all due respec, but I think you don't know what you're talking about.
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 you have libinput, or libei, or libportal with the InputCapture PR, and xdg-desktop-portal with the InputCapture interface, or maybe you have nothing at all (weston). It's a gamble if your choice of desktop environment and it's custom wayland compositor a 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 minimal (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.
249 more comments available on Hacker News