What exactly is wrong with "scaling" on Linux? I use Qt apps on Plasma and everything just works. Nearly all my displays are HiDPI now.
Well, that's the whole thing. HiDPI in and of itself works well. I use it with a 24" UHD monitor and I absolutely love the setup.
But the main issue with Linux, at least with X11, is that it doesn't handle multiple displays with different DPI settings.
As you noted, QT seems to work fine, as do some other toolkits that have dynamic scaling according to the monitor size. Alacritty does this too, for example (don't know what toolkit they use, though).
But GTK in particular is terrible. Yes, you can configure it to use scaling, in which case it works well, IF you don't need fractional scaling (though recent versions of Gnome seem to support it somehow).
But now, if you're going to use, say, a HiDPI laptop with a "regular", larger external monitor, you're gonna have a bad time. If you enable scaling, the widgets will be huge on the LoDPI display. If you disable it, widgets will be teeny tiny on the HiDPI one.
The issue is really with window managers and toolkits. What needs to happen is that window managers ask the applications (the top level windows really) to scale themselves -this can be done not just for DPI purposes- and then the applications should apply that scaling.
(applications should expose that they can support this - like they expose that they support handling a 'close window' event - so that compositing window managers can do it themselves for applications that do not support it, which is also why this needs to go through the window manager)
Qt can do this but AFAIK window managers do not do this because there isn't any standard events for that - i remember an email about this exact topic when i took a look at the Xorg mailing list for WMs some time ago, but it didn't seem to be going anywhere (in that it barely had any replies).
So it really is about standardizing how it is to be done. I think the main reason it isn't done is that such setups are comparably rare (i mean hidpi displays themselves are very rare - if you check any desktop resolution stats they often barely are a blip - and having both a hidpi display and a regular dpi one is even less common than that) so developers aren't that interested in implementing such a thing.
One way it could be done however is also pushing the idea that this isn't just for multimonitor setups: as i wrote above, you can use that for generic scaling, which is useful even for single monitor regular dpi setups (if anything it can be very useful for low resolution setups - like 1366x768 and similar which are way more common than hidpi - when faced with applications with a lot of padding, etc).
And this is really not that dissimilar under Windows: nowadays you have a lot of different GUI toolkits and applications still need to "opt-in" and explicitly support stuff like scaling, so you have a lot of applications that do not do that.
On Windows, Win32 doesn't do that by default because it would break backwards compatibility from those Windows 95 binaries being run on a Windows 10 2021 edition, so it must be a conscious decision to enable it.
UWP and WinUI work just fine.
The issue was elsewhere - it provided standardized wire protocol and you could not break it. It could extend it, but applications not aware of the extension would be not able to benefit. Windows and Mac on the other hand kept the protocol proprietary and you had to use supplied libraries, you could not talk to the display server directly. So Microsoft and Apple could update these libraries; on Linux, there was no such option, all the apps using wire protocol instead of client libraries would be left out in the dark.
It is issue with X11. If you have Wordperfect binary from 1999, it still has to work; it does not matter that RandR provides information, old clients will not ask for it and without it, they will be broken.
That's why Xwayland does upscaling by itself.
> mean hidpi displays themselves are very rare - if you check any desktop resolution stats they often barely are a blip - and having both a hidpi display and a regular dpi one is even less common than that
Cause and effect. They are rare, because using them sucks, making them even rarer. On systems, where they do not suck, they are not that rare. This attitude makes entire platform worse off.
This is why i wrote "so that compositing window managers can do it themselves for applications that do not support it, which is also why this needs to go through the window manager". You do not need X11 support for that, functionality that exist can be used right now to do it - assuming the applications and WMs cooperate to specify the necessary attributes and events, of course.
> That's why Xwayland does upscaling by itself.
You can also do this with a compositor for applications that do not support scaling themselves (which would be the default state - again this isn't any different than the 'supports close event' flag that already exists for decades now). Without a compositor you're out of luck (for the most part)...
...However!
Keith Packard worked on server-side scaling some time ago [0] (not sure if it was merged with mainline) which would allow this to be done even without a compositor (well, kinda, technically the server does the compositing just for the scaled windows). So even without a regular desktop compositor this should still be implementable, assuming that functionality was (or will be) merged in mainline Xorg. But note that this is only for the case where one wants to run applications that do not support scaling and have hidpi scaling and also not using a compositor. The rest can already be implemented with Xorg as-is.
>X11 provides the necessary information via RandR to perform per-monitor scaling
This is not true. If it were true, it would be significantly easier to get DPI scaling to work on X11 and XWayland already. If you're referring to the physical size measurements, there are numerous problems with those, and they should never be used to do DPI scaling. If you're developing for Wayland, you should just ignore those measurements and use the scale provided by the server. If you mean that applications can draw themselves at arbitrary scales, they could always do that, without even bothering with RandR, but that will break down when you try to handle the compositing cases, e.g. stretching a window across monitors and expecting the display/input coordinates to scale correctly. So regardless of what you're trying to get the apps to do, some more work needs to be done there.
Even if those problems were fixed, DPI scaling would still not work without more changes in the server. The major reason why it can't even work is because of input coordinate scaling -- the server needs to be able to scale coordinates based on a factor provided by the client, and RandR does not provide this, and it doesn't make sense to add it to RandR either. If you want to standardize how this is done, the best way would just be to copy the method used by Wayland back into the X server. Part of it might be merging those patches by Keith that you linked, part of it might be somebody finishing this MR: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
I don't know about that, though the only person i personally know with a HiDPI display uses X without a compositor (they just use a theme with everything being big).
> If there was interest in those, at the very least somebody would have to adapt them
These are only part of the puzzle, they are not really that useful by themselves without the rest of what i wrote, which would actually be the more involved problem. Having scaling without a compositor is more of a "cherry on top" than anything else.
> This is not true. If it were true, it would be significantly easier to get DPI scaling to work on X11 and XWayland already.
I think mixing DPI and scaling is the root of the problem here. Scaling is something independent from DPI settings, though DPI settings can be used for setting up the defaults.
However scaling is useful regardless of DPI.
> If you're referring to the physical size measurements, there are numerous problems with those, and they should never be used to do DPI scaling.
Why not? They can be used to calculate defaults. I've heard that by default the official X server misreports DPI, but many distributions apply patches to fix that - not sure why the X server does this but it is something to be fixed. Personally i never had issues with how the X server reported my monitors' DPI and i've used a bunch of different monitors over the decades.
Regardless this is something that can be fixed anyway - after all if Wayland can get the proper information, so can X11.
> If you mean that applications can draw themselves at arbitrary scales, they could always do that, without even bothering with RandR, but that will break down when you try to handle the compositing cases, e.g. stretching a window across monitors and expecting the display/input coordinates to scale correctly. So regardless of what you're trying to get the apps to do, some more work needs to be done there.
The idea is for RandR to be used by the window manager as an initial/default scaling setup for windows per monitor. The users should be able to alter that of course and even alter per-window (i mean toplevel window here) scaling (via their window manager).
> Even if those problems were fixed, DPI scaling would still not work without more changes in the server. The major reason why it can't even work is because of input coordinate scaling -- the server needs to be able to scale coordinates based on a factor provided by the client, and RandR does not provide this, and it doesn't make sense to add it to RandR either.
IIRC this was actually fixed some time ago to allow scaling via compositors. Outside compositors we're back to Keith's patches. But this is also an issue for applications that do not support scaling.
Basically what i mean is this, to summarize it:
* Applications can either support or not scaling. If they do support scaling they set some attribute to their toplevel windows to indicate that.
* The Window Manager sends events to toplevel windows that support scaling to setup their scaling whenever the scaling changes (the window is dragged to another monitor, the user requests a different scale level via an icon menu or shortcut or whatever). If a window doesn't support scaling (note that an application can have windows that both support and not support scaling, not that it matters much but it is a good idea to avoid associating application support with window support) it gets scaled by either the window manager (if it is a compositor), a dedicated compositor (some compositors can work with other window managers) or the server (with Keith's patches).
There could also be support for toolkits to do the scaling themselves if the window manager doesn't support scaling (e.g. window managers that support scaling can use an attribute in the root window to indicate that support), but that is more complex and may not be really necessary.
Note that only the case where an X application doesn't support scaling and a compositor is not running is where the current server functionality isn't adequate. Everything else should already be there, but it needs support from toolkits (to support the relevant events and of course scaling their contents) and window managers (to implement scaling events). Perhaps RandR's DPI info isn't reliable (though that hasn't been my experience) but that can be fixed, the harder bits are getting toolkits and window managers to support that stuff.
The physical measurements could be used to inaccurately guess defaults, some Wayland servers might do that, but it's not preferred. The X server doesn't "misreport" DPI in the sense that it's purposefully sending a wrong value, there's a process that it does (I may not be remembering this exactly) where it tries to read from the EDID, which could be wrong values. If the values are there but wrong those will just get quietly passed through, if those are zero then it then tries to fill in measurements based on a default DPI. Random X clients with access to RandR can also change the measurements stored in the server for whatever reason -- basically there is no possible way for this value to always be correct if you just want a number that tells you what DPI to target.
You're right this could be fixed, just like every bug could technically be fixed if given enough attention, but somebody needs to take the time to backport the Wayland method to X, which I don't have high hopes for it happening any time soon. The main thing you're missing in the server, as I said, is scaling of input coordinates. The compositor or the toolkit can't do this, it has to happen in the server, because those events are sent directly from the server to the client. It's probably a better approach to get that working, and then put a prop on the root window, and then hack kwin/mutter/whatever to use that, but I don't think anyone has tried to implement it that way yet.
Do you have a link/cite for this? I couldn’t find easily somewhere summarizing pixel density stats.
“Desktop resolution stats” is not the same thing. All the retina displays have at least a 2x pixel ratio so these tables on a cursory Google search are clearly lumping 13 inch MacBook pros into the 1280x800 bucket for instance.
You got a reference to something that clearly is accounting for pixel ratio?
https://data.firefox.com/dashboard/hardware
> these tables on a cursory Google search are clearly lumping 13 inch MacBook pros into the 1280x800 bucket for instance.
How can you tell that? Even JS-only trackers can use Window.devicePixelRatio to get the real resolution, if needed.
If you use 2x scaling (or other integer scaling), everything is fine. If you need fractional scaling, things break down pretty quickly, at least on GNOME.
Once you use fractional scaling (e.g. 1.5), GTK applications will scale correctly, but are slightly slower and consume more mattery. However, all XWayland applications are unusably blurry.
Unfortunately, fractional scaling is really needed on 14" 1080p laptops or 4k e.g. 27" screens. With 1x scaling everything is tiny and with 2x scaling gigantic.
The only workaround that worked ok for me was using 1x scaling and using font scaling in GNOME. Many controls and icons are tiny that way, but at least text is readable and not blurry. Of course, this only works up to some extend and when both screens need the same amount of scaling (since font scaling cannot be configured per screen).
But your comment makes me hesitate to buy a HiDPI monitor!