I compiled it on Debian 13, and it does work XFCE4, but things are a bit squirrely until you disable the compositor. Sadly, no luck getting it to play nicely with LightDM. Ended up launching it from a TTY. This was on an AMD mini PC I had lying around the studio.
I really wish people gave a damn about the “gui over the network” problem x11 solves. Wayland drops this use case entirely so we’re pretty much universally stuck with vnc. Microsoft rdp is a great solution for this in windows land.
They drop this use-case, but still use sockets for IPC, so I still have to pretend I'm doing network programming, serialize my messages over the "network" and "flush the stream" (insanity) but don't actually get any of the benefits of this model.
I genuinely wonder if they stopped to think why X11 has sockets or just blindly copied it over. Or are they unaware other forms of IPC exist, that don't require you to go through the kernel 13 times to send a byte to the other process?
What would you rather they use to communicate with the server? Message passing via shared memory?
UNIX sockets are perfectly fine for IPC with small amounts of data, and is how everything in UNIX has always done it, network transparency or not. They provide a simple, efficient and reliable communication channel between two processes.
Wayland uses UNIX socket for message passing, but then offload most of the work to shared memory when the real work begins (GPU rendering). I just wanted to add some nuances that it's not as black and white as this comment made it seem.
How about making the standard client library's API the interface, and have it hide whatever the system is actually using?
A long time ago when I looked at designing a X11 replacement, that was my approach. AFAIK, only special X utilities used anything but Xlib anyway.
And later I think this is what early revisions of Canonical's Mir did.
If I had to guess, because then at least -hypothetically- easier to optimize for the 'local' case (depending on implementation, at least from my understanding of the POSIX/*nix paradigm, bending and breaking a bunch of rules possibly) by dropping in a different implementation.
Optimise how? There already is only the local case in Wayland, pixel data is shared using shared memory which only works locally. Only small communication messages are sent via the socket. And the Wayland protocol also uses native endianness because, again, it only cares about the local case. It even sends file descriptors over the socket.
So what would you do differently in an alternative client library?
> So what would you do differently in an alternative client library?
I should have better disclaimed my comment.... to be clear I don't know much about the graphics subject, I probably should have prefaced it with,
"I don't know anything about Wayland but as someone totally naieve on the subject but assuming someone else's assumption".
At least to me, even if it breaks the X11 model (Which is a shame, that was fun to play with back in the day) if they're doing it the way they are I'm guessing Chesterton's fence will come into play at one point or another.
Yes, command buffers over shared memory are the correct way to do this.
1. You don't need to convert your discrete messages into a stream with size metadata, only for them to immediately be converted to a message on the other side.
2. You don't need to jump into the kernel to copy over 20 bytes, only for the other side to jump into the kernel to copy it back.
3. You don't need to deal with the "oh but what if my read returns half a message because this is a stream"
4. You don't need to pretend you're doing network programming.
Regardless, it's not that big of a deal - this is like my 73th biggest gripe with Wayland, I only mentioned it since GP was talking about network transparency.
It's pretty representative of the project though - "We're doing things the way we've always done them, but slightly different. Now rewrite all your software to work with our thing. No, you cannot do global keyboard shortcuts or set window position. You don't like it? We're doing this for free, you cannot critique it."
You don’t have to hit the kernel for 20 bytes. Buffer up all your commands and send them to the kernel with a single write(). The other side can then read them all (or however many fit in its receive buffer) with a single read(). The only real difference is that the memcpy happens in the kernel instead of the receiver and that the kernel provides a useful blocking mechanism by default so you don’t have to manage that in userspace code.
You need some kind of serialisation either way. It can be as simple as “this message has the shape of this C struct”, but that’s the case whether you’re talking shared memory command buffers or sending data over a socket (and there are good arguments for and against in both cases).
You’re right that you don’t need to deal with “oh I received half a message” when using shared memory command buffers, but that’s more a code complexity thing someone solves once in wayland-client and then nobody has to really think about it again. It’s not really a performance concern (because hopefully the rx buffer is large enough for it to happen rarely) or application code complexity concern.
Sure. But imagine some piece of exotic hardware, e.g. computer mouse, that reports its movement at 1000Hz.
If the compositor wants to notify the client as soon as possible, it has to send 1000 messages per second. If you buffer them, you're wasting the hardware's potential, if you don't buffer, them you're doing 1000 write()s per second, which is... ugh.
If you're literally going to design the protocol from scratch and require all existing software to deal with it, why not pick the IPC model that doesn't have this issue.
Wait how do you solve that with shared memory command buffers? Don’t you need to involve the kernel to notify the receiver that you’ve written stuff to the command buffer?
Or would the receiver spin in a tight loop on a memory load from some byte in shared memory so that it gets notified without involving the kernel? Or is there some fancy mechanism I’m not aware of?
Not really, you can have one command buffer per client or process, and map each one in the virtual space of the process that's supposed to write to it.
by Mark Thomas as an experimental sucessor of the "X Window System" (its further development has been cancelled for a long time; the latest release that is available on this website is from 2004).
This is pretty cool - especially that it's at the point where it can be used with a real window manager.
I'm curious why multiple screens is considered legacy baggage and thus out of scope, given how common multiple monitor setups are these days. I also have zero familiarity with X internals, so don't know if multiple monitor support is a horror show that'd be miserable to support.
I suspect(with out reading the source to find out) that screens are the traditional X11 screens as opposed to the modern xrandr combined screen.
Traditionally each screen in an X11 setup was it's own separate thing with it's own separate frame buffer. While technically applications could move between screens, this depended on the application caring enough to do so. It had to maintain two(or more) mirrored windows(one per screen) and keep them all aligned. So realistically no application did this.
The modern method of doing multi monitors on X11 involves one large virtual screen with each monitor assigned a section of it. This has downsides, for example; this is where the myth that X11 can't do mixed DPI setups comes from. But it has one huge massive overwhelming upside. The application does not have to be aware that there are multiple screens and multi monitor setups just work.
Just did a quick `xrand -q` to confirm I'm doing multiple DPIs, etc (cuz laptop and external monitor) on a single screen with 0 issues. Unless the physical misalignment of the monitors, which reflects as a vertical jump when moving the mouse pointer across the virtual boundary, can be considered an issue.
The mixed DPI support on X11 is just that each monitor provides a DPI attribute that applications can query. It's up to the application or the toolkit it uses to actually look at this attribute and scale itself properly. In practice, this means that only Qt software will have DPI awareness on multi-monitor setups, and it requires having the "QT_AUTO_SCREEN_SCALE_FACTOR=1" environment variable set for applications that don't explicitly opt into it.
What most X11 users actually do is set the global DPI to that of the highest DPI monitor, and use xrandr to scale down the framebuffer of the lower DPI monitor, which "zooms it out". Note that this has performance and image quality implications. There's a guide on how to do this here: https://blog.summercat.com/configuring-mixed-dpi-monitors-wi...
X screens are legacy. It used to be you could connect to a particular screen by number to open windows on that screen but the modern way to do it is to have one big virtual screen. X screens were like having a separate X server for each monitor, but with a single shared cursor and shared VRAM. You can see why that's an obsolete model.
Yep. When did virtual screens come in? My last full time experience with X was with Xsun in the early 2000s under Solaris. There was a shared cursor, I thought you could drag windows between monitors, but I also thought the DISPLAY variable was different for each (though I could be misremembering)
Looked nice, but crossed it off as soon as I saw that, as I'm working on a project currently that uses many screens. Can't just call a thing legacy because you and the people you directly know aren't using it.
Maybe they mean X11-screens. That are more or less independent screens, you can't move a window from one to the other for example.Emacs supports that somewhat with the "open new frame on display server" menu option, but usually, multiple screens are not very useful.
Nowadays, multiple monitors present one big virtual framebuffer and only one logical X11 screen.
It is a niche feature, but it is still used eg when an application wants to have good control over a screen's frame buffer to display sth in an external monitor and minimise disturbances. I think it is fairly standard in psychophysics experiments, at least with some software. That's where I worked with such a ("zaphodsheads") setup.
The normal, usable way to have multiple monitors for your X11 desktop environment is for them to all be combined into one logical screen that you can move windows around in, and that applications aware of the right extensions can discover the actual physical layout of the monitors that comprise the single logical screen. Multiple screens in that X11 sense is a far more obscure feature than simply supporting more than one physical monitor.
Love seeing this. I'd be interested in seeing how much more could be shaved off by doing things like offering an xcb/xlib shim that moves more functionality to the client side (e.g. server-side font support are trivial to move client-side) as a means to deprecate features on the server side that most modern X11 apps don't use anyway.
Projects like this really need to disclose how much ai was used. Otherwise my default assumption is it’s slop, which would be a bummer if someone carefully crafted this with some light ai assistance.
I agree, as soon as people start proudly tagging their vibe-coded projects, the sooner people will stop judging AI projects as "slop" based on nothing at all.
I genuinely wonder if they stopped to think why X11 has sockets or just blindly copied it over. Or are they unaware other forms of IPC exist, that don't require you to go through the kernel 13 times to send a byte to the other process?
UNIX sockets are perfectly fine for IPC with small amounts of data, and is how everything in UNIX has always done it, network transparency or not. They provide a simple, efficient and reliable communication channel between two processes.
A long time ago when I looked at designing a X11 replacement, that was my approach. AFAIK, only special X utilities used anything but Xlib anyway. And later I think this is what early revisions of Canonical's Mir did.
So what would you do differently in an alternative client library?
I should have better disclaimed my comment.... to be clear I don't know much about the graphics subject, I probably should have prefaced it with,
"I don't know anything about Wayland but as someone totally naieve on the subject but assuming someone else's assumption".
At least to me, even if it breaks the X11 model (Which is a shame, that was fun to play with back in the day) if they're doing it the way they are I'm guessing Chesterton's fence will come into play at one point or another.
It's pretty representative of the project though - "We're doing things the way we've always done them, but slightly different. Now rewrite all your software to work with our thing. No, you cannot do global keyboard shortcuts or set window position. You don't like it? We're doing this for free, you cannot critique it."
You need some kind of serialisation either way. It can be as simple as “this message has the shape of this C struct”, but that’s the case whether you’re talking shared memory command buffers or sending data over a socket (and there are good arguments for and against in both cases).
You’re right that you don’t need to deal with “oh I received half a message” when using shared memory command buffers, but that’s more a code complexity thing someone solves once in wayland-client and then nobody has to really think about it again. It’s not really a performance concern (because hopefully the rx buffer is large enough for it to happen rarely) or application code complexity concern.
If the compositor wants to notify the client as soon as possible, it has to send 1000 messages per second. If you buffer them, you're wasting the hardware's potential, if you don't buffer, them you're doing 1000 write()s per second, which is... ugh.
If you're literally going to design the protocol from scratch and require all existing software to deal with it, why not pick the IPC model that doesn't have this issue.
Or would the receiver spin in a tight loop on a memory load from some byte in shared memory so that it gets notified without involving the kernel? Or is there some fancy mechanism I’m not aware of?
The people who put together TS/RDP are geniuses IMO, it's insane as to how usable it has been for at least 15-ish years...
> https://www.y-windows.org/
by Mark Thomas as an experimental sucessor of the "X Window System" (its further development has been cancelled for a long time; the latest release that is available on this website is from 2004).
The German Wikipedia still mentions it:
> https://de.wikipedia.org/w/index.php?title=X_Window_System&o...
I'm curious why multiple screens is considered legacy baggage and thus out of scope, given how common multiple monitor setups are these days. I also have zero familiarity with X internals, so don't know if multiple monitor support is a horror show that'd be miserable to support.
Traditionally each screen in an X11 setup was it's own separate thing with it's own separate frame buffer. While technically applications could move between screens, this depended on the application caring enough to do so. It had to maintain two(or more) mirrored windows(one per screen) and keep them all aligned. So realistically no application did this.
The modern method of doing multi monitors on X11 involves one large virtual screen with each monitor assigned a section of it. This has downsides, for example; this is where the myth that X11 can't do mixed DPI setups comes from. But it has one huge massive overwhelming upside. The application does not have to be aware that there are multiple screens and multi monitor setups just work.
What most X11 users actually do is set the global DPI to that of the highest DPI monitor, and use xrandr to scale down the framebuffer of the lower DPI monitor, which "zooms it out". Note that this has performance and image quality implications. There's a guide on how to do this here: https://blog.summercat.com/configuring-mixed-dpi-monitors-wi...
[1] https://en.wikipedia.org/wiki/Xinerama [2] https://xorg.freedesktop.org/archive/X11R7.5/doc/man/man1/xr...
Looked nice, but crossed it off as soon as I saw that, as I'm working on a project currently that uses many screens. Can't just call a thing legacy because you and the people you directly know aren't using it.
Nowadays, multiple monitors present one big virtual framebuffer and only one logical X11 screen.
The normal, usable way to have multiple monitors for your X11 desktop environment is for them to all be combined into one logical screen that you can move windows around in, and that applications aware of the right extensions can discover the actual physical layout of the monitors that comprise the single logical screen. Multiple screens in that X11 sense is a far more obscure feature than simply supporting more than one physical monitor.
Xorg worked under nvidias for years.
Also this is slop.
Is anything done with AI automatically slop? I don't understand this
There is no need to put this code on GitHub. Everyone with an API key can achieve the same if you hand them the prompt.
This is like committing build artifacts to version control.
On top it's such a lame idea. "What if rewrite in rust applied to X server". Fits on a napkin. Man what a nothingburger :(
Would that change anything about the fundamental cliche-ness here?
Also, no, I'm not clever, but not sure what that has to do with this comment chain.