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

71–80 of 131 posts

Re: Yserver: A modern X11 server written in Rust

#71

Post by asveikau »

kennywinker wrote: post #15

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 was under the impression that this person is pretty heavily dependent on Claude.

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.

Re: Yserver: A modern X11 server written in Rust

#72

Post by Liskni_si »

somat wrote: post #11
simmonmt wrote: post #2

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…

> So realistically no application did this.

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.

Re: Yserver: A modern X11 server written in Rust

#73

Post by Liskni_si »

simmonmt wrote: post #9
chadgpt3 wrote: post #3

Earlier quoted context omitted.

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)

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.

Re: Yserver: A modern X11 server written in Rust

#74

Post by dormento »

skeledrew wrote: post #20

> dropping legacy baggage (multiple screens[...] 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.

Unless I'm mistaken, they probably don't mean xrandr, which is what you probably use. They meant legacy x multi head setup (same session but independent screens). I know its there, but i never used it.

edit: AND i've been using GNU/Linux and derivatives for the last 20 years.

Re: Yserver: A modern X11 server written in Rust

#76

Post by winrid »

simoncion wrote: post #70
winrid wrote: post #27

Earlier quoted context omitted.

The downside is your refresh rate is locked to the slowest monitor.

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…

It's possible it has been fixed in the last couple years but for a while it was the case.

Re: Yserver: A modern X11 server written in Rust

#77

Post by simoncion »

nananana9 wrote: post #54
mort96 wrote: post #48

Earlier quoted context omitted.

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…

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

> But imagine some piece of exotic hardware, e.g. computer mouse, that reports its movement at 1000Hz.

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

Re: Yserver: A modern X11 server written in Rust

#78

Post by simoncion »

Liskni_si wrote: post #72
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…

> So realistically no application did this. 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.

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.

Re: Yserver: A modern X11 server written in Rust

#79

Post by sthuck »

ndiddy wrote: post #33
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.

If you're fine with RDP, both KDE and GNOME have built-in RDP support on Wayland. If you want something closer to ssh -X, look up waypipe.

I might be mistaken, but both need a physical monitor turned on. If your monitor goes to sleep you can't connect/see a black screen.

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.

Re: Yserver: A modern X11 server written in Rust

#80

Post by simoncion »

winrid wrote: post #76
simoncion wrote: post #70

Earlier quoted context omitted.

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…

It's possible it has been fixed in the last couple years but for a while it was the case.

Were you -perhaps- using GNOME and the GNOME-provided GUIs to change monitor refresh rate? Given GNOME's history of legendarily user-hostile decisions made in the name of "simplicity", it would surprise me not even a little bit that the GNOME folks decided to pretend that the active monitor with the lowest refresh rate dictated the fastest you could drive any monitor.
Post reply on HN