Live data from Hacker News

Phoenix: A modern X server written from scratch in Zig

git.dec05eba.com

221–230 of 462 posts

Re: Phoenix: A modern X server written from scratch in Zig

#223
post #158

Earlier quoted context omitted.

I use Linux on the desktop since 1997, and there was no point where Windows was even slightly more attractive. I don't know what "prime time" means here. edit: apart from, you know. Applications and drivers for random hardware.

With prime time I mean being comfortable enough to install it for a non-technical user. Even during Ubuntu's Unity days it didn't feel like I could install it on a computer for my parents or siblings for them to use as a daily driver.

I had Kubuntu installed on my grandfather's computer for a year. I ended up replacing it for Windows because my aunt likes to install stuff on it. But my grandfather was happy with it. He only needed a working web browser and a program to use the TV tunner.

Re: Phoenix: A modern X server written from scratch in Zig

#224
post #193

Earlier quoted context omitted.

Current status: > 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

I said build on top of wlroots, not DWL. And I only brought it up as an example of a small Wayland compositor/window manager because the poster I was replying to wants to build their own anyway. DWL is more interesting as a learning exercise than something to use.

> I said build on top of wlroots, not DWL.

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.

Re: Phoenix: A modern X server written from scratch in Zig

#225

Earlier quoted context omitted.

I think the problem is that people wanting to build that and being in position to (being paid for by their employer), are fed up with X11. 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 t…

> I think the problem is that people wanting to build that and being in position to (being paid for by their employer), are fed up with X11. 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 comp…

Replace "X" with anything and this is why i generally try to avoid relying on open source projects where the majority of the development is driven by some company if there is an alternative, even if they're jankier (and often they are).

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.

Re: Phoenix: A modern X server written from scratch in Zig

#226
post #21
post #11

Pretty interesting approach to make an X server that is essentially "Wayland-like" (merging display server/compositor by default, isolated apps by default, no remoting of GLX, dropping legacy protocol features to the point of breaking compat with the core protocol, etc.). Not sure who this is for, but by itself it looks like a fairly reasonable set of choices.

For people who absolutely have to have X11 this looks like a better plan than XLibre.

Rewriting it from scratch is so very rarely a better plan than improving what you already have.

Re: Phoenix: A modern X server written from scratch in Zig

#227

Earlier quoted context omitted.

> This definitely doesn't match my memory, and I was there :) Most of the good reasons remain unavailable in X11 to this day. 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?

Per-display DPI settings. No snooping on input without permission. Awareness of the lock screen (the compositor can know that the lock screen is active and provide alternate keybindings instead of having to configure the lock application as well). Locking is not blocked by context menus being open. I ran XMonad for 15 years, but recently switched to river and am loving it.

HDR something that can't be brought to X11 without breaking backwards compatibility.

Re: Phoenix: A modern X server written from scratch in Zig

#228

Earlier quoted context omitted.

BS, windows and macos cant even do proper window managing for a start, and then it just goes downwards from there on.. You can perhaps install various weird third party things, but it does not come with it by default. 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 year…

[flagged]

[deleted]

Re: Phoenix: A modern X server written from scratch in Zig

#229
post #45

Earlier quoted context omitted.

Fair! Though I'm actually not sure I understand what you mean with simplicity. X11 is so vastly more complicated than Wayland.

What's the simple way for a bash script to get the title of the currently focused window? In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please. 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 Wayla…

> In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.

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.

Re: Phoenix: A modern X server written from scratch in Zig

#230

Earlier quoted context omitted.

Wayland made writing WMs needlessly hard, and the benefits of Wayland were frankly not real - most of the reasons given in 2011 were patched in to X11 later. All the Wayland rewrite got us was a situation where Wayland is both bleeding-edge and obsolete simultaneously. Say what you like about X11, but by the time people unironically pushed for mass Wayland adoption, X11 was stable and boringly so. The future of WMs i…

Let me know when X11 handles fractional scaling across mixed dpi and refresh rate monitors, with HDR and VRR. To me, who has finally been able to drop Windows for gaming in the last 3 months, the benefits of wayland are very real.

Technically Xorg can handle fractional scaling across mixed dpi and refresh rate monitors, but it requires support from toolkits, window managers and applications which means the developers of all of those (or at least toolkits and window managers) need to cooperate. At minimum, you need toolkit support for the most basic. AFAIK Qt6 does have this support and should be able to handle fractional scaling across mixed DPI monitors but not in an ideal way since for better experience you'd need the app/toolkit cooperating with the window manager instead of the toolkit trying to do everything on its own without knowledge of the rest of the desktop. I wrote about it in detail here[0] but the gist is that it is largely an issue of getting the developers of various projects to cooperate than some feature Xorg itself lacks (it doesn't). Wayland had it easier here because it started from scratch and developers had to worry about those things for supporting it. On a more positive note, because of Wayland (and Win32, if a toolkit support scaling there) the the hard part of the work on the toolkit side should already be there.

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

Post reply on HN