> Those patches were never merged, and I doubt they will be, because there seems to be almost no interest in supporting high DPI displays on X without a compositor.
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.