Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yserver: A modern X11 server written in Rust

github.com

Post reply on HN
Print view View original

41–50 of 131 posts

Re: Yserver: A modern X11 server written in Rust

#41

Post by mort96 »

to11mtm wrote: post #39
mort96 wrote: post #29

Earlier quoted context omitted.

So .. still using sockets, but not documenting how the messages on the socket look? Why?

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?

Re: Yserver: A modern X11 server written in Rust

#42

Post by nananana9 »

mort96 wrote: post #18
nananana9 wrote: post #14

Earlier quoted context omitted.

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 th…

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.

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

Re: Yserver: A modern X11 server written in Rust

#43

Post by ethanpailes »

le-mark wrote: post #12

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.

https://github.com/wayland-transpositor/wprs

Re: Yserver: A modern X11 server written in Rust

#44

Post by to11mtm »

mort96 wrote: post #41
to11mtm wrote: post #39

Earlier quoted context omitted.

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.

Re: Yserver: A modern X11 server written in Rust

#45

Post by aleph_minus_one »

Concerning the name "Yserver": be aware that there also existed (the implementation is still available for download) the "Y Window System"

> https://www.y-windows.org/

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

Re: Yserver: A modern X11 server written in Rust

#46

Post by ndiddy »

ltrever wrote: post #26
somat wrote: post #11

Earlier quoted context omitted.

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…

Can you pls share smt on how to properly do multi dpi in X? It is hard to find and I struggle with it

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

Re: Yserver: A modern X11 server written in Rust

#47

Post by TiredOfLife »

le-mark wrote: post #12

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.

Sunshine/Moonlight.

Re: Yserver: A modern X11 server written in Rust

#48

Post by mort96 »

nananana9 wrote: post #42
mort96 wrote: post #18

Earlier quoted context omitted.

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.

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…

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.

Re: Yserver: A modern X11 server written in Rust

#49

Post by hypfer »

I'm really just tired of all these "projects" that in the end just turn out to be Claude.

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 :(

Re: Yserver: A modern X11 server written in Rust

#50

Post by Gigachad »

ltrever wrote: post #26
somat wrote: post #11

Earlier quoted context omitted.

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…

Can you pls share smt on how to properly do multi dpi in X? It is hard to find and I struggle with it

This + mixed refresh rate are the key selling points of Wayland.
Post reply on HN