Yserver: A modern X11 server written in Rust

I really miss the tear-off-into-their-own-window menus. They were so handy.

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.

This report doesn't agree with what I tested 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 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.

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...

This + mixed refresh rate are the key selling points of Wayland.

$DISPLAY is definitely different for each X11 screen, ie. :0.0 for the first screen, :0.1 for the second and so on. (:1, :2 is used for more instances of the X11 server).

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.

2007 is when xrandr 1.2 came and made it feasible to use on a laptop - enable/disable outputs dynamically without restarting X.

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.

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.

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."

I'm just so tired of these lazy, worthless comments about any AI-written software.

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.