-
Notifications
You must be signed in to change notification settings - Fork 879
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
scale_factor
should not make assumptions on X11
#2231
Comments
But folks do rely on Though, I'd agree that using 1 as default unless env variable is telling to use X11 scale and HiDPI is broken by design anyway, and randr is the only way to get some sense of HiDPI. |
scale_factor
should make assumptions on X11scale_factor
should not make assumptions on X11
I guess there are two slightly separate issues:
As far as I know, the calculation in 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 |
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? |
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
I don't use X11. |
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. |
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. |
Also fyi, winit does respect the DPI set by X11 if it is present and will just use the
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. |
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.
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. |
But that's the default? That's literally not having anything set, so why would you be surprised about not having it set?
I mean that's not correct? You can set the environment variable?
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. |
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.
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.
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). |
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.
How many "normal" Linux users are there exactly? 3? Maybe 4? At most.
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. |
@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. |
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? |
|
I also came across this using winit 0.29.2. Digging into the source I found this:
Which seems to be incorrect. It should be
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. |
The issue is about us using the 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. |
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.
The text was updated successfully, but these errors were encountered: