It is exposed reliably already, it is just that to get workable mixed mode HiDPI support (i.e. multiple monitors of different DPIs) you need the window manager and toolkits/applications to cooperate:
1. The toolkit/applications needs to support scaling, preferably using arbitrary (aka fractional) scaling.
2. The window manager needs to obtain per-output (output=monitor) DPI and associate a scaling value for each output (note that scaling and DPI are not necessarily tied - someone might e.g. want a high scaling factor for a secondary 1440p monitor because they have it farther away than their primary monitor).
3. The application/toolkit needs to tell to the window manager that it supports scaling as well as know that the window manager supports scaling. Window properties can be used to do that.
4. The window manager needs somehow to communicate to the toolkit/application to scale a window. This can happen either because the window was dragged to a monitor (output) with different output but it could also be because, e.g. the user explicitly requested to scale a window from the window menu (e.g. for making a screencast for youtube). This "somehow" is basically a set of messages since the mechanism is already used for other things already.
5. If a toolkit/application does not support scaling (i.e. it does not have the appropriate properties) the window manager may decide to fake it itself (e.g. by redirecting the window output to a pixmap and then drawing that pixmap scaled). If a toolkit/application does support scaling but the window manager doesn't then it is up to the toolkit/application to decide, e.g. it may do its own scaling by tracking the output the window is and scaling itself appropriately (this will need some heuristics to avoid being too janky as the toolkit/application is essentially taking over part of what the window manager's job and toolkits/applications may just not want to do that).
If it isn't already obvious, the issue here is that this concerns multiple entities:
1. There needs to be some sort of commonly accepted messages and properties for the window managers and applications to communicate scaling.
2. Toolkits (and applications that use custom toolkits) need to implement support for scaling and handling the above messages and properties.
3. Window managers also need to implement the above messages and properties, implement some sort of scaling configuration and use the appropriate RandR functionality to setup initial per-output scale configuration.
AFAIK of all the above the only thing that exists is that the X server can provide the necessary information and Qt supports fractional scaling. AFAIK it also can use its own root property to set per-output scaling but it does the scaling itself independent from the window manager so it is far from ideal.
For the rest basically the toolkit and window manager developers need to be convinced to work on it and also come up with a common message/property protocol, both of which IMO are the hard parts - compared to that, the technical side is easy :-P.
You lay this out as a list of numbered bullet points, and it is great to see it enumerated like this, but I can only tell you that, as a non-programmer myself, I can barely follow a word of that, and have absolutely no idea what is needed from who and where in there.
You say:
> If it isn't already obvious,
None of this is obvious. I think to most Linux users, that is impenetrable. It is to me, I'm afraid.
But you could potentially do the X.org world a big favour by developing that comment into a detailed blog post, with examples and hypothetical proposals of how to do it.
Given (a lot) more info, I would like to write about this.
ISTM that X.org and X11 in general is on the threshold of dying from neglect in the next year or two, and unless the people who understand the issues step up and explain them to the general FOSS world, so that someone can see if maybe they could start to work on them, it will die... just because nobody could be bothered to keep it alive.
And since there isn't a single Wayland environment I personally can stomach using, that would be a very bad thing IMHO.
Currently the choices are two raging trash fires of CADT development and vanity, and a handful of weird tiling window manager things.
> and have absolutely no idea what is needed from who and where in there.
FWIW i don't exactly know "who" needs to do what either - that is the issue really, in order to get that in the X11 world you need several different people and projects to care to work together. AFAICT most don't really seem to care to make an organized thing.
The main reason Wayland sidesteps some of that is that a Wayland compositor combines the graphics system, the window system and the window manager in one program, meaning that one project can solve everything itself (even if all compositors need to solve it separately), however with X11 you need all window managers and all toolkits to coordinate with each other.
The other reason is that Wayland has buy-in from the two major toolkits, Gtk and Qt. I have a feeling that even if there was an X11 coordination to implement mixed DPI functionality at least Gtk wouldn't bother with it as they want to remove X11 support in Gtk5.
> None of this is obvious.
Well, that was tongue in cheek, i meant that the obvious thing was that it is a mess :-P.
> ISTM that X.org and X11 in general is on the threshold of dying from neglect in the next year or two [...] And since there isn't a single Wayland environment I personally can stomach using, that would be a very bad thing IMHO.
IMO any news of Xorg death are somewhat exaggerated, as i wrote in another reply a couple of days ago, both Xorg and Wayland compositors use the same underlying kernel APIs to access the hardware so if nothing else your current environment will keep working for the foreseeable future. Also i've dabbled a bit in the Xorg code myself and i'm certain it isn't that hard to keep it in working condition - the biggest issue might be people interested in merging patches and making releases but so far it seems to be people who are interested in that.
> in order to get that in the X11 world you need several different people and projects to care to work together
100% believe that and that it's a big problem.
I've seen some say that Xenocara in OpenBSD is the only project with some active R&D going into this today. Any comments on that?
> AFAICT most don't really seem to care to make an organized thing.
Definitely. Of course, if someone somewhere were paying it might be different...
> The main reason Wayland sidesteps some of that is that a Wayland compositor combines [...]
If I may attempt, and this is not meant to be rude, to say what I think that would come across to most even quite nerdy folk as:
Wayland combines tech, tech and tech, but tech still has to tech, whereas with X11, you have to tech, tech and tech separately, and then tech some tech alongside a tech.
> The other reason is that Wayland has buy-in from the two major toolkits, Gtk and Qt.
That's a much bigger issue.
I suspect GNOME 4, aka 3.40, aka 40, is revealing a bigger problem. Just as all the other desktops got up to speed with Gtk 3, GNOME yanked the rug out from under them with Gtk 4.
The GNOME team don't seem to me to care at all about other desktops, and they don't care much about their users' preferences either.
The attitude seems to me to be:
"Hey, Steve Jobs just gave them what he thought they needed, and they loved it, so we can do the same! He took away all their buttons and ports and slots and so on, and made it super simple, and the company is worth trillions! So we can just take away all those options and buttons and functions, all the junk we don't use, like themes and stuff, and they will love it!"
Any project that isn't directly affiliated with GNOME will come to regret using Gtk in time, I suspect.
Qt sounds better, from my uninformed outsider perspective, but I don't know much at all. AIUI the price of entrance is you must use C++ or have a 2nd class experience, and a lot of people don't like C++.
Maybe this is the big chance for the GoLang or DLang folk to prove themselves: do some better, modernised version of one of the other toolkits, say one from olden times like XForms or something, and offer a compelling alternative that's 100% FOSS, and accessible from other languages, not just their pet one.
1. The toolkit/applications needs to support scaling, preferably using arbitrary (aka fractional) scaling.
2. The window manager needs to obtain per-output (output=monitor) DPI and associate a scaling value for each output (note that scaling and DPI are not necessarily tied - someone might e.g. want a high scaling factor for a secondary 1440p monitor because they have it farther away than their primary monitor).
3. The application/toolkit needs to tell to the window manager that it supports scaling as well as know that the window manager supports scaling. Window properties can be used to do that.
4. The window manager needs somehow to communicate to the toolkit/application to scale a window. This can happen either because the window was dragged to a monitor (output) with different output but it could also be because, e.g. the user explicitly requested to scale a window from the window menu (e.g. for making a screencast for youtube). This "somehow" is basically a set of messages since the mechanism is already used for other things already.
5. If a toolkit/application does not support scaling (i.e. it does not have the appropriate properties) the window manager may decide to fake it itself (e.g. by redirecting the window output to a pixmap and then drawing that pixmap scaled). If a toolkit/application does support scaling but the window manager doesn't then it is up to the toolkit/application to decide, e.g. it may do its own scaling by tracking the output the window is and scaling itself appropriately (this will need some heuristics to avoid being too janky as the toolkit/application is essentially taking over part of what the window manager's job and toolkits/applications may just not want to do that).
If it isn't already obvious, the issue here is that this concerns multiple entities:
1. There needs to be some sort of commonly accepted messages and properties for the window managers and applications to communicate scaling.
2. Toolkits (and applications that use custom toolkits) need to implement support for scaling and handling the above messages and properties.
3. Window managers also need to implement the above messages and properties, implement some sort of scaling configuration and use the appropriate RandR functionality to setup initial per-output scale configuration.
AFAIK of all the above the only thing that exists is that the X server can provide the necessary information and Qt supports fractional scaling. AFAIK it also can use its own root property to set per-output scaling but it does the scaling itself independent from the window manager so it is far from ideal.
For the rest basically the toolkit and window manager developers need to be convinced to work on it and also come up with a common message/property protocol, both of which IMO are the hard parts - compared to that, the technical side is easy :-P.