kms: Try to automatically calculate dpi and scale factor #662
Conversation
|
What's the reasoning behind scaling like this? In the past I would choose a simple scaling ppi solution where steps in 96 are expected. This seems to work fairly well for me personally. it's not 100% of the way there, but across my TVs, tablets, and desktop displays I use it has served me well EDIT: this gives me roughly 169% scale for my 27% 4k monitor, and a 110% scale for my 1280 x 960 15" display, I changed my 4k scale to 165, but it's otherwise quite accurate. |
That is basically what this code is doing. It also calculate dpi or ppi though it arrives at the diagonal slightly different. It also doesn't use 96 as a step size, so the size will end up being 100. That is easily fixed. The only thing that differs then afterwards is limiting the minimum and maximum scaling factor (so we don't go below 100% by default and also not above 200%, which is probably not what you want in desktop use-cases) and go to 25% steps, because that is what It also tries to avoid high scaling factors for very low resolutions, inspiration for this was taken from microsoft's approach in windows (which is probably what most people expect): https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/dpi-related-apis-and-registry-settings?view=windows-11#table-5-display-values E.g. a 10inch display with 1366x768 resolution might have a DPI value of 148, but you probably don't want 150% or 125% scaling given the small resolution anyway (think old netbooks). |
|
Updated to use the standard 96 instead of 100 as a step size. |
|
I tested this on all of the screens I have handy at home and made a table with my thoughts:
This looks like it's working very well! Some of my hunches and preferences are a bit off from the current behavior, but my preferences definitely trend toward smaller DPI. |
Unfortunately we don't have distance sensors nor information about the output being a TV right now. I am hoping we get the latter eventually with libdisplay-info, then we can use a different heuristic here. So this issues is sadly expected.
If we want 100% that isn't super easy to solve. I'd guess we would have to diverge from the standard 96 = 100% scaling ratio to get FHD at 15" just under the calculated ratio, which obviously affects every setup. E.g. the HP Dev One would likely end up at 125% then. We could also artificially limit this to 100% for FHD (right now we theoretically even allow 150% at that resolution for small displays, see HP Dev One), but that also feels wrong. On smaller screens FHD at 100% can certainly be very small.
I feel like this is somewhat common with linux users in general given the state of fractional scaling for years. 96 dpi = 100% is also a very conservative ratio, while most people can comfortably deal with e.g. 120dpi at that scale. But for accessibility reasons I would prefer to rather go a little too far then fall short. Windows has changed these defaults pretty aggressively over the years and I have barely seen any complaints of this behaviour as fixing this just a one-time adjustment. MacOS also defaults to a rather conservative 200% scaling on many of it's retina displays, where I would personally always select the less dense options myself. |
|
Yeah I definitely think erring on the big side is best. In the time I was on the support team, I helped many customers turn up scaling or turn down resolution, but I never had to help anyone turn the scaling down or resolution up because they wanted the text smaller. Lowering scaling is easy and the setting is remembered, so people that share my preferences likely won't be too burdened with having to customize it themselves. I'm fine with 96 if everyone else is. |
you can somewhat reliably infer the viewing distance based on the vertical size of the display in most cases. Height is the most useful way to gauge the intended use when missing additional info. 32"-36" displays are a little spotty, one of the more common "TV" or extended distance sizes would be a 40" 16:9 display, or roughly 19.6 vertical inches. If the height exceeds 19" then it could be safe to increase the scale by an amount depending on the resolution of the display, some displays may even need a greater then 200% scaling, but not one I have seen. EDIT: you can go a step further and limit this to HDMI displays. as most TVs barring a select few will be HDMI anyways (despite how I wish this werent true), so it could be a somewhat reliable as DP may be used for more special use cases. |
See that somewhat is somewhat irritating to me. 😅 I am not saying this is a bad approach nor that we shouldn't try to detect these cases in the future, but given we cannot do this reliably, I would rather merge this heuristic first, see how that works out and tweak it, before making it more complex. And I haven't 100% given up on detecting TVs yet, there are a few more informations channels we haven't even tapped into. If that fails we will certainly get back to an approach like that.
That is a good call in any cases, if we end up adding TV heuristics, those shouldn't apply for DP (or any non-HDMI) connection. |
|
I think having to customize scaling for "couch mode" is not unreasonable in the least. The computer I usually use with my TV, when running Gnome, also needed me to adjust the scaling factor to 200% manually. It is a desktop OS, after all. |
But can we detect if a DisplayPort-HDMI adapter is in use? Because with modern ultra-thin laptops it's pretty typical that any external display you connect will be over USB-C DisplayPort alt mode, whether that's adapted to an HDMI TV or a VGA projector. Native DisplayPort outputs indeed are likely to not be TVs. Or if they are it's an advanced setup where the user can be expected to configure scaling how they want it. Edit: I guess display interface is a field in EDID and DisplayID. Presumably passed through by adapters like that? |
Since we've previously defaulted to the greatest possible resolution and no scaling, I'm not sure we really have a sample to compare how many people will need to go in the other direction once the defaults are changed. |
No description provided.