> automatic HiDPI scaling that a shockingly large number of Wayland proponents insist Xorg doesn't support.
Assuming they know what they're talking about and not just parroting whatever they read others mention, usually when someone says that "Wayland does $THING that X11/Xorg doesn't do", this is really a shortcut for "X11/Xorg could technically do $THING, if enough developers and projects cared about it, but that would be a massive undertaking and it is easier to convince developers do $THING if we can control most of the stack to only do $THING in one particular way we want by working from a clean slate".
Since you mentioned environment variables, not sure what SDDM exactly is doing, but in the case of HiDPI scaling under Xorg the only method for HiDPI i'm aware of that uses environment variables is Qt's `QT_SCREEN_SCALE_FACTORS` which is a semicolon-separated list of per-screen scaling factors that Qt applications can use to automatically scale themselves depending on the screen the window/application is in. Considering SDDM is written in Qt, i'll guess that this is what it set.
But the thing is, this is far from enough if you want "robust" support under X11/Xorg. The reason is that a typical X application under a typical X desktop has multiple components: an X server (which i'm going to assume it is Xorg for now - other X servers are basically Xorg forks and sync with its features), a window manager, an optional desktop compositor and a widget toolkit on the application's side (not strictly needed as an app can use its own adhoc code for that but let's assume it uses one since this doesn't really matter in this case).
The behavior you need for robust HiDPI support is for the application to use the proper scaling for each of its toplevel windows depending on the connected output the window is in (note: this may or may not actually be relevant to DPI - someone may have bad eyesight and want their 27" 1440p monitor to be 150% scaled) and have that be done automatically - ideally, transparently from the user's perspective - as they move windows between outputs and/or add/remove outputs (e.g. connecting/disconnecting or turning on/off a graphics tablet with an embedded monitor would add/remove an output).
Now, technically, Xorg does provide the necessary core functionality to implement the above, however the issues begin when you start considering who is going to implement it and what part of the stack is responsible for which aspect of supporting window scaling.
Ideally, what you'd want is for applications should be able to scale each of their toplevel windows arbitrarily based on notifications from the underlying system as the user interacts with the application windows (note: this is not necessarily limited to just the user moving windows between outputs - a user could, for example, select an option from their window manager to scale a window at 200% or 300% - this could be useful when doing video streaming or recording videos for example).
So, in an ideal world, the following should happen under X11/Xorg:
1. Widget toolkits can scale their widgets arbitrarily (ideally not just at fractional level but also sub-100% level too - useful when using secondary screens with a low resolution).
2. Window managers can receive RandR events for output DPI changes and use that information to maintain a scaling factor for each output (the user could also specify custom per-output scaling too).
3. As the user interacts with the windows, the window manager sends notifications to the windows/applications whenever a window needs its scale changed. The widget toolkits use these notifications to scale their windows' contents.
Ignoring a few details, the above is basically what Wayland does since it started from a clean slate where they could dictate everything from scratch.
However X11/Xorg already has a lot of software already written for it and there are a few snags in the way:
1. Pretty much no toolkit supported arbitrary scaling, so they had to be extended for it. Since Wayland needed that, toolkits that need to support it added the functionality anyway (e.g. Qt and Gtk) though not without issues along the way (AFAIK Gtk didn't support fractional scaling for a long time). Though not all toolkits have support for this.
2. Window managers must be extended to monitor outputs via RandR and send appropriate notifications whenever windows move across outputs to those windows. This would also need some new notification protocol (most likely a new version of EWMH). However...
3. ...toolkits must also be extended to support these notifications - supporting scaling isn't enough if they do not know when to scale. This introduces a problem because...
4. ...window managers will have to deal with toolkits not supporting the notifications. One way would be to just ignore them, but another way is to do the scaling themselves. However, there is another issue here.
5. When using (and having enabled) a desktop compositor scaling can be easy (especially when dealing with edge cases like a window lying across the edge between two monitors :-P), but without one, the window manager needs to scale the window itself (there was a Xorg branch by Keith Packard that introduced server-side window scaling but AFAIK it was never merged) without affecting the rest of the desktop - and of course do the appropriate coordinate transformations for various events (e.g. mouse motion). Moreover since a desktop compositor can be a separate program than a window manager (many -if not most- X11 window managers are not desktop compositors), they both need to somehow coordinate with each other.
6. Since this requires all window managers (and desktop compositors) to be updated, the inevitable result is that there will be a lot of them that will not be updated for quite some time, so applications (or realistically, widget toolkits) will need to also handle HiDPI scaling themselves by doing the RandR queries and automatically sizing their own windows based on output. This is a subpar option because the application does not know the window manager's own state and you can end up with the two "fighting" with each other. Also the window manager cannot do desktop-wide configurations (it is actually blind to them).
7. Obviously whatever protocols in place (as i wrote above, probably a new EWMH version) are used, they'll also need to let the components (window manager, widget toolkit) provide information for when any of the above are in place so the proper action is taken (e.g. a toolkit should not try to do the output tracking itself if the window manager supports it and a window manager should not try to do scaling itself if the widget toolkit supports it - but both need to inform the other about this).
As you can hopefully imagine, the above require the developers of all window managers, all desktop compositors, all widget toolkits and applications not only to coordinate with each other but also handle various cases in case the user used something in the stack that did not support things.
With Wayland since everything was done from scratch, there were less people that needed to be convinced to cooperate - and in practice since Wayland originated from RedHat and the GNOME ecosystem, convincing the appropriate GNOME and Gtk developers to cooperate was probably a coffee break away :-P. Meanwhile Qt would already need to add (or already had, not sure when it was added) support for scaling/HiDPI anyway for Windows and macOS, so the infrastructure was there.
The current situation is that Qt, currently, supports the #6 i mentioned above since it can be implemented without needing support from window managers, desktop compositors or specifying new protocols (something that seems to be much harder than it should be - e.g. AFAIK Cinnamon implemented a very trivial X attribute for displaying a percentage for windows in a taskbar/icon overlay -think of download percentage- but despite the developers' attempt to have others adopt it, i do not think it saw much adoption). But this is really the "fallback solution" when everything else is just not there, it is not the ideal one.
That said, from a technical perspective there is nothing theoretically stopping Xorg desktop environments having top-notch robust HiDPI support. What blocks everything is convincing the developers of the various components of the desktop stack to cooperate, implement and support it.
> ...the above require the developers of all window managers, all desktop compositors, all widget toolkits and applications not only to coordinate with each other but also handle various cases...
/me wonders if OP has been paying attention to how "consensus building" actually ends up working in the Wayland world
> With Wayland since everything was done from scratch, there were less people that needed to be convinced to cooperate - and in practice since Wayland originated from RedHat and the GNOME ecosystem, convincing the appropriate GNOME and Gtk developers to cooperate was probably a coffee break away...
/me realizes that the answer is "No. Not really."
To be less droll:
1) Through xrandr, even windowmaker provides the data required for an application to know the properties of the monitor that > 50% of each of its windows are on. Given how much nicer xrandr was than xinerama, WMs that cared about multihead moved over to it fairly quickly.
2) I'm certain that not every WM provides the information required for screen-DPI- and screen-scaling-aware programs to scale as desired. But, the "Wayland is a lightweight protocol that makes few policy decisions" motto turns out to mean that for most decisions that users care about, each Wayland WM (or whatever the Wayland terminology for the Wayland equivalent is) needs to re-make and reimplement those decisions. Feature fragmentation has been bad. So, no, if you're not going to hold Wayland to the "Every WM must implement all the features" standard, then you're not going to demand that of Xorg WMs.
3) You happened to mention the two things that's needed for Xorg to support both HiDPI and non-integer scaling... GUI drawing library support and a common protocol for setting and retrieving user-driven adjustments to the "natural" rendering scale given the display DPI. XRandR [0] has either always, or has effectively always provided the information required for GUI toolkits to scale their widgets according to a screen's DPI. And the XSETTINGS protocol [1] is used to store the user-commanded scaling adjustment. Glancing at the release date for those two things, they either substantially predate or came out very, very shortly after Wayland's initial release.
Weird. It's almost as if we were waiting on the GUI toolkits to use what Xorg had been providing them for ages.
Anyway. Check footnote 1 in the comment you replied to for the on-the-ground details on GUI toolkit render scaling on Xorg from an end-user's perspective.
[0] adopted no later than 2007
[1] first proposed in 2001 and adopted no later than 2009 (though, if I cared to spend more than a few minutes on the search, I expect I'd find that it was adopted much earlier)
What i described was about Wayland, GNOME and Gtk specifically, not the entire "Wayland world". Wayland has been a mess that could have been completely avoided if people just tried to fix any issues with Xorg instead of falsely claiming that Xorg cannot be fixed and we'd had proper support for HiDPI, HDR, mixed refresh rate configurations with compositing and all sorts of other nice things at least a decade ago instead of creating a pointless schism in the already tiny Linux desktop ecosystem but ultimately you cannot control what other people spend their time on.
1) Window Maker does not provide anything to any application, if applications need such information they have to use the extension APIs themselves. IF there was an agreed upon protocol for window managers notifying applications to scale themselves, then Window Maker could implement it. But such a protocol does not exist.
2) Window managers do not provide any information there at all since there is no such support. And yes, all Wayland compositors do need to implement that stuff, but because it started from a clean slate and Wayland compositors had to be written from scratch anyway, it was easier to convince developers to do that because they self-selected to go through the effort of making a Wayland compositor in the first place. As i wrote in my original post, the issue here isn't if something would be written or not, but convincing the people who work on the projects. It is mainly a social issue, not a technical one.
3) Yes, without any other support in place, GUI toolkits and other applications can use the information exposed RandR to implement scaling themselves but, as i already wrote, this is a fallback solution because the rest of what i describe is not there. This is far from having robust support, ignores things like custom scaling options, handling moving windows between desktops and support for applications that do not do scaling themselves (which is many of them), among other things.
All of the above are things i already addressed in my original message BTW and again, the issue is not technical but social/political. It is about convincing people to cooperate, not if something is technically possible (and let's be honest, it isn't like Xorg's code is written in stone, if something is currently impossible, the code could be extended to make it possible).
Assuming they know what they're talking about and not just parroting whatever they read others mention, usually when someone says that "Wayland does $THING that X11/Xorg doesn't do", this is really a shortcut for "X11/Xorg could technically do $THING, if enough developers and projects cared about it, but that would be a massive undertaking and it is easier to convince developers do $THING if we can control most of the stack to only do $THING in one particular way we want by working from a clean slate".
Since you mentioned environment variables, not sure what SDDM exactly is doing, but in the case of HiDPI scaling under Xorg the only method for HiDPI i'm aware of that uses environment variables is Qt's `QT_SCREEN_SCALE_FACTORS` which is a semicolon-separated list of per-screen scaling factors that Qt applications can use to automatically scale themselves depending on the screen the window/application is in. Considering SDDM is written in Qt, i'll guess that this is what it set.
But the thing is, this is far from enough if you want "robust" support under X11/Xorg. The reason is that a typical X application under a typical X desktop has multiple components: an X server (which i'm going to assume it is Xorg for now - other X servers are basically Xorg forks and sync with its features), a window manager, an optional desktop compositor and a widget toolkit on the application's side (not strictly needed as an app can use its own adhoc code for that but let's assume it uses one since this doesn't really matter in this case).
The behavior you need for robust HiDPI support is for the application to use the proper scaling for each of its toplevel windows depending on the connected output the window is in (note: this may or may not actually be relevant to DPI - someone may have bad eyesight and want their 27" 1440p monitor to be 150% scaled) and have that be done automatically - ideally, transparently from the user's perspective - as they move windows between outputs and/or add/remove outputs (e.g. connecting/disconnecting or turning on/off a graphics tablet with an embedded monitor would add/remove an output).
Now, technically, Xorg does provide the necessary core functionality to implement the above, however the issues begin when you start considering who is going to implement it and what part of the stack is responsible for which aspect of supporting window scaling.
Ideally, what you'd want is for applications should be able to scale each of their toplevel windows arbitrarily based on notifications from the underlying system as the user interacts with the application windows (note: this is not necessarily limited to just the user moving windows between outputs - a user could, for example, select an option from their window manager to scale a window at 200% or 300% - this could be useful when doing video streaming or recording videos for example).
So, in an ideal world, the following should happen under X11/Xorg:
1. Widget toolkits can scale their widgets arbitrarily (ideally not just at fractional level but also sub-100% level too - useful when using secondary screens with a low resolution).
2. Window managers can receive RandR events for output DPI changes and use that information to maintain a scaling factor for each output (the user could also specify custom per-output scaling too).
3. As the user interacts with the windows, the window manager sends notifications to the windows/applications whenever a window needs its scale changed. The widget toolkits use these notifications to scale their windows' contents.
Ignoring a few details, the above is basically what Wayland does since it started from a clean slate where they could dictate everything from scratch.
However X11/Xorg already has a lot of software already written for it and there are a few snags in the way:
1. Pretty much no toolkit supported arbitrary scaling, so they had to be extended for it. Since Wayland needed that, toolkits that need to support it added the functionality anyway (e.g. Qt and Gtk) though not without issues along the way (AFAIK Gtk didn't support fractional scaling for a long time). Though not all toolkits have support for this.
2. Window managers must be extended to monitor outputs via RandR and send appropriate notifications whenever windows move across outputs to those windows. This would also need some new notification protocol (most likely a new version of EWMH). However...
3. ...toolkits must also be extended to support these notifications - supporting scaling isn't enough if they do not know when to scale. This introduces a problem because...
4. ...window managers will have to deal with toolkits not supporting the notifications. One way would be to just ignore them, but another way is to do the scaling themselves. However, there is another issue here.
5. When using (and having enabled) a desktop compositor scaling can be easy (especially when dealing with edge cases like a window lying across the edge between two monitors :-P), but without one, the window manager needs to scale the window itself (there was a Xorg branch by Keith Packard that introduced server-side window scaling but AFAIK it was never merged) without affecting the rest of the desktop - and of course do the appropriate coordinate transformations for various events (e.g. mouse motion). Moreover since a desktop compositor can be a separate program than a window manager (many -if not most- X11 window managers are not desktop compositors), they both need to somehow coordinate with each other.
6. Since this requires all window managers (and desktop compositors) to be updated, the inevitable result is that there will be a lot of them that will not be updated for quite some time, so applications (or realistically, widget toolkits) will need to also handle HiDPI scaling themselves by doing the RandR queries and automatically sizing their own windows based on output. This is a subpar option because the application does not know the window manager's own state and you can end up with the two "fighting" with each other. Also the window manager cannot do desktop-wide configurations (it is actually blind to them).
7. Obviously whatever protocols in place (as i wrote above, probably a new EWMH version) are used, they'll also need to let the components (window manager, widget toolkit) provide information for when any of the above are in place so the proper action is taken (e.g. a toolkit should not try to do the output tracking itself if the window manager supports it and a window manager should not try to do scaling itself if the widget toolkit supports it - but both need to inform the other about this).
As you can hopefully imagine, the above require the developers of all window managers, all desktop compositors, all widget toolkits and applications not only to coordinate with each other but also handle various cases in case the user used something in the stack that did not support things.
With Wayland since everything was done from scratch, there were less people that needed to be convinced to cooperate - and in practice since Wayland originated from RedHat and the GNOME ecosystem, convincing the appropriate GNOME and Gtk developers to cooperate was probably a coffee break away :-P. Meanwhile Qt would already need to add (or already had, not sure when it was added) support for scaling/HiDPI anyway for Windows and macOS, so the infrastructure was there.
The current situation is that Qt, currently, supports the #6 i mentioned above since it can be implemented without needing support from window managers, desktop compositors or specifying new protocols (something that seems to be much harder than it should be - e.g. AFAIK Cinnamon implemented a very trivial X attribute for displaying a percentage for windows in a taskbar/icon overlay -think of download percentage- but despite the developers' attempt to have others adopt it, i do not think it saw much adoption). But this is really the "fallback solution" when everything else is just not there, it is not the ideal one.
That said, from a technical perspective there is nothing theoretically stopping Xorg desktop environments having top-notch robust HiDPI support. What blocks everything is convincing the developers of the various components of the desktop stack to cooperate, implement and support it.