GNOME Bugzilla – Bug 782742
HiDPI scaling not triggered for 24 inch 4k (UHD) monitor (BenQ BL2420U)
Last modified: 2021-07-05 13:47:40 UTC
The monitor is a 24 (23.5) inch and has a 3840x2160 resolution. The display area (in mm) is 521.28x293.22 according to the spec and stepping through compute_scale with debugger I see that it is reported as (520x290). Resolution width was report correctly as 2160. This leads to a dpi_x, dpi_y of 187.5, 189.1, which is currently not enough to trigger the HIDPI_LIMIT (192). As a result everything is super tiny; clearly a scale of 2 would be better (macOS defaults to a scaling factor of two for it).
"Resolution width" should read "Resolution height" of course. Sorry.
I created a small script to do some simple and rough estimations to see what monitor sizes, resolution and aspect ratio will lead to what scaling factor; and if that would change if we were to adopt a 5% tolerance to already switch into HiDPI mode at 182.4 instead of 192. Script is here: https://gist.github.com/gicmo/88a640107ab8c14fbe9338a43f79bbb4 Output: Using threashold 192 22.0", 3840x2048, 4: 3 => 184.0 -> 1, 2 ! 22.0", 3840x2048, 16: 9 => 195.0 -> 2, 2 22.0", 3840x2048, 16:10 => 190.1 -> 1, 2 ! 22.0", 3840x2048, 21: 9 => 211.8 -> 2, 2 23.0", 3840x2048, 4: 3 => 176.0 -> 1, 1 23.0", 3840x2048, 16: 9 => 186.5 -> 1, 2 ! 23.0", 3840x2048, 16:10 => 181.9 -> 1, 1 23.0", 3840x2048, 21: 9 => 202.6 -> 2, 2 23.4", 3840x2048, 4: 3 => 173.0 -> 1, 1 23.4", 3840x2048, 16: 9 => 183.3 -> 1, 2 ! 23.4", 3840x2048, 16:10 => 178.8 -> 1, 1 23.4", 3840x2048, 21: 9 => 199.2 -> 2, 2 24.0", 3840x2048, 4: 3 => 168.7 -> 1, 1 24.0", 3840x2048, 16: 9 => 178.8 -> 1, 1 24.0", 3840x2048, 16:10 => 174.3 -> 1, 1 24.0", 3840x2048, 21: 9 => 194.2 -> 2, 2 25.0", 3840x2048, 4: 3 => 161.9 -> 1, 1 25.0", 3840x2048, 16: 9 => 171.6 -> 1, 1 25.0", 3840x2048, 16:10 => 167.3 -> 1, 1 25.0", 3840x2048, 21: 9 => 186.4 -> 1, 2 !
Created attachment 352220 [details] [review] monitor-manager: decrease HiDPI limit to 180 Currently we use a limit of 192, which is two times the classical screen dpi (96). For a hypothetical 4k UHD monitor this means the maximal width × height it can have and get a scale factor of 2 is around 508x270 (mm), i.e. a diagonal of 22.7". Therefore 23" or 24" monitors would not get a scale factor of 2, and text will be quite small. Changing the HiDPI limit will have the following result on the maximal size to still receive a scale factor of 2: limit, w × h, diagonal 192, 508 × 270, 22.7" 182, 535 × 285, 23.9" 181, 538 × 287, 24.0" 180, 541 × 289, 24.2" Therefore dropping the HiDPI limit to 180 seems reasonable to still include monitors just above 24".
Script to calculate the limits mentioned in the commit message is here: https://gist.github.com/gicmo/a1eb5f11cae692f8babe5f97441e1d76
(In reply to Christian Kellner from comment #0) > As a result everything is super tiny; clearly a scale of 2 would be > better (macOS defaults to a scaling factor of two for it). References of the limits or algorithms for macOS and Windows 10 would be very interesting to have. I know that my Surface 3 (1920x1080, 10.8 in" so 214 ppi) would benefit from not triggering hidpi due to the small resolution after the doubling, but could use a bigger font (so slightly bigger menu items and titlebars).
Created attachment 353313 [details] [review] monitor: decrease HiDPI limit for scaling to 180 Currently we use a limit of 192, which is two times the classical screen dpi (96). For a hypothetical 4k UHD monitor this means the maximal width × height it can have and get a scale factor of 2 is around 508x270 (mm), i.e. a diagonal of 22.7". Therefore 23" or 24" monitors would not get a scale factor of 2, and text will be quite small. Changing the HiDPI limit will have the following result on the maximal size to still receive a scale factor of 2: limit, w × h, diagonal 192, 508 × 270, 22.7" 182, 535 × 285, 23.9" 181, 538 × 287, 24.0" 180, 541 × 289, 24.2" Therefore dropping the HiDPI limit to 180 seems reasonable to still include monitors just above 24".
Comment on attachment 352220 [details] [review] monitor-manager: decrease HiDPI limit to 180 I have rebased the patch to git master.
(In reply to Christian Kellner from comment #6) > Created attachment 353313 [details] [review] [review] > monitor: decrease HiDPI limit for scaling to 180 > > Currently we use a limit of 192, which is two times the classical > screen dpi (96). For a hypothetical 4k UHD monitor this means the > maximal width × height it can have and get a scale factor of 2 is > around 508x270 (mm), i.e. a diagonal of 22.7". Therefore 23" or > 24" monitors would not get a scale factor of 2, and text will be > quite small. Changing the HiDPI limit will have the following > result on the maximal size to still receive a scale factor of 2: > > limit, w × h, diagonal > 192, 508 × 270, 22.7" > 182, 535 × 285, 23.9" > 181, 538 × 287, 24.0" > 180, 541 × 289, 24.2" > > Therefore dropping the HiDPI limit to 180 seems reasonable to still > include monitors just above 24". I'd like you to consider devices with high resolution screen in small form factors, eg. 10/12" tablets and convertibles, before pushing this. The heuristics might be bad, but at least they've been there for a while. If we're going to change them, we should make comprehensive changes, with an eye on all the cases we care about.
The work System76 has done with hidpi considers external monitors > 170 dpi to be hidpi. Though, laptop and desktop screens can feel quite different even at the same resolution. On laptops, treating 140 dpi as the "ideal" 1x display and 280 dpi as the "ideal" 2x display is a pretty good rule of thumb. Our experience shows that laptop screens can feel quite usable up to 210 dpi. Anything near 210 dpi (190-230) is a bad manufacturing choice for laptops, since there isn't an integer factor that feels "right". Things either feel usable but a little small or too big. On the other hand, a 24" desktop monitor at ~180 dpi really needs to be 2x. 27.5" displays are harder to classify, since viewing distance makes a big perceptual difference. There are a lot of laptop displays in the 160-170 dpi range that need to be treated as 1x. These tend to be 17.3" or less, though some oems make 21" laptop screens. ======= I'd recommend we lower the threshold for 2x on screens that are at least 22" in size. On smaller screens (laptops), we could also adopt 140 dpi as the 1x benchmark. 96 dpi isn't really a thing on laptops and hasn't been since 1080p displays became common in 17", 15", 14" and (sometimes) 13". When fractional scaling becomes a thing, 190-230 dpi would be defined as "1.5x" displays, helping users of laptops with odd density panels get as close to the look of a 1080p screen as possible. Everything else should continue to be scaled to an integer factor by default.
(In reply to David Jordan from comment #9) Thanks a bunch for the input, much appreciated. > I'd recommend we lower the threshold for 2x on screens that are at least 22" > in size. > > On smaller screens (laptops), we could also adopt 140 dpi as the 1x > benchmark. 96 dpi isn't really a thing on laptops and hasn't been since > 1080p displays became common in 17", 15", 14" and (sometimes) 13". When > fractional scaling becomes a thing, 190-230 dpi would be defined as "1.5x" > displays, helping users of laptops with odd density panels get as close to > the look of a 1080p screen as possible. Everything else should continue to > be scaled to an integer factor by default. ACK! So I think the best way to modify (well more evolve than just modify) the patch to have size dependent thresholds. This should also address Bastien's concern. I will give it a shot, we can then maybe discuss the exact numbers and workings based on the new patch.
A few corner cases already implemented in calculate_scale() that we should be careful not to break: variable sized screens and displays with bad edid data. Projectors often report 0mm for their physical dimensions, since there is no single correct value. These screens are often huge and 1x scaling is probably appropriate as a default. I've seen some desktop displays that report their aspect ratio as the physical dimensions in the EDID data. We can't clean anything useful about their actual dpi. The vast majority of displays reporting 16mm x 9mm or 160mm x 90mm are lying. There may be some laptop screens (or projectors) like this, but I haven't personally encountered any. Currently this aspect ratio as physical size case doesn't get any hidpi scaling. This is an okay default. However, we may be able to make assumptions about the dpi based on resolution and set a scaling factor by default above a certain resolution. That would be a riskier change that needs careful consideration of all the cases.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.