GNOME Bugzilla – Bug 726238
hidpi: Fix scale-factor updates
Last modified: 2014-03-13 14:52:37 UTC
See patches basically we do not correctly handle changes of the scale factor while running.
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.
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.
Review of attachment 271710 [details] [review]: Looks good
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.
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
(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.
(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.
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
(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).