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.
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.
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).
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.
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.
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.
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.
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 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 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. Seriously.
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.
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.)
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.
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?
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.
Long term if x11 starts having issues then probably https://gitlab.freedesktop.org/wayback/wayback will be it
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.
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.
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).
My rpi dashboards are gonna love 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.
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.
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.
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.
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.
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.
Be the change you want to see.
Also happy winter solstice.
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.
> 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?
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.
> 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
[delayed]
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?
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. Seriously.
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.
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...
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!
It's christmas and not april fools!
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.
Are different DPIs for different monitors supported too?
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?
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