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 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.
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.
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.
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.
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.
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.
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.
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.
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
> unless you run multiple X screens which disallows moving Windows between screens which is a pretty big barrier to normal usage.
Is it? Or is it forgotten?
Around 1994 I had a Pentium 133 with 16MB. In it a Diamond Speedstar 24(Pro?) (Tseng ET 4k) Vesa Local Bus, some ISA Trident 8900, and an ISA Hercules, driving one 17", one 15", and the Hercules at something like 12" IIRC. One could choose in the BIOS which "GPU" ...err... frame buffer should have priority at boot, or rather which slot, so when you've chosen VLB it took that, and the others were a matter of the OS to initalize and drive way after boot.
At the time I compared 386BSD, NetBSD, SLS(Softlanding Systems), early Slackware and SuSE, and lo and behold, I could move windows across all of them on all of them!1!!
With proudly created custom modelines for all of them, even the Hercules, with different Hz & DPI for each screen.
Though it didn't really make sense, because X on the Hercules was very laggy and jerky, coz' 8-Bit ISA. Was more useful for syslogs and debugger.
Anyways, it worked, even if only as POC, to show off.
Now that wasn't Xorg, but XFree86, but still?
1994. Worky, worky!
IIRC that also applied to Accelerated-X, at least for the Tseng and Trident.
In 1994 the only way to have multiple monitors was to run X with multiple X screens which did not allow moving windows freely between screens. In 1998 X11R6.4 brought xinerama and proper multi-head with many physical screens but only 1 X screen removing that complication.
May I submit that it is more likely that you are speaking of 1998 instead of 94 rather than this entire technology working differently.
> May I submit(suggest?) that it is more likely that you are speaking of 1998 instead of 94
No. I'm not pulling this out of thin air, or misremembering. It wasn't easy, and it wasn't in the manpages, or only some of it. It was rather involved, and didn't work on first try. Not only that X-thing, but also which TTY/VT was on which head for tailing syslogs, std-error, and whatnot else. But it worked. And with no X on the Hercules, just between the Trident and Tseng, even reasonably fast.
I remember exactly because I moved shortly after that. I also remember which relief Xinerama brought me, when it appeared :-)
Edit: I also remember frying the Hercules and the attached screen with both of them giving me the magic blue smoke, because I've overdriven them a little. But it didn't matter, because that was already abandoned cybertrash at the time, used, and collected just for fun :-)
> With proudly created custom modelines for all of them...
Yep. I remember that pride very clearly. I'm also so glad I never have to do that math ever again.
> SLS(Softlanding Systems)
I'd never heard of this one. If the claim that its slogan was "Gentle Touchdowns for DOS Bailouts" is true, then that's a really great pairing of distro name and slogan.
TBH I've been mostly unimpressed with the early Linuxen. At the time they had almost nothing which NetBSD didn't have, and I knew that really well. Gentoo 'ricing' well.
But it was clear that there was momentum behind the Linux hype. It was on CD-Roms in magazines, in book stores. While *BSD wasn't known generally, just by some guys in Universities, or similar. Bad marketing. FUD because lawsuits, and whatnot else.
> 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
Hmm.
I'm not sure what windowing system you've been using over the past ~thirty years, but you seem to be unaware of both Xinerama (released in the late 1990s) and XRandR (version 1.2 [0] of which was released in like 2006). Maybe you've been using an X11 implementation provided by some proprietary *NIX for all of these years, but whatever you've been using, it has certainly been neither XFree86 or xorg.
> 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.
1) Monitors have been able to support multiple refresh rates for ages. This is a big part of why EDID and friends exists.
2) I note that VESA standardized Adaptive Sync in ~2009, and that VRR-supporting monitors were extremely uncommon in the consumer space until the introduction of GSync and the addition of Adaptive Sync to the DisplayPort standard... which both happened in ~2014. Add to that the fact that my secondary monitor does not support VRR, and it becomes very clear that VRR is not a prereq for driving multiple monitors at different refresh rates.
[0] IIRC, 1.2 is the version that gave it feature parity with Xinerama
$ xrandr | grep -A1 ' connected' | sed 's/^/ /'
eDP connected 1920x1200+0+240 (normal left inverted right x axis y axis) 286mm x 178mm
1920x1200 60.03*+ 40.02
--
DisplayPort-0 connected primary 2560x1440+1920+0 (normal left inverted right x axis y axis) 597mm x 336mm
2560x1440 59.95 + 200.00* 179.96 144.01 120.00
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...
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,
> 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.
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.
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.
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.
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. ;)
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.
Please do not see any malice in this naive question, but why is that an obsolete model?
Back in the days I had very different displays that I could use to display various windows of a flight simulator (some dedicated to some instruments, the big one for the front view, for instance) and it was quite nice. It sounds like that would not be easy to replicate with a single shared frame buffer, but maybe I'm wrong (I've been using nothing but a small laptop screen for decades)
It's much easier to place a window at a specific position on a large frame buffer than to drag a window between screens when they are separate display servers.
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.
$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.
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.