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 726238 - hidpi: Fix scale-factor updates
hidpi: Fix scale-factor updates
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2014-03-13 13:10 UTC by drago01
Modified: 2014-03-13 14:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
hidpi: Listen for gtk-xft-dpi instead of monitors-changed (2.35 KB, patch)
2014-03-13 13:10 UTC, drago01
committed Details | Review
hidpi: Make sure gdk and clutter scaling stays disabled when the scale factor changes (1.16 KB, patch)
2014-03-13 13:11 UTC, drago01
committed Details | Review

Description drago01 2014-03-13 13:10:51 UTC
See patches basically we do not correctly handle changes of the scale factor while running.
Comment 1 drago01 2014-03-13 13:10:54 UTC
Created attachment 271710 [details] [review]
hidpi: Listen for gtk-xft-dpi instead of monitors-changed

Currently we update the scale factor on startup and when we get a
monitors-changed signal, which is not the only cases where the setting changes. We cannot listen for gdk-window-scaling-factor changes because it is not
exported to gdk.

So use gtk-xft-dpi which also indicates a scale factor change.

When someone changes gtk-xft-dpi directly without changing the scale factor
we will just re-read the gdk-window-scaling-factor so no harm is done.
Comment 2 drago01 2014-03-13 13:11:00 UTC
Created attachment 271713 [details] [review]
hidpi: Make sure gdk and clutter scaling stays disabled when the scale factor changes

Not doing that could led to messy situations when the user changes the scale factor
at runtime.
Comment 3 Giovanni Campagna 2014-03-13 13:14:34 UTC
Review of attachment 271710 [details] [review]:

Looks good
Comment 4 Giovanni Campagna 2014-03-13 13:15:14 UTC
Review of attachment 271713 [details] [review]:

I think clutter and gdk should remember if the scale factor is set by the application, and ignore outside changes, but ok.
Comment 5 drago01 2014-03-13 13:16:28 UTC
Attachment 271710 [details] pushed as 5616bbd - hidpi: Listen for gtk-xft-dpi instead of monitors-changed
Attachment 271713 [details] pushed as c492415 - hidpi: Make sure gdk and clutter scaling stays disabled when the scale factor changes
Comment 6 drago01 2014-03-13 13:17:21 UTC
(In reply to comment #4)
> Review of attachment 271713 [details] [review]:
> 
> I think clutter and gdk should remember if the scale factor is set by the
> application, and ignore outside changes, but ok.

They seem to only do that when set via the env var ... don't ask me why it is done this way.
Comment 7 Jasper St. Pierre (not reading bugmail) 2014-03-13 14:47:05 UTC
(In reply to comment #1)
> Currently we update the scale factor on startup and when we get a
> monitors-changed signal, which is not the only cases where the setting changes.

Huh?

https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkscreen-x11.c#n1123

It emits monitors-changed at the bottom, always.
Comment 8 drago01 2014-03-13 14:51:11 UTC
Mär 06 19:01:19 <owen>	gcampax: So nothing in g-s-d is allowed to use gnome_rr_screen_new() now?
Mär 06 19:01:24 *	hyperair (~hyperair@175.156.69.254) hat #gnome-shell betreten
Mär 06 19:01:32 <owen>	(Just moved on to looking at https://bugzilla.gnome.org/review?bug=709859&attachment=260297 which adds such a call)
Mär 06 19:01:33 *	giallu hat die Verbindung getrennt (Read error: 148 (No route to host))
Mär 06 19:02:19 *	RavetcoFX (~RavetcoFX@66.222.149.241) hat #gnome-shell betreten
Mär 06 19:03:01 <gcampax>	owen: no, because g-s-d runs before mutter
Mär 06 19:03:09 <gcampax>	it has been the case since 3.10
Mär 06 19:04:32 *	API hat die Verbindung getrennt (Leaving)
Mär 06 19:06:06 *	tommie-lie (~thomas@HSI-KBW-5-10-56-11.hsi18.kabel-badenwuerttemberg.de) hat #gnome-shell betreten
Mär 06 19:07:13 <drago01>	well "We don't want hi-dpi screens running below native resolution to have a high scaling factor."
Mär 06 19:07:50 <drago01>	non native does not have to be "non high dpi" (in most cases it is but it should look at the current res)
Mär 06 19:08:05 *	g0bl1n hat die Verbindung getrennt (Ex-Chat)
Mär 06 19:09:16 <owen>	drago01: Yeah, I'm not sure about the sense of this patch (but the patch set goes ahead and later uses the GnomeRRScreen for other things)
Mär 06 19:10:16 <owen>	gcampax: Hmm, nasty loop here with respect to the idea that hi-dpi depends on screen configuration
Mär 06 19:11:24 <owen>	gcampax: Means that gnome-shell can start up hidpi or not - then switch over after initialization. Of course, that woudl also be the case if gnome-shell causes modesetting on startup.
Mär 06 19:11:37 <gcampax>	owen: right, but mutter ignores the hi-dpi setting, so it would just start always at 1 and get promoted to 2 when mutter is ready
Mär 06 19:11:43 <atrus>	partial tangent: any ideas how to just disabling the auto-high-dpi detection system-wide? my 25.5" monitor reports that it's 7" in size, and i haven't found a reasonable workaround short of updating gsettings for each user one at a time (which would be really bad if those user profiles existed on multiple systems, but for now is just annoying)
Mär 06 19:12:00 <owen>	gcampax: gnome-shell pays attention to it
Mär 06 19:12:08 <drago01>	gcampax: gnome-shell only updates the scaling when it gets "monitor-changed" from gdk
Mär 06 19:12:23 <mclasen>	atrus: didn't I see a suggestion to add a minimal resolution check ?
Mär 06 19:12:24 <owen>	atrus: You can set settings system wide, or put a corrected edid in your xorg.conf
Mär 06 19:12:26 <drago01>	which might be wrong anyway should be "when the xsettings changes"
Mär 06 19:12:32 <gcampax>	drago01: from gdk? why not from metascreen?
Mär 06 19:12:57 <drago01>	gcampax: because gdk is guaranted to emit it after having set the scale factor 
Mär 06 19:13:07 <drago01>	gcampax: metascreen might be racy
Mär 06 19:13:11 <atrus>	owen: i don't even have an xorg.conf, and i got very mixed messages on how to do it depending on what version of which driver you're using and what not.
Mär 06 19:13:23 <atrus>	and i never did find one that would work anyways.
Mär 06 19:13:40 <owen>	atrus: You put a snippet into /etc/X11/xorg.conf.d
Mär 06 19:13:48 <owen>	atrus: But yes, it's a fairly laborious thing
Mär 06 19:14:07 <gcampax>	drago01: yeah, we should listen to the xsettings and forget about monitor-changed
Mär 06 19:14:11 <owen>	atrus: http://www.burtonini.com/blog/computers/gsettings-override-2011-07-04-15-45
Mär 06 19:14:19 <atrus>	owen: any idea what that snippet would be? i've found many suggestions, and so far they've all been wrong. :)
Mär 06 19:14:29 <rtcm>	drago01: http://paste.fedoraproject.org/83075/39412962/ ? and, isn't your patch good for master too ?
Mär 06 19:14:29 <gcampax>	drago01: and btw, I hope gdk does not react to monitors-changed on its own to set the scale factor
Mär 06 19:14:34 *	rib1 hat die Verbindung getrennt (Leaving.)
Mär 06 19:14:45 <owen>	gcampax: GDK is getting the scale factor from gsd
Mär 06 19:14:48 <owen>	via xsettings
Mär 06 19:15:05 <gcampax>	owen: ok, so why does monitors-changed matter?
Mär 06 19:15:06 <drago01>	rtcm: ugh yes and yes
Mär 06 19:15:30 <owen>	gcampax: I'm not sure - maybe a leftover from previous vesions of the patch which computed things from the GDK monitor information?
Mär 06 19:15:33 <rtcm>	drago01: ok, I'll push to both then
Mär 06 19:15:40 <drago01>	rtcm: ok thanks
Mär 06 19:15:56 <drago01>	owen: yes
Mär 06 19:16:14 <atrus>	owen: so, that seems to be in the context of a package... is there a place to put things like that independent of packaging? somewhere in /etc?
Mär 06 19:16:37 <drago01>	gcampax: we have no xsettings code in mutter right?
Mär 06 19:16:46 <gcampax>	drago01: no, we use gdk's
Mär 06 19:16:59 <drago01>	gcampax: does gdk tell us when an xsetting changes ?
Mär 06 19:17:13 <gcampax>	drago01: yes, it's a GObject property, just listen to notify::
Mär 06 19:17:36 <drago01>	gcampax: I mean the xsetting itself not the gdk scale factor (we disable that one)
Mär 06 19:17:44 <gcampax>	(there is also a low-lever event I think, but we don't need that)
Mär 06 19:18:02 <gcampax>	drago01: yes, GtkSettings::gtk-scale-factor, is a GObject property
Mär 06 19:18:09 <drago01>	gcampax: ok
Comment 9 drago01 2014-03-13 14:52:37 UTC
(In reply to comment #7)
> (In reply to comment #1)
> > Currently we update the scale factor on startup and when we get a
> > monitors-changed signal, which is not the only cases where the setting changes.
> 
> Huh?
> 
> https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkscreen-x11.c#n1123
> 
> It emits monitors-changed at the bottom, always.

Seems to be correct but anyway we somehow agreed to use xsettings instead (see above IRC discussion).