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.
It depends on whether their reasons for "absolutely having to have X11" hinge on actual compatibility with e.g. old binaries or wanting full remoting without streaming pixels.
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.
I don't "actually want Wayland" because I want the simplicity of X and the ability to run my own wm, but I have no need for legacy X11 requests, for some values of "legacy". Whether this will become viable for me remains to be seen, but I need very little from my X11 server.
Look into river. It has the window management and keybindings able to be offered by other tools (I have an idea to implement one using XMonad's layouts).
It also vastly improved battery on my Dell Pro laptop. 58% battery used in 7h45m (light compilation day, but no suspend).
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.
Well, you are not really forced to write a compositor these days as there are libraries that do all the heavy lifting for you.
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.
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 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.
> "most of the reasons given in 2011 were patched in to X11 later"
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.
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.
The 3 justifications I remember for Wayland were security (isolating windows from each other), multi DPI, and eliminating tearing. All are now features of XLibre.
This is all playing a bit fast and loose with the details.
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.
Why? People complain that the YAML specification/protocol is too complex. This may be, but I found using YAML much, much easier and nicer than XML. So to me these two things are not necessarily interconnected. You can have a great implementation and a crappy protocol; but also a great protocol and a crappy implementation.
The people who absolutely have to have X11 like myself usually have reasons. It sounds like currently a lot of those reasons for using X11 would prevent using this X server. Like reliable non-fragmented and widely supported screenreader protocol. Or the ability to do keyboard and mouse sharing.
>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).
Accessibility? Sure. Everything else? Nah, I'm sorry. There are countless ways to do remoting with Wayland. There are countless ways to do kb+mouse sharing.
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/
Anything special about Raspberry Pi's that require X11? Raspberry Pi OS defaults to Wayland nowadays, and there's specific kiosk Wayland compositors like Cage (https://github.com/cage-kiosk/cage).
"The devs of x11" is a wide category, considering how many X11 devs weren't even born when X11 was first written. Plenty of X11 devs objected to Wayland and tried to patch X11, but when half the devs decide they want to write a replacement and put the original into maintenance-mode, there's not much you can do.
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.
Valve ships a Wayland compositor that just runs XWayland for apps and doesn't even expose the Wayland socket by default. I'm really not sure how we're supposed to count that.
> by itself it looks like a fairly reasonable set of choices.
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?
I consider Wayland's choices reasonable as well. I.e. I
it's not surprising that a reasonable attempt to clean up X ends up looking similar to Wayland, just in a slightly different place on the xy graph that has backwards compat and cleanup as its axis.
This is a great project! I like and use Wayland but the portal protocols and extension mechanism does leave a lot to be desired. Wayland is still quite a way behind Windows and macOS in terms of what productivity users need
An X11 rewrite with some security baked in is an awesome approach. Will be watching!
I thought for a long time that rather than move to Wayland, we could come up with a tidied-up version of X. Sounds like a good and useful project, I hope it progresses.
It was always an option, but "just" needed someone to dedicate all their time to it and pull in a group of long term maintainers. The real question is what will happen with the project in 2 years and will it be stable for day to day use.
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.
Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
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.
> Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
> [...]
> 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.
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 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.
As someone who came from Windows, and has used Linux as my primary OS for 15 years, and MacOS here and there (cos work provided laptop), I can tell you that Linux was not ready for prime time 15 years ago. Today, I feel it is, but definitely not 15 years ago.
15 years back people were given Windows macOS and Linux and people voted which OS were ready for the Desktop and which were not. The only BS is your inflammatory contribution to this topic.
Windows is reasonably OK, but MacOS' window management has always been really terrible.
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.
I don't use a Mac, but have you ever used Windows?
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.
Windows allows you to launch applications from a menu or via search. You can switch between windows with a mouse or keyboard shortcuts. Windows can either be floating, arranged in pseudo-tiled layers, or full screen. KDE can pretty much do the same under Wayland. Ditto for Gnome under Wayland, albeit to a lesser degree. That covers the bases for most people.
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.
I don't really understand what is supposedly missing in Wayland for productivity users? At work I have been using gnome with the wayland backend for years at this point and I can't really figure out anything that's missing.
Accessibility is apparently a big problem with wayland. E.g., the most popular / ?only? app that supports hardware eye trackers on Linux does not work with wayland, and states that it likely never will as wayland does not provide what it needs to add support (it is also the most popular app for voice/noise control). Even basic things like screen readers are apparently still an issue with wayland. Without a strong accessibility story, systems running wayland would have been banned at my last employer (a college).
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.
This is the kind of initiative I’d prefer to see from X preservationists. Great job, I hope it succeeds. I prefer Wayland, but there’s still a place in the world for X; it just needs new dev teams to shoulder the burden.
> The choices in the Linux ecosystem lead to unnecessary fragmentation and development/packaging nightmares.
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.
The *original* X11 should die, but the modern Linux GUI stack has long abandoned most of its features anyway. X11 was already reduced to a bit-blitter protocol long before Wayland.
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 name Phoenix is overused. There is an Elixir framework called Phoenix. I think I also heard of other projects with that same name before.
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 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.
As the application author you can set the release mode in the build script so that the release flag looks like `zig build --release` instead, and the user doesn't choose the optimization mode.
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.
I have no idea how well this one works, but I am all up for
more projects that can compete against the singularization
that corporations currently try (see paid developers for
wayland, GNOME and now also KDE). I wonder how much money
would be needed to make the xorg server adapt to the modern
era; I don't even know the featureset that is missing for
this either. But I also know that wayland, after 20 years
(!!!), will never cover those requests users had over tohse
20 years, simply because it tries to cater to a narrow
specification wanted by corporations rather than the people -
so much is now clear (wayland protocol was released in
2008, so it is soon 20 years actually; in a few days we
have 2026, so it will be 18 years).
It’s possible that most of old X11 toys would not work properly, because many of them rely on X11 drawing APIs, but they are pretty simple to implement anyway.
Multiple screens support is listed as non-goal. Would that prevent its usage with window managers which support virtiaul desktops? I am i3 user and it is a critical feature for me.
Is this why back in the day sometimes a Linux distro would have a multi-monitor setup where each monitor was an actual different desktop cube for example. There was a time when each window for an Nvidia graphics card in that type of configuration could not be moved from one screen to another, etc.
As others have already mentioned, the continuous multi-monitor(Xinerama) was an afterthought. A good news is that, by design, it’s actually pretty easy to add in the later steps.
The part that is counterintuitive to most people when it comes to the "server" terminology is that, with X, your end-user workstation (which may be an incredibly dumb X terminal) is the "display server", which means you remote into a server (in the traditional sense) elsewhere, which then acts as an X client by making requests to your local machine to display windows.
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.
I think the confusion is obvious, given a little empathy for the range of people who use computers.
The server is usually a remote machine, especially back in the time when "client-server" architecture was emerging in mainstream (business) vernacular.
Please don't imagine that I don't fully understand this.
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.
Yes, it’s simultaneously logical if you look at how it works and immensely strange if you don’t understand the architecture. (As has been noted all the way back to the UNIX-HATERS Handbook[1], although, pace 'DonHopkins, the NeWS Book uses the same terminology—possibly because it was written late enough to contain promises of X11/NeWS.)
Programmers aren't good at checking if the name is taken. We've done this particular one before. Phoenix (Firefox) had to change names because of Phoenix Technologies, then again because of the Borland Firebird Database.
Bit of an observation, but I've noticed that there's been quite a few pragmatic projects started in Zig. Bun vs Deno comes to mind (one focused on DX, the other on security), and now this vs Wayland. Not to say that designing something properly is wrong, just that it tends to throw away a lot of important interoperability.
If you are not going to implement X11 drawing ops and XRender (which I, and many others, still use heavily), what's even the point? Any 'modern' program that only does client-side rendering already supports Wayland. AFAIK GTK 3 doesn't even support DRI on X11 unless you somehow trick it into using the abandoned OpenGL Cairo backend, but that's not modern enough apparently.
It talks about trimming 'legacy' features and specifically says they are omitting 'font-related' operations. That obviously means no useful core X11 application will work (unless you count xlogo and xeyes). Whether the XRender glyph cache mechanism is included is unclear. It also says only DRI is *currently* supported, but maybe that's incidental?
Yeah, we should introduce competition. It doesn’t feel like Wayland is improving these days. Missing features force me to hit X11 regularly, and I still get Wayland session crashes etc, while X11 could happily run over a year without crash and run all applications I need without issues.
Cool project I guess, don't see the point but technically interesting. Will be cool to have another modern display protocol/server. I personally would have rewritten Wlroots in Zig or something, but I guess this is more interesting.
XLibre is a joke. They're making changes for the sake of changes: for example, commit aefde9 strips out vendoring in an ad-hoc, incomplete fashion (introducing a minor spacing bug in the process); and commit aafd986 replaces `int` with `unsigned int` (instead of `size_t`), failing to properly fix the bug that the compiler warnings identified (albeit, also removing an unrelated C footgun along the way, so this does look like a bug fix). The main author has a history of cowboy commits: 533c45e (which made it into mainline Xorg before he got kicked out) straight-up prevents hw/xfree86/os-support/bsd/arm_video.c from compiling, so it's clear there's no actual testing taking place.
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.
Yeah but wayback doesn't lend itself to the "omg my x11 I could neverrrrr :huff-emoji: :huff-emoji:" hysteria.
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.
Here's two complaints: it's a security theater, and it's horribly balkanized by design.
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?
OK, you can't have your preferred environment because someone else has a different use-case.
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.
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.
It depends on whether their reasons for "absolutely having to have X11" hinge on actual compatibility with e.g. old binaries or wanting full remoting without streaming pixels.
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.
I don't "actually want Wayland" because I want the simplicity of X and the ability to run my own wm, but I have no need for legacy X11 requests, for some values of "legacy". Whether this will become viable for me remains to be seen, but I need very little from my X11 server.
Look into river. It has the window management and keybindings able to be offered by other tools (I have an idea to implement one using XMonad's layouts).
It also vastly improved battery on my Dell Pro laptop. 58% battery used in 7h45m (light compilation day, but no suspend).
Fair! Though I'm actually not sure I understand what you mean with simplicity. X11 is so vastly more complicated than Wayland.
For the server/compositor.
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.
Well, you are not really forced to write a compositor these days as there are libraries that do all the heavy lifting for you.
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.
So build on top of wlroots or something. DWL for example is super small...
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 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.
> "most of the reasons given in 2011 were patched in to X11 later"
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.
> 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.
The 3 justifications I remember for Wayland were security (isolating windows from each other), multi DPI, and eliminating tearing. All are now features of XLibre.
This is all playing a bit fast and loose with the details.
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.
First time I've heard of Arcan. Sounds intriguing.
IMO, if you have to rewrite a display server implementation then you're already proving all the protocol advocates right.
Why? People complain that the YAML specification/protocol is too complex. This may be, but I found using YAML much, much easier and nicer than XML. So to me these two things are not necessarily interconnected. You can have a great implementation and a crappy protocol; but also a great protocol and a crappy implementation.
The people who absolutely have to have X11 like myself usually have reasons. It sounds like currently a lot of those reasons for using X11 would prevent using this X server. Like reliable non-fragmented and widely supported screenreader protocol. Or the ability to do keyboard and mouse sharing.
>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).
Accessibility? Sure. Everything else? Nah, I'm sorry. There are countless ways to do remoting with Wayland. There are countless ways to do kb+mouse sharing.
>There are countless ways to do kb+mouse sharing.
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/
My rpi dashboards are gonna love it
Anything special about Raspberry Pi's that require X11? Raspberry Pi OS defaults to Wayland nowadays, and there's specific kiosk Wayland compositors like Cage (https://github.com/cage-kiosk/cage).
Tho admittedly kiosk-wm (https://github.com/JOT85/kiosk-wm) is much more succinct.
Long term if x11 starts having issues then probably https://gitlab.freedesktop.org/wayback/wayback will be it
People who want to use X11 are likely to be the same people using older software and hardware, which this doesn't support.
I don't use any old hardware, and I have argued for a new X server following almost exactly the steps this project outlines.
Good news. The devs of x11 agree and made a replacement called... Way... Oops
"The devs of x11" is a wide category, considering how many X11 devs weren't even born when X11 was first written. Plenty of X11 devs objected to Wayland and tried to patch X11, but when half the devs decide they want to write a replacement and put the original into maintenance-mode, there's not much you can do.
> there's not much you can do.
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.
Yeah, no, the X11 devs made pretty much all the wrong tradeoffs for me.
K bro. K.
I wonder why Valve disagrees.
Valve ships a Wayland compositor that just runs XWayland for apps and doesn't even expose the Wayland socket by default. I'm really not sure how we're supposed to count that.
> by itself it looks like a fairly reasonable set of choices.
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?
I consider Wayland's choices reasonable as well. I.e. I it's not surprising that a reasonable attempt to clean up X ends up looking similar to Wayland, just in a slightly different place on the xy graph that has backwards compat and cleanup as its axis.
A lot of people would have preferred this to Wayland if it had come much earlier.
If it also runs Wayland apps, many may prefer it actually.
This is a great project! I like and use Wayland but the portal protocols and extension mechanism does leave a lot to be desired. Wayland is still quite a way behind Windows and macOS in terms of what productivity users need
An X11 rewrite with some security baked in is an awesome approach. Will be watching!
I thought for a long time that rather than move to Wayland, we could come up with a tidied-up version of X. Sounds like a good and useful project, I hope it progresses.
It was always an option, but "just" needed someone to dedicate all their time to it and pull in a group of long term maintainers. The real question is what will happen with the project in 2 years and will it be stable for day to day use.
I thought this too and originally thought that’s what Wayland was going to do but it went off and did its own thing.
I’m all for an X12.
An X12 was briefly considered by the community before adopting Wayland: https://www.x.org/wiki/Development/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.
I’ve been here since the beginning.
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.
Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
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.
> Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
> [...]
> 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.
Python is really one of the worst designed languages. It always baffles me that people recommend it to beginners.
Except for all the others (that anyone uses)…
There’s a reason they’re called Pythonistas
It’s always drama and they’re the center of it.
(I’m joking of course, Merry Christmas)
Be the change you want to see.
Also happy winter solstice.
> Wayland is still quite a way behind Windows and macOS in terms of what productivity users need
What's missing?
Ads in the start menu, forced screenshotting of all your activity, and AI integration in every aspect of the desktop experience.
lol
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 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.
> You can perhaps install various weird third party things, but it does not come with it by default.
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.
As someone who came from Windows, and has used Linux as my primary OS for 15 years, and MacOS here and there (cos work provided laptop), I can tell you that Linux was not ready for prime time 15 years ago. Today, I feel it is, but definitely not 15 years ago.
15 years back people were given Windows macOS and Linux and people voted which OS were ready for the Desktop and which were not. The only BS is your inflammatory contribution to this topic.
The average user only cares what they can run on the desktop. Linux did not have as much choice back then.
I can’t tell if this is satire.
> windows and macos cant even do proper window managing for a start
Well they certainly manage them better than x11 and wayland. What a fucking nuts thing to say. Are you rms?
Windows is reasonably OK, but MacOS' window management has always been really terrible.
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.
I don't use a Mac, but have you ever used Windows?
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.
Windows allows you to launch applications from a menu or via search. You can switch between windows with a mouse or keyboard shortcuts. Windows can either be floating, arranged in pseudo-tiled layers, or full screen. KDE can pretty much do the same under Wayland. Ditto for Gnome under Wayland, albeit to a lesser degree. That covers the bases for most people.
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.
> and Windows and Linux are identical and merely have different icons
At least on this we can agree, but windows never had to reboot the window server in my experience
I don't really understand what is supposedly missing in Wayland for productivity users? At work I have been using gnome with the wayland backend for years at this point and I can't really figure out anything that's missing.
Accessibility is apparently a big problem with wayland. E.g., the most popular / ?only? app that supports hardware eye trackers on Linux does not work with wayland, and states that it likely never will as wayland does not provide what it needs to add support (it is also the most popular app for voice/noise control). Even basic things like screen readers are apparently still an issue with wayland. Without a strong accessibility story, systems running wayland would have been banned at my last employer (a college).
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.
This is the kind of initiative I’d prefer to see from X preservationists. Great job, I hope it succeeds. I prefer Wayland, but there’s still a place in the world for X; it just needs new dev teams to shoulder the burden.
I disagree. The choices in the Linux ecosystem lead to unnecessary fragmentation and development/packaging nightmares.
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 choices in the Linux ecosystem lead to unnecessary fragmentation and development/packaging nightmares.
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.
The *original* X11 should die, but the modern Linux GUI stack has long abandoned most of its features anyway. X11 was already reduced to a bit-blitter protocol long before Wayland.
So, in theory, we can embrace a rather-minimal X11 implementation that can run the modern UI, including some desktop features missing in Wayland.
This is the worst argument ever. The choices in the Linux community is what's made it the best OS in the world today.
The name Phoenix is overused. There is an Elixir framework called Phoenix. I think I also heard of other projects with that same name before.
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...
From the ashes of some previous project is born some new project.
It's symbolic.
I remember people naming new software projects this back in the 1980s for the same reason.
It's a great name but way overused. I guess everything these days rose from ashes of past failures. Sector is highly competitive.
Firefox tried to use it and was sued for trademark infringement. wxPython also has a Phoenix project. It's definitely a catchy, but overused, name.
I don’t think the problem was with “phoenix”.
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.
As the application author you can set the release mode in the build script so that the release flag looks like `zig build --release` instead, and the user doesn't choose the optimization mode.
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 have no idea how well this one works, but I am all up for more projects that can compete against the singularization that corporations currently try (see paid developers for wayland, GNOME and now also KDE). I wonder how much money would be needed to make the xorg server adapt to the modern era; I don't even know the featureset that is missing for this either. But I also know that wayland, after 20 years (!!!), will never cover those requests users had over tohse 20 years, simply because it tries to cater to a narrow specification wanted by corporations rather than the people - so much is now clear (wayland protocol was released in 2008, so it is soon 20 years actually; in a few days we have 2026, so it will be 18 years).
So … does xterm work? emacs? xfig? ghostview? xload? xev? oclock? xmodmap? xpilot?
It’s possible that most of old X11 toys would not work properly, because many of them rely on X11 drawing APIs, but they are pretty simple to implement anyway.
Multiple screens support is listed as non-goal. Would that prevent its usage with window managers which support virtiaul desktops? I am i3 user and it is a critical feature for me.
In short: No.
In X11 "screen" has a particular meaning, and only supporting a single screen doesn't preclude multi-monitor support or virtual desktops.
Is this why back in the day sometimes a Linux distro would have a multi-monitor setup where each monitor was an actual different desktop cube for example. There was a time when each window for an Nvidia graphics card in that type of configuration could not be moved from one screen to another, etc.
Yep!
As others have already mentioned, the continuous multi-monitor(Xinerama) was an afterthought. A good news is that, by design, it’s actually pretty easy to add in the later steps.
> The compositor will get disabled … if the client runs a fullscreen application and disabled vsync in the application.
This is interesting to me, why would vsync being enabled mean that the desktop compositor needs to stick around for a full screen app?
I imagine because vsync and triple buffering introduce latency. There are cases like games where you don't want all that lag.
If the goal was to reduce latency, wouldn’t you want the desktop compositor out of the way when vsync is on?
First my mind went to Phoenix (elixir framework), then to X (twitter) before it clicked what this was actually about. Some very overloaded names
The meaning of 'X server' has been well-established for 30+ years.
(tangent)
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.
The server runs on the machine that allows clients to connect to it. What is the confusing part about this?
X has the terminology the other way around compared to all other consumer facing software.
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.
I think most of the confusion arises because when you are tunneling X via ssh, the X client/server is the reverse of the shh client/server.
Add to that that the user manages the ssh connection while the X connection is managed for them...
The part that is counterintuitive to most people when it comes to the "server" terminology is that, with X, your end-user workstation (which may be an incredibly dumb X terminal) is the "display server", which means you remote into a server (in the traditional sense) elsewhere, which then acts as an X client by making requests to your local machine to display windows.
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.
I think the confusion is obvious, given a little empathy for the range of people who use computers.
The server is usually a remote machine, especially back in the time when "client-server" architecture was emerging in mainstream (business) vernacular.
The server is not usually a remote machine. The server is the app accepting remote connections.
This has been true for decades.
https://en.wikipedia.org/wiki/Server_(computing)
Please don't imagine that I don't fully understand this.
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.
Yes, it’s simultaneously logical if you look at how it works and immensely strange if you don’t understand the architecture. (As has been noted all the way back to the UNIX-HATERS Handbook[1], although, pace 'DonHopkins, the NeWS Book uses the same terminology—possibly because it was written late enough to contain promises of X11/NeWS.)
[1] https://www.donhopkins.com/home/catalog/unix-haters/x-window...
Programmers aren't good at checking if the name is taken. We've done this particular one before. Phoenix (Firefox) had to change names because of Phoenix Technologies, then again because of the Borland Firebird Database.
Phoenix was also the name of Mozilla's browser before they changed it to Firefox
I'm hoping they go with phoenix11 #seewhatididthere
Another potentially interesting project is zigx, an X11 client library for Zig applications:
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.
Bit of an observation, but I've noticed that there's been quite a few pragmatic projects started in Zig. Bun vs Deno comes to mind (one focused on DX, the other on security), and now this vs Wayland. Not to say that designing something properly is wrong, just that it tends to throw away a lot of important interoperability.
I finally caved and switched to Wayland 6 months ago or so. Things just work so much more smoothly.
If you are not going to implement X11 drawing ops and XRender (which I, and many others, still use heavily), what's even the point? Any 'modern' program that only does client-side rendering already supports Wayland. AFAIK GTK 3 doesn't even support DRI on X11 unless you somehow trick it into using the abandoned OpenGL Cairo backend, but that's not modern enough apparently.
Where do they say they're omitting drawing and xrender?
It talks about trimming 'legacy' features and specifically says they are omitting 'font-related' operations. That obviously means no useful core X11 application will work (unless you count xlogo and xeyes). Whether the XRender glyph cache mechanism is included is unclear. It also says only DRI is *currently* supported, but maybe that's incidental?
If I could give a comment HN Gold, it would be this comment. 3 times.
Are different DPIs for different monitors supported too?
No active development in the last 4 months?
Nice! We do need more X servers, since Wayland refuses to incorporate essential protocol elements due to religion.
Yeah, we should introduce competition. It doesn’t feel like Wayland is improving these days. Missing features force me to hit X11 regularly, and I still get Wayland session crashes etc, while X11 could happily run over a year without crash and run all applications I need without issues.
Cool project I guess, don't see the point but technically interesting. Will be cool to have another modern display protocol/server. I personally would have rewritten Wlroots in Zig or something, but I guess this is more interesting.
So this can be an interesting option for XWayland?
Well no because it's not actually compatible with X11
Complements XLibre[0], an active fork of the X11 server from Xorg.
XLibre is trying to advance the existing implementation which Xorg abandoned, whereas Phoenix is writing a new, compatible server from scratch.
0. https://github.com/X11Libre/xserver
XLibre is a joke. They're making changes for the sake of changes: for example, commit aefde9 strips out vendoring in an ad-hoc, incomplete fashion (introducing a minor spacing bug in the process); and commit aafd986 replaces `int` with `unsigned int` (instead of `size_t`), failing to properly fix the bug that the compiler warnings identified (albeit, also removing an unrelated C footgun along the way, so this does look like a bug fix). The main author has a history of cowboy commits: 533c45e (which made it into mainline Xorg before he got kicked out) straight-up prevents hw/xfree86/os-support/bsd/arm_video.c from compiling, so it's clear there's no actual testing taking place.
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.
Yeah but wayback doesn't lend itself to the "omg my x11 I could neverrrrr :huff-emoji: :huff-emoji:" hysteria.
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.
Here's two complaints: it's a security theater, and it's horribly balkanized by design.
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?
OK, you can't have your preferred environment because someone else has a different use-case.
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.
It's christmas and not april fools!
But this is a treat, not a silly joke!