> 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.
It's FOSS NewsSourav Rudra
It's FOSS NewsSourav Rudra
