Yserver: A modern X11 server written in Rust(github.com) |
Yserver: A modern X11 server written in Rust(github.com) |
by Mark Thomas as an experimental sucessor of the "X Window System" (its 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 the "Y Window System":
> 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.
Old versions of GIMP (back when the toolbars etc. were separate windows) used to let you move any of its windows to a different X screen. And by "move" I don't mean drag - there was a menu where you could select the screen to move to.
[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.
edit: AND i've been using GNU/Linux and derivatives for the last 20 years.
What they are talking about is supporting more than one of those, and from app's perspective they are completely separate (can't move windows between them).
While I can see the use cases (say secondary screen only running single app) I never actually used that feature so it's understandable drop.
At least it is worth reading.
- [0] https://wayland.fyi/
And for example, it's a weird signal to me when somebody believes the reason X11 has baggage is because it does byte swapping for endianness. This statement alone taints the entire rationale for the project.
Xorg worked under nvidias for years.
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.
yeah actually, i think this is great. It shows that with AI we dont have to listen to Lennart Poopering and the gang of un-fun dicks from ugly disgusting european Redhat employees.
Also this is slop.
Is anything done with AI automatically slop? I don't understand this
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.
Security-wise there are concerns but...
Early dial-up Internet days (early for me), 28.8k modem, I was already running Linux, probably on a 486. I also had a very old PC laptop (I think a friend of my parents gifted it to me after he got a new one from work), a 386 I think (with the horrible slow display/refresh rate: a TFT IIRC). I used a parallel cable and PLIP (Parallel Line IP) and X11 networking to send a window manager+browser from the desktop (the 486) to the laptop.
So my brother and I could both go on the Internet at the same time.
It felt like the future and, honestly, we've kinda seriously regressed when it comes to "GUI over the network".
waypipe ssh XXXThe 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...
The kde one doesn't support remote user login, and while the gnome one does on paper, I never got it to work. The remote connection situation in Wayland is a major regression.
I have to wonder if the fact that Wayland either never had or has only very recently gotten support for applications that need to place their windows at application-commanded locations on the screen meant that those lovely tear-off menus had to die.
Look, I've been writing open source software for 20+ years, and after getting seriously burned out by it, I picked it up again with Claude (proof: https://github.com/jleclanche)
I can tell you a few things from that:
1. I'm writing better software than before, because AI is less lazy than I am. It's not necessarily always smarter, but writing correct software has gotten so stupidly cheap that it doesn't make sense not to do things right... so when you tell AI to do things correctly, it tends to know what you're talking about.
2. I'm more curious than before, because AI gives me time to explore many paths, very fast. A project like this one, like someone else said elsewhere in the comments, is more about the journey than the destination.
There is no "write me an X11 server but do it in rust and post on hn" prompt that does the thing. There's a journey of building, learning, understanding.
I'm not saying the resulting software is particularly valuable, but the journey is. This is HN, and you're shitting on someone who is using the most powerful pieces of technology we've achieved to go on a journey of discovery of X11 internals for the past 2 months. It's just shameful.
And yeah, if I were the author, I'd run claude over all the transcripts and extract a story with what's been taught and learned throughout. But I'm not the author. Just someone enjoying living in absolute science fiction.
I can't recall any application able to use multiple X11 screens (except in the trivial sense that you could set DISPLAY when starting the application), and I've been using X11 since X11R4.
Xinerama (the extension that enables one virtual screen over multiple outputs) existed before but the layout could only be defined statically - so you'd need to restart your X server with a different config if you wanted to connect a monitor or a projector or something.
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...
I've tested per-monitor DPI before, and [0] mentions one way to do it. I tested per-monitor refresh just now. Using the xrandr CLI to set the refresh rate to 24.0 on my primary monitor and 60.0 on my secondary results in "cinematic" visuals on the primary monitor and "soap opera" visuals on the secondary.
I'm currently using Windowmaker, but I see no reason why this wouldn't work with KDE.
Using the xrandr CLI to set the refresh rate to 24.0 on my primary monitor and 60.0 on my secondary results in "cinematic" visuals on the primary monitor and normal "soap opera" visuals on the secondary. Setting the refresh rate back to 60 on my primary results in "soap opera" visuals on both.
I'm currently using Windowmaker, but I see no reason why this wouldn't work with KDE. I'm using xorg-server 21.1.23 (which supports RandR 1.6), xf86-video-amdgpu 25.0.0, xrandr CLI version 1.5.4, and kernel 7.0.12.
I'm on Gentoo Linux. I would not be surprised to learn that Debian (and Debian-derived distros) never shipped a version of Xorg or the related libraries where this worked correctly.
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.
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.
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.
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.
Or would the receiver spin in a tight loop on a memory load from some byte in shared memory which indicates a new buffer is submitted, so that it gets notified without involving the kernel? Or is there some fancy mechanism I’m not aware of?
I would probably expose a poll() and let the client deal with it, I don't know if there's a one-size-fits-all signaling mechanism. But you have control over it, which is probably another plus.
Speaking of... it looks like common Wayland compositors [0] still kill clients that can't keep up with "high speed" event generators like 1kHz mice. [1] So, that's nice.
(For people who plan to retort with "just handle events in a timely manner", check out the comment here [2]. OSX, Windows, and X11 all cope just fine with programs that go unresponsive for multiple seconds. If the statements in this bug report (and the reports I've read elsewhere) are accurate, Wayland doesn't... and that is inexcusable.)
[0] ...or whatever the Wayland terminology is for the thing that does the work of the X11 compositor + window manager...
[1] <https://gitlab.freedesktop.org/wayland/wayland/-/work_items/...>
[2] <https://gitlab.freedesktop.org/wayland/wayland/-/work_items/...>