scale_factor should not make assumptions on X11

[jmaargh]

My understanding from these docs is that scale_factor should be either defined by a system-level (i.e., not per-app) user preference (like on Windows and Wayland) or by a manufacturer-provided setting (like on most mobile devices). I don't use macOS, but I think it also fits into one of these categories.

The docs indicate that getting scale factor on X11 systems is just irreducibly complex (though I'm curious why winit can't just copy the approach of, for example, gtk). This leads to a multi-stage approach to getting the scale_factor, the last resort of which is the calc_dpi_factor function. This issue is specifically with that function.

As far as I understand, that function assumes that 96 dpi is the blessed "standard" which is scale_factor = 1.0, and any deviation from that results in an equivalently scaled scale_factor. I think this behaviour is unexpected and unwelcome.

As a user, I want applications to respect my scale_factor preference I set at a system level, exactly as it does on Windows for example. If the application cannot find that value for whatever reason, I don't want it just picking its own. As a developer, I don't want my application to arbitrarily scale itself in ways that no other application does. The WINIT_X11_SCALE_FACTOR environment variable does not help me as a developer (because if we can get a clear signal of scale factor from X11, I want to respect it) or for most users (who don't want to set environment variables for their apps to render correctly).

If winit cannot find a clear indication of scale_factor from X11, then I strongly think it should just default to 1.0. Any scale factor that isn't either 1.0 or what the user/manufacturer provided is surprising and will almost certainly be inconsistent with everything else. I think any other application/framework/toolkit attempts to blind reverse-engineer an appropriate scale factor. As a side benefit, this would avoid all issues like this -- you don't need to compensate for every broken xrandr configuration if you're not basing your hack on it.

I'm happy to contribute to fixing this.

[kchibisov]

But folks do rely on randr behavior. This auto calculation is used by the end users and removing it is not desired. Qt for example also supports it.

Though, I'd agree that using 1 as default unless env variable is telling to use randr could make sense, but removing isn't an option.

X11 scale and HiDPI is broken by design anyway, and randr is the only way to get some sense of HiDPI.

[jmaargh]

I guess there are two slightly separate issues:

1. I believe the scale_factor on X11 should either reflect what the user has configured in their preferences, or it should be 1.0 by default. Anything else is surprising to the end user and unlikely to be what they want.
2. There doesn't appear to be a simple consistent way to discover that configured scale factor is, the user-facing preference for it typically come from the desktop environment.

As far as I know, the calculation in calc_dpi_factor cannot possibly reflect the user preference, because it depends only on pixel resolution and physical dimensions, the user has no control over it and any physical display that is not 96 dpi will result in a weird scale factor.

I think a better approach would be to check a hierarchy of different ways to check for a configured scale factor, following common frameworks. E.g., check Xresources, then check something that gnome settings would set, then a kde-compatible check, etc., if none of them give a response, then set to 1.0.

If any particular application would like to scale purely based on DPI, it can still do that by doing the calculation itself and setting WINIT_X11_SCALE_FACTOR.

[jmaargh]

But folks do rely on randr behavior. This auto calculation is used by the end users and removing it is not desired. Qt for example also supports it.

Interesting. Who exactly do you mean by "folks" here? Do you mean that you do, or that you've heard from users that do? Also, do you have a reference for Qt support for it, I couldn't find any after a quick search?

[kchibisov]

I know that folks use it, since I heard that it's being desired for certain group on #alacritty irc channel. I know that @chrisduerr is using it for sure.

For Qt the option is QT_AUTO_SCREEN_SCALE_FACTOR=1.

Do you mean that you do

I don't use X11.

[jmaargh]

Oh I see, so you mean there are some end-users of applications who like the behaviour. Then yes, either it can be left in with a way for developers to opt-in at runtime (like you suggested) or simply removed and developers can do the calculation themselves if their users want it.

[chrisduerr]

Yeah I actually prefer this over any other DPI mechanism. Because it's the only one that actually just works with fractional DPI assuming your client can handle it.

[chrisduerr]

As a user, I want applications to respect my scale_factor preference I set at a system level, exactly as it does on Windows for example. If the application cannot find that value for whatever reason, I don't want it just picking its own.

Also fyi, winit does respect the DPI set by X11 if it is present and will just use the xrandr calculation as fallback.

I think a better approach would be to check a hierarchy of different ways to check for a configured scale factor, following common frameworks. E.g., check Xresources, then check something that gnome settings would set, then a kde-compatible check, etc., if none of them give a response, then set to 1.0.

This is pretty much what it does. Only that gnome/kde settings is not really any of Winit's business. If a DE changes the DPI, it should also set it in non-DE specific configuration files.

[jmaargh]

Also fyi, winit does respect the DPI set by X11 if it is present and will just use the xrandr calculation as fallback.

AFAICT, winit uses the key from Xresources if it finds one set. My experience is that in common DE setups, this value is not found set even though the user has set their preferences to 100% scaling.

Moreover, my point was that xrandr-based guess should not be a default fallback, but either not there at all or opt-in. Right now it cannot even be opted out, winit is just forcing this behaviour -- which I find both surprising and unwanted -- onto all users.

This is pretty much what it does. Only that gnome/kde settings is not really any of Winit's business. If a DE changes the DPI, it should also set it in non-DE specific configuration files.

I get the reluctance to put in DE-dependent code in, but the result of DE user preferences are winits business, exactly as they are on Windows or macOS. As a user, I expect every application on my system to be affected by that setting and as a developer I would like my scale-factor-aware window management library to be aware of the users scale factor preferences.

[chrisduerr]

My experience is that in common DE setups, this value is not found set even though the user has set their preferences to 100% scaling.

But that's the default? That's literally not having anything set, so why would you be surprised about not having it set?

Right now it cannot even be opted out

I mean that's not correct? You can set the environment variable?

I get the reluctance to put in DE-dependent code in, but the result of DE user preferences are winits business, exactly as they are on Windows or macOS.

No they're not. DEs configurations are not the same as global configurations. If I make a change to my GTK settings I do not want my KDE applications to be affected. Same goes for winit too.

[jmaargh]

But that's the default? That's literally not having anything set, so why would you be surprised about not having it set?

Perhaps, as an engineer that sounds plausible as a cause. As a user though, it's complete nonsense. Just because my preference happens to be what is the default means that apps should ignore it? Of course users are going to be surprised if their apps behave differently from what appears in their settings, if you're not surprised by this it's because you have an abnormally deep understanding of how these settings work behind the scenes and have internalised that the behaviour is ok because there's an explanation. No normal user would be ok with this.

Right now it cannot even be opted out

I mean that's not correct? You can set the environment variable?

You can opt out of scaling altogether, you can't opt-out of the weird randr-based scaling which I'm suggesting shouldn't be happening (at least not by default) while leaving in the ability to respond to actual scaling settings.

No they're not. DEs configurations are not the same as global configurations. If I make a change to my GTK settings I do not want my KDE applications to be affected. Same goes for winit too.

Your opinions are yours, I think this one is far from universally shared. I think the vast majority of people who see their OS has a scaling option in its settings expect that to apply to all well-behaved applications. Just like on any other platform. Why do normal users care what toolkits and libraries were used to build them? As an application developer I want my application to respect what the end user has set in their DE preferences too (anything else seems user-unfriendly). Moreover, my strong suspicion is that most OS maintainers and DE developers also want the system settings app to act as global settings for all well-behaved applications.

---

That discussion got in the weeds a bit, but the main point remains that winit doing this weird randr-based scaling is not consistent with my experience with other libraries and I suspect is not wanted by the vast majority of end users (both because of the lack of consistency and the lack of control they have over it).

[chrisduerr]

Perhaps, as an engineer that sounds plausible as a cause. As a user though, it's complete nonsense. Just because my preference happens to be what is the default means that apps should ignore it?

No, that is my opinion as a user. I don't want bullshit GTK settings to mess with the proper default locations. That is a fucking nightmare to troubleshoot and not something I'd ever want to get involved with. What's next, someone writes a new toolkit I've never heard of, that is the only thing exporting DPI and I'm unable to find where it's set because I've never heard of it before? That's an absolutely ridiculous approach to take to system configuration.

No normal user would be ok with this.

How many "normal" Linux users are there exactly? 3? Maybe 4? At most.

Your opinions are yours, I think this one is far from universally shared. I think the vast majority of people who see their OS has a scaling option in its settings expect that to apply to all well-behaved applications.

That's why DEs should set the global Xorg option. It's up to the DE to make sure its settings are applied properly. That also usually is the case for most settings, I'm not sure about GNOME and DPI scaling. So if a DE developer wants things to apply everywhere, all they have to do is set it globally instead of for their specific toolkit. It's literally that easy. So someone setting it just for their toolkit clearly doesn't want it to apply globally.

[jmaargh]

@chrisduerr Your responses are getting more heated. I could continue to respond point-by-point, but I'm not going to any more unless I feel it's contributing to a productive discussion on the point at hand. Please keep responses cool-headed and focussed on the my main suggestion: to change how winit behaves by default and possibly also some changes to how it can be configured to behave for the sake of better consistency and (in my opinion) less surprising behaviour for both end-users and application developers.

[zkldi]

Just to add to the pile here, this is currently causing bizarre issues on my laptop and even other screens I have plugged in. I have things set to 100% scale and it still infers (guesses?) incorrect values like 1.08 or 1.667. Is there a way to forcibly disable this behaviour?

[kchibisov]

Xft.dpi: 96 or WINIT_X11_SCALE_FACTOR=1

[ArturKovacs]

I also came across this using winit 0.29.2.

Digging into the source I found this:

winit/src/platform_impl/linux/x11/util/randr.rs

Line 41 in d82886b

.get_string("Xfi.dpi", "")

Which seems to be incorrect. It should be Xft instead of Xfi. This has been fixed at some point and is correct in 0.29.15

winit/src/platform_impl/linux/x11/util/randr.rs

Line 52 in 8f08fba

.get_string("Xft.dpi", "")

So the application shows up as requested in the system settings with GNOME 42.9 and winit 0.29.15, so I believe this issue can be closed.

[kchibisov]

The issue is about us using the randr based calculations when anything else is absent, so to resolve this issue we have to use scale 1 on X11 by default, which I'm personally in favor.

We do have the env, xft, xsettings, randr, on X11 which pretty much matches what Qt does, iirc. It's just default Qt behavior is scale 1, but we use randr.

The bug you've mentioned was present only for 0.29, and was fixed right away, which is not applied for the original report.