After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 788040 - GNOME Shell is not scaled according to the primary monitor
GNOME Shell is not scaled according to the primary monitor
Status: RESOLVED DUPLICATE of bug 788820
Product: mutter
Classification: Core
Component: general
3.26.x
Other Linux
: Normal major
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2017-09-22 09:12 UTC by Jiri Eischmann
Modified: 2017-10-12 09:57 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jiri Eischmann 2017-09-22 09:12:56 UTC
My setup:

Dell XPS 13 - built-in display: 13" 3200x1800
External display: 21" FullHD (1900x1080) set as primary
I'm running GNOME on Wayland

In GNOME 3.24, the scaling of GNOME Shell was set according to the primary monitor, the external one, in this case. All GNOME Shell UI had correct size because it's all placed on the primary monitor.
In GNOME 3.26, the scaling of GS is set according to the built-in monitor which makes all the GS UI on the primary monitor too large. In display settings I can only set scaling for the secondary built-in monitor, not for the external one.

GNOME Shell should be scaled according to the primary monitor to achieve correct sizes of UI elements because they're all placed on the primary monitor.

Window scaling works correctly and Wayland native apps rescale while moving them from one monitor to another.

If I turn the experimental HiDPI support on, the GS scaling on the primary monitor is correct. However, it's still experimental and not default. We should make sure that the default works at least well as in the previous version. Moreover the experimental support brings quite a major regression due to blurriness of windows of the most popular apps (Firefox, Chrome,...) and except for GS scaling the default works better if you have a truly HiDPI monitor and I suspect that's what users with such monitor will want to use for the time being.
Comment 1 Andreas Linz 2017-10-09 08:33:03 UTC
I can confirm this issue.
I am using a Lenovo X1 Carbon with 2560x1440 and an external monitor with the exact same resolution and the scaling for Firefox, chromium and others seems to depend on the internal laptop display (I only use the external monitor when connected).
But, GTK3 apps like Evolution, Nautilus, Gnome-Web etc. seem to work fine though.
Comment 2 Johan Lorenzo 2017-10-09 08:56:20 UTC
I confirm this as well.

(In reply to Jiri Eischmann from comment #0)
> In GNOME 3.26, the scaling of GS is set according to the built-in monitor
> which makes all the GS UI on the primary monitor too large.
I noticed it too. If I set the primary display to the builtin one, then gnome-shell looks perfectly fine.

> In display settings I can only set scaling for the secondary built-in
> monitor, not for the external one.
On my setup, I have the ability to set the scaling factor of both monitors. Nonetheless, even if my primary monitor is set to 100%, gnome-shell remains twice too big.

> GNOME Shell should be scaled according to the primary monitor
I agree. 

> If I turn the experimental HiDPI support on
After some investigation (at [1] for instance), I haven't found what gsetting key to toggle. Would you mind sharing how to turn it on, Jiri?


[1] http://blog.3v1n0.net/informatica/linux/gnome-fractional-and-multi-monitor-scaling-hackfest-the-report/
Comment 3 Andreas Linz 2017-10-09 09:25:45 UTC
@Johan Lorenzo

The dconf-editor shows that "scale-monitor-framebuffer" is the only supported value for org.gnome.mutter.experimental-featues
Activating this feature did not make a difference for me, though.
Comment 4 Johan Lorenzo 2017-10-09 09:33:47 UTC
Thanks Andreas!

> Activating this feature did not make a difference for me, though.

Same here. I had to reboot my machine to get the right scaling (restarting gnome may be just enough, though). Then, I saw exactly what you stated in comment 0.
Comment 5 Jonas Ådahl 2017-10-12 03:57:42 UTC
Ah, here is this bug, I couldn't find it before, so I created https://bugzilla.gnome.org/show_bug.cgi?id=788820 and attached the patches there.
Comment 6 Jonas Ådahl 2017-10-12 09:57:14 UTC
I'll close this as a duplicate (even though this one is older) because the patches in the other bug has now landed.

*** This bug has been marked as a duplicate of bug 788820 ***