I'd like to give a fresh description of this bug. I think I can do so
more concisely, as it affects gnome-shell. I was in two minds about
whether to report it as a new bug, but honestly feared if I did so it
would just be marked a duplicate of this one and ignored. :-)

Also to update for current versions:

gnome-shell: 3.26.0-0ubuntu1

Under Xorg only (not Wayland), the *text* elements of gnome-shell do not
reflect the scale setting chosen in Settings->Devices->Displays (set to
200% to reproduce), but instead just show the text at the size specified
in gnome-shell.css as if the scale was set to 100%.

The non-text elements of the gnome-shell UI are scaled correctly for the
chosen scale factor, so the size of icons and other elements, and the
placement of them, across the full screen is correct. Only the text size
is wrong.

Workaround 1: Using gsettings org.gnome.desktop.interface text-scaling-
factor to match the selected desktop scale, eg: setting it to 2.00,
corrects the error in gnome-shell, it then looks fine. But this is
useless as a workaround as it also scales up all text on the desktop
that was already scaled correctly.

Workaround 2: If the shell theme in use has a gnome-shell.css file, edit
it to set the stage font-size to double its original. eg: for Arc theme,
as I use, change it from 9pt to 18pt. Obviously you need to change this
whenever you change your desktop scale setting and force the theme to be
reloaded.

Note: This bug affects the default shell theme too, but as far as I can
see, that doesn't have a comparable gnome-shell.css file to fix, so I
don't know how to work around it with that. (I expect it is possible, I
just don't know where.)

Requested fix: in Xorg (it already works in Wayland), font size should
be multiplied by desktop scaling factor. This is a regression because it
used to work when desktop scaling was controlled by gsettings
org.gnome.desktop.interface scaling-factor. I think especially seeing as
fractional scaling didn't make it into gnome 3.26, except in
experimental (and somewhat broken, I did try it) form, it's not
unreasonable to expect non-fractional scaling factors to continue to
work as they did in 3.24, even if controlled from a different setting.
:-)

Slightly wider note on HiDPI:

Forcing wayland on my nvidia system seemed to work for a while, but
actually became more unstable over time as more updates came in, until
as of writing, both nouveau and nvidia proprietary drivers fail
catastrophically under kernel 4.13, apparently crashing in the DRM
supporting code, making the system completely unusable. (I had to ssh in
to recover.)

Well, kms isn't supported under nvidia yet, so I was asking for trouble
trying to force it to work, so this isn't a bug report about that. We
know it's broken. Hence me going back to trying to use Xorg. On my non-
nVidia machine I'm happy with Wayland, but I'm sure I'm not the only
nvidia user out there with a HiDPI monitor who's about to see their
systems become completely unusable under Linux. That's a lot of users
who, right now, can't step up to Wayland, and there's probably more that
have other rational reasons for needing to stick with Xorg right now.

And the vexing thing is, it's so *close* to working pretty well under
Xorg. I've needed to do just three workarounds to get the system back to
being completely usable, even with two monitors of different sizes.

The first is the one described above, to fix gnome-shell's text size.

The second is to explicitly set gsettings org.gnome.desktop.interface
scaling-factor to 2 as well, as some apps, including some gnome apps
like Nautilus, are still obeying that and not the new scale setting in
the control center. I'm sure those apps will come around to the new
setting eventually but they probably should get a separate bug report.

(And will someone *please* tell me where that new setting is? I could
really do with being able to set and read it via a script. Presumably
it's a gsettings value somewhere? But I can't find it.)

The third is to use Xrandr to provide something like fractional scaling
in exactly the manner that macOS does it (so I really don't feel that
it's slumming it, and if it's cheating, rather than "properly" doing
fractional scaling, I'm happy with the cheat to have something that
works *now*). This lets me, for instance, match a 27" 1440p monitor to a
27" 4K monitor both showing desktops of the same size, with scale set in
displays prefs to 200%:

To get a "Looks like 1080p" on a 1440p monitor, equivalent to 133.33...%
scaling:

xrandr --output DP-2 --scale-from 3840x2160 --auto --panning 3840x2160

That then pairs nicely with my 4K monitor at 200% and native resolution.

Or to get a "Looks like 1440p" on a 4K monitor, equivalent to 150%
scaling:

xrandr --output DP-4 --scale-from 5120x2880 --auto --panning 5120x2880

(Actually on nvidia I can set this via the nvidia-settings app, but it's
just doing xrandr as above, so it's not an nvidia-specific method.)

It would be great if this behaviour could be put behind the Displays
user interface, because the underlying display system can already do it.
As I said, this *is* how it works in macOS (obviously not actually using
xrandr...): "Retina" modes are all 200%, but so-called fractional
scaling modes are scaled down from larger desktop areas. The "Looks like
2560x1440" is, you can see if you take a screenshot, a full 5K desktop
area. Their user interface even warns that it's not as optimal as the
default scaling mode, but they let you do it and it works fine, and on a
fast GPU you don't really notice or care it's not optimal. And xorg can
do it *right now* (I'm using it this minute) using xrandr and a fixed
scaling factor of 200%.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1713323

Title:
  HiDPI support partially broken after upgrade to Gnome 3.25

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1713323/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to