_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Yserver: A modern X11 server written in Rust
LeFantome wrote 5 hours 7 min ago:
It is kind of ironic that all the would be X successors waiting until
Wayland took over before appearing.
Something like XLibre or Phoenix would have been taken very seriously 5
years ago.
Ferret7446 wrote 3 hours 44 min ago:
I think it was only recently that Xorg started dying and Wayland
became mostly usable for most people. That was when I switched over,
and I assume a lot of others as well.
drnick1 wrote 6 hours 9 min ago:
Yet another vide-coded, MIT-licenced Rust rewrite, yawn.
sunshine-o wrote 7 hours 32 min ago:
The wayland.fyi people might have a point on the whole X11 vs Wayland
thing [0].
At least it is worth reading.
- [0]
HTML [1]: https://wayland.fyi/
Venn1 wrote 7 hours 49 min ago:
I compiled it on Debian 13 and it works with XFCE4. Granted, things are
a bit squirrely until you disable the compositor. No luck getting it to
play nicely with LightDM so I ended up launching it from a TTY. This
was on an AMD mini PC I had lying around the studio.
hypfer wrote 8 hours 0 min ago:
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 :(
calvinmorrison wrote 7 hours 37 min ago:
a nothing burger as REDHAT is 10 years into their pathetic rugpull of
Wayland destroying 40 years of UNIX GUI development and
infrastructure.
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.
scrollaway wrote 7 hours 55 min ago:
Ah yes, the famous zero-shot X11 server. Aren't you clever.
hypfer wrote 7 hours 51 min ago:
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.
jitl wrote 6 hours 9 min ago:
"Please don't give me a present on my birthday. Anyone with a
credit card could get me the same thing if you hand them the
url."
i'm personally okay receiving presents on my birthday even if
they were purchased from a store on the internet, and i'm okay
receiving software presents on github.com even if they were
purchased from a store on the internet.
scrollaway wrote 7 hours 38 min ago:
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: [1] )
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.
HTML [1]: https://github.com/jleclanche
goodmythical wrote 5 hours 49 min ago:
The fact that you're being downvoted for sharing a constructive
opinion and the rest of the "hurp durp this is slop" comments
aren't is vastly more of a problem on HN than curious
contributions like Yserver.
g-b-r wrote 3 hours 55 min ago:
It's very likely that in the end it will be the opposite, HN
is filled with AI enthusiasts
aleph_minus_one wrote 8 hours 4 min ago:
Concerning the name "Yserver": be aware that there also existed (the
implementation is still available for download) the "Y Window System"
> [1] 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":
>
HTML [1]: https://www.y-windows.org/
HTML [2]: https://de.wikipedia.org/w/index.php?title=X_Window_System&old...
simonask wrote 6 hours 8 min ago:
On general principle, I think 22 years of inactivity is perfectly
reasonable for considering any software project perfectly dead.
goodmythical wrote 5 hours 57 min ago:
On general principle, I think sharing but a single character
between names of products is perfectly reasonable for considering
any names perfectly seperable.
No one's comparing this to 'y'combinator or 'y'ahoo.
'server' and 'window system' are completely different...
aleph_minus_one wrote 6 hours 5 min ago:
That's why I wrote "existed" (simple past).
Klonoar wrote 2 hours 34 min ago:
The âbe awareâ is the problematic text; nobody cares that a
two decade old dead project has the same name.
vidarh wrote 8 hours 16 min ago:
Love seeing this. I'd be interested in seeing how much more could be
shaved off by doing things like offering an xcb/xlib shim that moves
more functionality to the client side (e.g. server-side font support
are trivial to move client-side) as a means to deprecate features on
the server side that most modern X11 apps don't use anyway.
skeledrew wrote 8 hours 32 min ago:
> 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.
dormento wrote 7 hours 4 min ago:
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.
PunchyHamster wrote 7 hours 25 min ago:
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.
wtallis wrote 8 hours 16 min ago:
I think X11 terminology may be causing some confusion. Refer to [1]
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.
HTML [1]: https://nouveau.freedesktop.org/MultiMonitorDesktop.html
skeledrew wrote 5 hours 21 min ago:
Ah yes I see it was a terminology issue. I was also confusing it
with virtual displays, which is what I'm using a lot of. Thanks.
rmu09 wrote 8 hours 24 min ago:
Maybe they mean X11-screens. That are more or less independent
screens, you can't move a window from one to the other for
example.Emacs supports that somewhat with the "open new frame on
display server" menu option, but usually, multiple screens are not
very useful.
Nowadays, multiple monitors present one big virtual framebuffer and
only one logical X11 screen.
freehorse wrote 7 hours 49 min ago:
It is a niche feature, but it is still used eg when an application
wants to have good control over a screen's frame buffer to display
sth in an external monitor and minimise disturbances. I think it is
fairly standard in psychophysics experiments, at least with some
software. That's where I worked with such a ("zaphodsheads") setup.
arcfour wrote 4 hours 3 min ago:
They are also roughly analogous to the modern DE concept of
"Workspaces" which people seem to enjoy.
self_awareness wrote 8 hours 38 min ago:
Why it "can't" work under nvidia?
Xorg worked under nvidias for years.
zeofig wrote 5 hours 16 min ago:
proompt didn't work
Venn1 wrote 7 hours 34 min ago:
And XFree86 before that.
kennywinker wrote 8 hours 38 min ago:
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.
cute_boi wrote 5 hours 49 min ago:
Checked and as with many project in HN, this is very slop..I am sure
author haven't even reveiwed more than 20% of the code.
asveikau wrote 7 hours 16 min ago:
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.
phendrenad2 wrote 8 hours 32 min ago:
I agree, as soon as people start proudly tagging their vibe-coded
projects, the sooner people will stop judging AI projects as "slop"
based on nothing at all.
hokkos wrote 8 hours 33 min ago:
Seems pretty accurately disclosed to me
HTML [1]: https://github.com/joske/yserver/graphs/contributors
le-mark wrote 8 hours 45 min ago:
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.
LeFantome wrote 5 hours 13 min ago:
You can do GUI over the network in multiple ways with Wayland.
TacticalCoder wrote 6 hours 42 min ago:
> I really wish people gave a damn about the âgui over the
networkâ problem x11 solves.
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".
simonask wrote 5 hours 45 min ago:
Your story here also illustrates why GUI over the network used to
be a much more important use case than it currently is.
These days itâs unbelievably niche, as opposed to more controlled
screen sharing scenarios. I think itâs understandable that it
doesnât get a high priority.
Induane wrote 7 hours 47 min ago:
Arcan has a decent model for this.
TiredOfLife wrote 8 hours 2 min ago:
Sunshine/Moonlight.
ethanpailes wrote 8 hours 4 min ago:
HTML [1]: https://github.com/wayland-transpositor/wprs
to11mtm wrote 8 hours 9 min ago:
> Microsoft rdp is a great solution for this in windows land.
The 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...
dannymi wrote 8 hours 15 min ago:
waypipe works very fine.
waypipe ssh XXX
ndiddy wrote 8 hours 17 min ago:
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.
sthuck wrote 6 hours 52 min ago:
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.
ndiddy wrote 4 hours 26 min ago:
Yeah that's fair, the KDE people have remote login as a goal but
it's not there yet. Waypipe is definitely the more mature option
at the moment if you need a headless workflow.
nananana9 wrote 8 hours 40 min ago:
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 through the kernel 13 times to
send a byte to the other process?
mike_hock wrote 51 min ago:
A fundamental part of the Wayland protocol is passing file
descriptors through the sockets so this doesn't generalize to
network sockets. It also can't be done with shared memory.
mort96 wrote 8 hours 34 min ago:
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.
nananana9 wrote 8 hours 6 min ago:
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."
mike_hock wrote 49 min ago:
> command buffers over shared memory are the correct way to do
this
Sounds like a security nightmare.
asdfaoeu wrote 7 hours 57 min ago:
You would have a lot of security issues right? Whether or not
it's useful Wayland does prevent to isolate clients from each
other.
mort96 wrote 7 hours 41 min ago:
Theyâre right on this one, shared memory isnât some scary
dangerous thing. Both processes will just have some region of
their respective virtual address space which are mapped to
the same physical memory, which they can use to share data.
Wayland already uses this for pixel data.
nananana9 wrote 7 hours 46 min ago:
Not really, you can have one command buffer per client or
process, and map each one in the virtual space of the process
that's supposed to write to it.
mort96 wrote 8 hours 2 min ago:
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.
nananana9 wrote 7 hours 51 min ago:
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
and require all existing software to deal with it, why not
pick the IPC model that doesn't have this issue.
simonask wrote 5 hours 49 min ago:
Just to let you know, 1000 messages per second over a UNIX
socket between two processes is very much well within the
capabilities of any recent machine running, say, Linux.
Thatâs not many at all.
simoncion wrote 6 hours 58 min ago:
> 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] < [1] > [2] < [1] >
HTML [1]: https://gitlab.freedesktop.org/wayland/wayland/-/w...
HTML [2]: https://gitlab.freedesktop.org/wayland/wayland/-/w...
mort96 wrote 7 hours 47 min ago:
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?
nananana9 wrote 7 hours 33 min ago:
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.
mort96 wrote 7 hours 28 min ago:
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.
Findecanor wrote 8 hours 27 min ago:
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.
dmytrish wrote 8 hours 18 min ago:
That's what wayland-client does.
mort96 wrote 8 hours 23 min ago:
So .. still using sockets, but not documenting how the messages
on the socket look? Why?
to11mtm wrote 8 hours 14 min ago:
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.
mort96 wrote 8 hours 9 min ago:
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?
to11mtm wrote 8 hours 4 min ago:
> 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.
p-o wrote 8 hours 28 min ago:
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.
mort96 wrote 8 hours 20 min ago:
Yeah, thatâs correct; I implied it by only talking about
sending small messages but itâs worth stating explicitly.
wmf wrote 8 hours 43 min ago:
Waypipe exists. Somebody needs to do the integration so you can run
ssh -W though.
LeFantome wrote 5 hours 10 min ago:
Why? Isnât âwaypipe sshâ more âthe UNIXâ way.
There is also wors.
IshKebab wrote 8 hours 59 min ago:
Why? Wayland hasn't been smooth sailing by any stretch but it's still
time to let X die.
Also this is slop.
L0Wigh wrote 7 hours 21 min ago:
Letting X11 die is stupid. It works perfectly fine and gives another
option than just Wayland
fb03 wrote 8 hours 14 min ago:
> Also this is slop.
Is anything done with AI automatically slop? I don't understand this
d4ng wrote 8 hours 56 min ago:
Maybe itâs more about the journey and not the destination.
simmonmt wrote 9 hours 9 min ago:
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.
somat wrote 8 hours 52 min ago:
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
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.
Liskni_si wrote 7 hours 15 min ago:
> 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.
simoncion wrote 6 hours 53 min ago:
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.
simonask wrote 6 hours 4 min ago:
FWIW, they have been unfashionable for much longer than Wayland
has been usable, on all platforms.
And thatâs understandable. Itâs not actually good
usability.
simoncion wrote 3 hours 1 min ago:
> Itâs not actually good usability.
They're really great on systems that let you hold a modifier
key and then a mouse button to drag windows around... rather
than requiring you to find the
very-small-compared-to-the-size-of-the-entire-window portion
of the window you can click to change the window position.
They get even better when you're on a system that reliably
remembers the position of application windows.
Folks who have never used a system that lets you relocate and
resize windows without first moving your mouse cursor to
"blessed" regions of the window absolutely do not know what
they're missing.
> ...they have been unfashionable...
Fashion is for people who love doing busywork. Where fashion
gets nasty is when that busywork makes a bunch of work for
everyone else.
obezyian wrote 6 hours 7 min ago:
The gtk3 docs give the following reason for the deprecation:
Menus are not meant to be torn around.
Yeah, they are meant to be implemented with web technologies
and look like shit.
BTW, this tear-off style is probably quite old. Long ago, I
used an early version of ANSYS (for Windows) which apparently
was still close to its Unix original, and it had its menus pop
up like real windows, with close buttons! They were nicely
cascaded, but one could rearrange them.
simoncion wrote 2 hours 52 min ago:
> BTW, this tear-off style is probably quite old.
Yeah, I agree with that. I was using some ancient X11 program
that had tear-off menus, but I'll be fucked if I can remember
which one it is.
> Yeah, they are meant to be implemented with web
technologies and look like shit.
Yuuuuuup. If you always take the "yes" side, you'll come out
quite a bit ahead of your fellow gamblers for the "Will GNOME
make things worse for sophisticated users and call it
'simplicity'?" wager.
skeledrew wrote 8 hours 14 min ago:
Just did a quick `xrand -q` to confirm I'm doing multiple DPIs, etc
(cuz laptop and external monitor) on a single screen with 0 issues.
Unless the physical misalignment of the monitors, which reflects as
a vertical jump when moving the mouse pointer across the virtual
boundary, can be considered an issue.
winrid wrote 8 hours 25 min ago:
The downside is your refresh rate is locked to the slowest monitor.
simoncion wrote 7 hours 18 min ago:
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.
winrid wrote 7 hours 2 min ago:
It's possible it has been fixed in the last couple years but
for a while it was the case.
simoncion wrote 6 hours 43 min ago:
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.
michaelmrose wrote 1 hour 22 min ago:
This is basically a built in limit of X. The only exception
is that monitors that support variable refresh rates may be
able to offer this feature in multiple monitor
configuration subject to software and hardware options.
I'm personally very dubious of the claim. This has
basically never been supported because x treats all screens
as one big screen unless you run multiple X screens which
disallows moving Windows between screens which is a pretty
big barrier to normal usage
ltrever wrote 8 hours 26 min ago:
Can you pls share smt on how to properly do multi dpi in X? It is
hard to find and I struggle with it
somat wrote 5 hours 49 min ago:
My favored article on the subject is
HTML [1]: http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/
Gigachad wrote 7 hours 58 min ago:
This + mixed refresh rate are the key selling points of Wayland.
arcfour wrote 4 hours 5 min ago:
I agree it used to be fiddly at best but in recent years I had
found it to be pretty easy in X11.
I haven't had complaints there for Wayland but I will say that
it breaking other things has been annoying.
simoncion wrote 7 hours 23 min ago:
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] < [1] >
HTML [1]: https://news.ycombinator.com/item?id=48533247
Gigachad wrote 4 hours 50 min ago:
Maybe it's possible now. It wasn't back when I last used X.
Now that Wayland is the default on most distros and works on
nvidia now I don't see any reason to go back.
simoncion wrote 2 hours 46 min ago:
Good for you? But mixed-monitor DPI and mixed-monitor
refresh rate haven't been key selling points of Wayland for
like eight to ten years, at least.
It has been nearly eighteen years since the Wayland project
started, and they are still not at feature parity with the
major windowing systems. [0] It's nuts how long it's taking
them. [1]
[0] As one example, apparently the Wayland policy for
clients that stop responding for a few seconds and fill up
their event mailbox is still to terminate the stuck client.
If memory serves, Windows 9x handled stuck clients better
than that.
[1] I'm sure it's good enough for what you're doing and you
never run into any rough edges or misfeatures, so don't
bother chipping in with that retort. ;)
ndiddy wrote 8 hours 2 min ago:
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:
HTML [1]: https://blog.summercat.com/configuring-mixed-dpi-monitor...
somat wrote 5 hours 17 min ago:
The irony is that despite the myth to the contrary wayland does
not even try to handle mixed DPI at all and only fakes it via
the fractional scale hack and X11 has supported mixed DPI from
probably day one.
Admittedly X11 mixed DPI was using separate screens which were
awkward to deal with and early versions of the unified screen
tech (xinarama and xrandr) did not support mixed DPI. And even
modern X11 while it provides the needed DPI information
requires the application to care enough to support it. Which
really means unless the toolkit provides it for free most
applications are not going to do anything,
ndiddy wrote 4 hours 18 min ago:
> The irony is that despite the myth to the contrary wayland
does not even try to handle mixed DPI at all and only fakes
it via the fractional scale hack and X11 has supported mixed
DPI from probably day one.
I'm not sure what you're talking about, fractional scaling is
just another way to describe DPI. The scale factor is just
the DPI divided by 96. If you're referring to windows getting
scaled by the compositor for fractional scales, that's only
used for older software. Both Qt 6 and GTK 4 support natively
rendering window contents at fractional scales on Wayland.
somat wrote 3 hours 20 min ago:
In a fractional scaling setup you first create a
homogeneous virtual screen at the dpi wanted then get the
right size by scaling the monitors out to fit. A dpi aware
application will draw itself at the correct size on the
appropriate screen. The main difference is the dpi aware
application still looks good on all monitors. where as the
fractional scaled stuff suffers scaling artifacts.
Wayland only supports fractional scaling. and there is a
good argument that this is a better system, not because it
looks better, it does not. but because applications don't
have to be aware of it where a mixed dpi requires the
application to actively deal with it.
kwhat4 wrote 9 hours 2 min ago:
Probably because Xinerama[1] and then later RandR[2] were an
afterthought. [1]
HTML [1]: https://en.wikipedia.org/wiki/Xinerama
HTML [2]: https://xorg.freedesktop.org/archive/X11R7.5/doc/man/man1/xr...
chadgpt3 wrote 9 hours 3 min ago:
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.
simmonmt wrote 8 hours 56 min ago:
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)
rwmj wrote 6 hours 41 min ago:
$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.
Liskni_si wrote 7 hours 10 min ago:
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.
DIR <- back to front page