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

61–70 of 131 posts

Re: Yserver: A modern X11 server written in Rust

#61

Post by scrollaway »

hypfer wrote: post #53
scrollaway wrote: post #52

Earlier quoted context omitted.

Ah yes, the famous zero-shot X11 server. Aren't you clever.

Would you be happier if I wrote "the prompts"? 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.

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.

Re: Yserver: A modern X11 server written in Rust

#62

Post by calvinmorrison »

hypfer wrote: post #49

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

[flagged]

Re: Yserver: A modern X11 server written in Rust

#64

Post by nananana9 »

mort96 wrote: post #58
nananana9 wrote: post #54

Earlier quoted context omitted.

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…

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

You most likely already have a tight loop lying around - the compositor needs to composite the screen each frame, you can probably poll in there. The client likely has one too, if not, you can involve the kernel & scheduler. If you need super high precision you probably busy wait, I don't know what the Linux scheduler's resolution is.

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.

Re: Yserver: A modern X11 server written in Rust

#66

Post by mort96 »

nananana9 wrote: post #64
mort96 wrote: post #58

Earlier quoted context omitted.

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

You most likely already have a tight loop lying around - the compositor needs to composite the screen each frame, you can probably poll in there. The client likely has one too, if not, you can involve the kernel & scheduler. If you need super high precision you probably busy wait, I don't know what the Linux scheduler's resolution is. I would probably expose a poll() and let the client deal with it, I don't know if t…

Those loops aren’t tight, they sleep for like 10-16ms for live windows or much longer for background windows. You were talking about receiving updates at 1000Hz.

Re: Yserver: A modern X11 server written in Rust

#67

Post by PunchyHamster »

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.

X11 "screen" you normally work on is a single virtual one that stretches multiple monitors

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.

Re: Yserver: A modern X11 server written in Rust

#68

Post by simoncion »

Gigachad wrote: post #50
ltrever wrote: post #26

Earlier quoted context omitted.

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.

Xorg does per-monitor DPI and per-monitor refresh rate. Debian probably never shipped a version that does, but it works fine on Gentoo Linux.

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.

[0] https://news.ycombinator.com/item?id=48533247>

Re: Yserver: A modern X11 server written in Rust

#70

Post by simoncion »

winrid wrote: post #27
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…

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

Post reply on HN