HiDPI support partially broken after upgrade to Gnome 3.25, 3.26

[Rachel Greenham]

After an upgrade this morning that took in the new version of this package, and a suite of gnome-session/gnome-settings packages, which may also be implicated, support for scaling on HiDPI screens seems to have partially failed. Partially.

BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but when I got to the launchpad page it had pre-filled "gnome-session". One presumes there's a reason for that so I've left it, especially as this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a settings migrations utility in ubuntu-session which I wonder if it might be implicated. (TBH looking at it it's not obvious why, though it does reset scaling - that's not the problem, the problem is that it can't be set back to a combination that works.)

Reminder all the stuff I'm reporting below as being wrongly-scaled was scaled correctly before the update that just took place. Enpass got a little help from having some QT env variables set, but that's it.

Logging in under session "Ubuntu" (Wayland - on a different machine as this one being nvidia doesn't support it) or session "Ubuntu on Xorg" - also affects GNOME sessions:

* The fonts in the top bar, and the menus and indicators accessible from there, are unscaled. The indicator icons *are* scaled correctly.

* The fonts in the applications view are unscaled, but the icons and layout *are* scaled correctly.

* Menu titlebar *text* is unscaled. close/minimize/maximize widgets *are* scaled correctly, as is the titlebar's size itself.

* The mouse pointer is unscaled.

* Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-client, hexchat, sublime text 3) are unscaled, or in some cases are a bit confused, with some elements correctly scaled, but again fonts are not.

* Also on a personal note, Java 9 JavaFX apps are no longer scaled. (In Java 8 it was already broken; I was targeting Java 9 with my development partly *because* its HiDPI support was working in Linux.) FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

## What is working:

* Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus, Gedit etc. etc.) are all fine. Although note those that use a "normal" titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus) show small titlebar text as mentioned above

* Google Chrome, Thunderbird, Firefox are fine (although the latter two aren't being updated for Artful yet, just sayin' ;-)

## What happens if I try to fix it:

gsettings org.gnome.desktop.interface scaling-factor appears to no longer be operational. Changing its value from 0 (default), 1 and 2 appears to have no effect on anything any more. It used to be setting it to 2 fixed the few things that weren't right by having it set to 0... Correction, that *does* fix it for Java 9 JavaFX, it must be reading that setting directly. But nothing else reported as broken above is affected by changing this setting. Nor in fact does setting it to 1 cause gnome apps to be unscaled.

gsettings org.gnome.desktop.interface cursor-size is working. I can set it to 48, double its normal size, to get back normal-sized cursors when the pointer is over newly-launched applications. But that's obviously a workaround.

gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0, also exposed in Gnome Tweaks, unsurprisingly makes text twice as large. That "fixes" it for the applications that are reported as being unscaled above, but it also doubles the size of text in gnome apps as well, so those are now far too large for the windows they're in. Google Chrome is unaffected by this, as is Java 9 JavaFX, but Thunderbird *is* affected.

I noticed a new gsetting: com.ubuntu.user-interface scale-factor, but it seems to have a nonsense-value "@a{si} {}". I have no idea if this is anything in use or if it was an intended Unity 8 thing. I didn't try anything with it.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: ubuntu-session 3.25.90-0ubuntu2
ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
Uname: Linux 4.12.0-11-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.6-0ubuntu7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sun Aug 27 13:03:53 2017
InstallationDate: Installed on 2017-07-30 (27 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
SourcePackage: gnome-session
UpgradeStatus: Upgraded to artful on 2017-08-22 (5 days ago)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[CirclingTheSun (circlingthesun)]

This may be related to fractional scaling (https://hackmd.io/KwQwxiAsCmCMwFoCcJiwTAHAEwSESiAbAOwDMYJcAZtWWdkA?view) that I think will be in Gnome 3.26. Maybe the scaling-factor setting lives elsewhere now?

[CirclingTheSun (circlingthesun)]

Curiously gnome-control-center is still on version 3.24.3 (instead of 3.25.x). This may explain why settings are not taking effect.

[CirclingTheSun (circlingthesun)]

It appears the release of gnome-control-center is delayed (https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1712797). Enabling the gnome3-staging ppa via (ppa:gnome3-team/gnome3-staging) allowed me to change the scaling factor again.

[Rachel Greenham (rachel-strangenoises)]

I was changing the settings from the commandline via gsettings eg:

gsettings set org.gnome.desktop.interface scaling-factor 2
gsettings reset org.gnome.desktop.interface scaling-factor

etc. etc.

That setting never was exposed in the user interface, to my knowledge. Rather uselessly the text-scaling-factor setting was, and is, in gnome-tweaks.

I'll put gnome3-staging on one of my systems and see what's what. I think the hope would be that the gnome-control-center now exposes the setting that works, whatever that is, presumably not scaling-factor :-) Let's see...

[Rachel Greenham (rachel-strangenoises)]

I can confirm that including gnome3-staging solves most of my HiDPI issues.

Nearly everything seems to work now, according to the setting in the control panel -> peripherals -> display tab. I don't know what that is exposing in gsettings (if it is); nothing obvious. It's certainly *not* org.gnome.desktop.interface scaling-factor, which is unaffected by that control. But it is working for me.

What still doesn't work:

* Java9 JavaFX, which is still apparently getting its idea of scale purely from org.gnome.desktop.interface scaling-factor and works according to that setting. That's their bug, presumably.
* QT apps like nextcloud-client may still have issues. When launched at login it still shows small fonts, but when relaunched later, it's fine. Little wrinkle. It might be the difference between the mysterious new setting being at a default-autodetect state, and being set deliberately to 200% now.

[Rachel Greenham (rachel-strangenoises)]

Spoke slightly too soon. It's fine on the Wayland machine, but a bit more unstable on the nvidia/xorg machine, and I seem to need to select the scale percentage twice before it properly takes effect, and it looks like under some circumstances it can revert to the state described in the original post. Well, that's probably (one reason) why it's still in staging. :-) So I guess we're already at the point where wayland is more stable than xorg. Come on nvidia!

[Daniel van Vugt (vanvugt)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 1714295, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.

[Daniel van Vugt (vanvugt)]

Sorry, let this be the primary bug.

[Rachel Greenham (rachel-strangenoises)]

Hope I'm not being overly pedantic:

The upgrade that originally broke it, that I applied on Aug 27, did *not* include gnome-shell. If it had it would have been an obvious culprit and I would have reported the bug against that instead of gnome-session. So at the time I originally reported this bug I was still running gnome-shell 3.24.3-0ubuntu4, according to my apt history.log.

Adding the gnome3-staging PPA on Aug 29 and thus only then getting gnome-shell 3.25 is what *fixed* the bug, but only for Wayland sessions. Xorg sessions still showed, and continue to show, the bug. (On my nvidia machine I'm now using nouveau/wayland to get around it despite other issues, but that's another story.)

Under Xorg the bug continues to show regardless of driver, ie: on nvidia proprietary drivers, nouveau, and on my other machine, on intel hd.

[Dean Henrichsmeyer (dean)]

On the affected system if you launch gnome tweak tool will it do the appropriately HiDPI scaling for everything but the title bar and notifications?

[Rachel Greenham (rachel-strangenoises)]

The only scaling setting in tweak tool is the one in the Fonts section, which appears to be exposing org.gnome.desktop.interface text-scaling-factor. It scales the *text*. It scales all text relative to its original size. So if I set it to 2.0 the text that's half size will be the correct size, but the text that already *was* the correct size will be twice that size, and mostly too big for the windows it's in, as only the text has been scaled, not most of the other user interface components.

As described in the original post under the paragraph starting "gsettings org.gnome.desktop.interface text-scaling-factor"

I've never seen the point of that setting. It's always done that, but only setting the text scale without the rest of the user interface is useless.

[Rachel Greenham (rachel-strangenoises)]

... or if you meant does the gnome tweak tool *itself* appear with its user interface elements at the correct size or too small? It shows at the correct size, including the titlebar... but actually contrary to my original report *all* titlebars, both the system and integrated type, are now being shown with text at the correct size.

In gnome-shell itself - the top bar, the menus and indicators off that, the applications and activities views - the text is still half-size. Also in at least some QT apps (eg: nextcloud-client) the text is still half-size, but GTK-based apps that had half-sized text in the original bug report, eg: hexchat, sublime text, etc., those now seem fine.

So there is a change since originally reporting. The problem does seem more restricted just to gnome-shell and non-GTK-based apps.

[Jeremy Bícha (jbicha)]

I don't have a Hi-DPI screen so I'm unsure about all the details.

My understanding is that you need to configure HiDPI for Qt apps separately.

I think that GNOME Shell 3.25.90 doesn't really support HiDPI for X, just for Wayland. That may be a regression, but Hi-DPI support in GNOME Shell has been redesigned to prepare to support fractional scaling in Wayland in a future release and it may be a lot more complicated for all that to work well on X too.

[Rachel Greenham (rachel-strangenoises)]

I care slightly less than I used to because I just now persuaded ubuntu wayland session to run on nvidia-384 proprietary drivers. :-) Something which I presume is intended to be the default behaviour at some point, or at least for Nouveau.

So since I reported this bug the move to gnome 3.25 has made it possible, for me at least, to leave Xorg behind, along with problems like this. I'm sure you'll have plenty of people who can't, or won't, for one reason or another, but I'm not one of them. nouveau and nvidia didn't work with wayland out of the box though; I had to pick up hints from archlinux forums and suchlike to figure out the necessary incantations. Presumably that'll get ironed out before release ;-) because now it's working it seems fine, apart from a minor redraw glitch while dragging windows larger, which if I'm going to make anything of I'll report elsewhere.

Final note though: The new 3.25 gnome-control-center was necessary to actually select the correct desktop scaling factor, and that's still only in gnome3-staging. (If there's a gsettings key for that new setting, I can't find it.)

[Brad Figg (brad-figg)]

I'm also seeing odd scaling issues with the recent update. What's interesting is that once I bring up gnome-tweak-tool all my scaling issues "go away" the title bars, fonts, login screen etc. are "fixed" and properly scaled.

[Rachel Greenham (rachel-strangenoises)]

No wait, I've bethought me, actually. Partly brought on by issues with nvidia/wayland that weren't immediately obvious - nouveau is actually working better for me, if noticeably a bit more sluggish.

Regarding your comment:

"I think that GNOME Shell 3.25.90 doesn't really support HiDPI for X, just for Wayland. That may be a regression, but Hi-DPI support in GNOME Shell has been redesigned to prepare to support fractional scaling in Wayland in a future release and it may be a lot more complicated for all that to work well on X too."

Yes, it is a regression, because it was working for *non* fractional scaling factors, and should reasonably be expected to go on doing so, even if it's fed from a different setting. (ie: it's now ignoring org.gnome.desktop.interface scaling-factor)

At the moment, in the gnome control center 3.25, I'm seeing only these scaling options on my desktop: 100%, 200%, 300%; and on my laptop only 100%, 200%. So we don't currently have fractional scaling right now anyway, though presumably they're expected to appear at some point. But it's rational to expect these non-fractional scaling factors to *go on working* in xorg, and perhaps for only those scaling factors to be offered via the user interface when in xorg.

And it so nearly does already. As previously described right now it's only gnome-shell itself, and non-GTK apps, that are not being scaled in xorg now, where they were before.

[Rachel Greenham (rachel-strangenoises)]

Brad's comment: No, I've not seen the act of merely *launching* the gnome tweak tool fix or alter anything in any way. In fact, though probably related, the latest update seems to have broken its Extensions tab, but that's another bug.

[Rachel Greenham (rachel-strangenoises)]

(though probably *unrelated*, I meant)

[Dean Henrichsmeyer (dean)]

It turns out my title bar issue was because my session had reverted to X for some reason rather than Wayland. I had to select X and then select Ubuntu again in order for it to choose and launch Wayland. After that my desktop is working as expected again.

[Dean Henrichsmeyer (dean)]

See https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716011 for what actually turned out to be my issue.

[John Skottis (giannissc)]

Also if you add a second monitor scaling is stuck at the default of the first screen and cannot be changed to anything else.

Note:

I am using a laptop with a 15 inch screen and 3200 x 1800 resolution with a second monitor with a 25 inch screen with 2560 x 1440 resolution. The primary monitor is the 25 inch and there is a scaling of 200% applied to the 15 inch. The scaling on the 25inch cannot be changed back to 100% and therefore the side bar looks enormous

[Rachel Greenham (rachel-strangenoises)]

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 ve...

[fossfreedom (fossfreedom)]

I strongly suspect this upstream bug/patch is the same/closely related

 - https://bugzilla.gnome.org/show_bug.cgi?id=788049

[Jeremy Soller (jackpot51)]

I have recommended this patch to upstream, which is the simplest method to fix the scaling issues described in detail above.

[Jeremy Soller (jackpot51)]

Here is a debdiff with the change, if Ubuntu would like to use it sooner.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "fix_x11_font_dpi.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Fusion (bornolbers)]

Info:
Ubuntu 17:10 upgraded from 17:04 (64bit)
gnome-shell --version: GNOME Shell 3.26.0
loginctl show-session 3 -p Type: Type=x11
Screen resolution: 3840x2160
VGA: nvidia 1050ti - 384.69
kernel: 4.13.0-11-generic

Status:
1. every update is applied.
2. tested with gnome extensions I've install, 'on' and 'off': result was the same
3. Gnome-tweak-tool - my default font size setting: 0,8 (I think that 0,8 - 0,9 is ok. With value less than 0,8 text is too small and with bigger than 0,9 ..should be under "universal access"=is too big).

Problem:
1. The gnome topbar is too small (both size and text), time and date are barely visible.
2. The dash's texts are also too small (names of the apps - under app's icons)
3. The window titlebar's text is tiny, although it's size is fine

Temporary Workaround (old ones - from a dupplicate bug):
1. if restart environment (alt+f2, r + enter) --> this fixes topbar size but leave other apps like nautilus untouched (which is fine cause they are working fine already)
2. if change font size through gnome-tweak-tool --> this fixes topbar size but also changes nautilus font size, which is not good, because nautilus font is already ok

Temporary Workaround (NEW - fastest):
1. change font size in any value through gnome-tweak-tool. For me, change from 0,80 to 0,81 and back to 0,8 solves the problem.

BUT: The workarounds mentioned above are temporary because the setting is undone after reboot.

Other Issues:
1. with font size on 1.00 (through gnome-tweak-tool) everything is very big.
2. Many Topicons are very small (like viber, telegram, skype, mega) Others (variety, deluge) are fine.

[Fusion (bornolbers)]

with the-minute-before-updates, including nvidia 384-90, topbar's text (where the clock lays down), dash's text changes in a chaotic way through gnome-tweak-tool. When I change the values, it changes in a normal way only the already correct text size (like nautilus text and gnome-tweak-took's window-text).

windows title's text: correct (normal changing)
topbar's text, dash's text: wrong (chaotic changing)

Issue: Chaotic changing. The size of the text on dash and the size of the text and size of topbar changes in a very strange way. From a value to the next it can be either normal, tiny in a random way. For example when change from value 0,81 to 0,80.. 0,81 is tiny and 0,80 is normal. But after some changes maybe both 0,8 and 0,81 be tiny or normal or otherwise. That is happening at all values between 0,80 and 1,00 that I checked. At start I tried to find a pattern and put here the values that happened, but there are not such values, if I change the values from 0,8 to 1,0 I get different result than if I change them from 1,0 to 0,8.

[Rachel Greenham (rachel-strangenoises)]

I'm looking forward to seeing how much the upstream changes fixes all these. Yes, I also saw some of the other transient effects noted above; the gnome-shell text part of it was just the bit I managed to isolate and find consistency in. :-)

I had seen the need to apply scaling twice - sometimes, and titlebar text being unscaled at first, but fixing itself before long, I think after some particular thing happens that I haven't yet identified. (I think going to activities view and back fixed it, for instance, but not sure about that yet.) Some apps still having small text was "fixed" by setting the old scaling-factor setting, but I knew that wasn't a proper fix, just hoped it was an observation that might help someone narrow it down. IIRC I think one of the upstream bugs mentioned relates to that already.

TBH I never did see any point in changing the text-scaling-factor setting (the font size multiplier in gnome tweak tool). It just makes the text that already is right go wrong, so I never found it to be useful. My only mention of it was to show how the problem, for me anyway, only affected gnome-shell *text*.

[Rachel Greenham (rachel-strangenoises)]

I just got the mutter upgrade to 3.26.0+20170925~ea214fb-1. My gnome-shell text was too big! So I reverted my local modification to the theme's gnome-shell.css ;-) and now the gnome-shell text is the correct size. I presume this build includes the abovementioned patch.

As this is, I think, the core bug in this bug report, I'm happy to call that fixed, as of this version.

Aside: I'm still getting too-small (ie: unscaled) text on system titlebars and some other (non-gnome) apps on login, which then mysteriously fixes itself when gnome-tweaks is launched, and for the rest of the session. (Yes I am finding that works now, and not launching activities view or anything.) I think that probably belongs in a separate bug report though.

[Jeremy Bícha (jbicha)]

Rachel, thanks for reporting on the current status. I am marking this a duplicate of bug 1717272 since that was the mutter bug that fixed several of the issues reported here.

Please do file that separate bug report.

[Kostiantyn Rybnikov (k-bx)]

Fresh Ubuntu 17.10 has the issue of showing Qt apps non-scaled. Should we reopen the https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1717272 issue, continue here, or make a new one? What's the way to go?