GNOME Bugzilla – Bug 729013
Use OUTPUT_SCALE instead of xft-dpi on wayland
Last modified: 2021-07-05 14:26:36 UTC
We should use the OUTPUT_SCALE that is set the primary output instead of xft-dpi when running as wayland compositor (the latter should no longer be set see bug 729012 )
Created attachment 275204 [details] [review] compositor: Add meta_get_primary_scale_factor api This gets used by gnome-shell to query the scale factor.
Created attachment 275205 [details] [review] gdkscreen-wayland: Emit monitors-changed when the output scale changes
Review of attachment 275205 [details] [review]: We should probably have a better signal than this. notify::scale or something.
Review of attachment 275204 [details] [review]: ::: src/compositor/compositor.c @@ +185,3 @@ + +int +meta_get_primary_scale_factor () (void) @@ +199,3 @@ + if (outputs[i].is_primary) + { + scale_factor = outputs[i].scale; Is outputs[i].scale not set in the RANDR backend? I'd rather just add something there. @@ +202,3 @@ + break; + } + } Indentation here is screwy.
Created attachment 275217 [details] [review] hidpi: Use meta_get_primary_scale_factor Don't query the xsettings directly but ask mutter for the scale factor instead. Also go back to use 'monitors-changed' to not depend on xsettings. Forgot to attach this one.
Comment on attachment 275205 [details] [review] gdkscreen-wayland: Emit monitors-changed when the output scale changes Attachment 275205 [details] pushed as b395929 - gdkscreen-wayland: Emit monitors-changed when the output scale changes
(In reply to comment #4) > Review of attachment 275204 [details] [review]: > > @@ +199,3 @@ > + if (outputs[i].is_primary) > + { > + scale_factor = outputs[i].scale; > > Is outputs[i].scale not set in the RANDR backend? I'd rather just add something > there. Yeah I though about it but we don't have per monitor scaling on X anyway and apps read ot the xsetting anyway (and we don't want to do xsettings in mutter) so it does not add much value.
Even if we fill outputs[i].scale from gdk-window-scaling-factor in meta-monitor-manager-xrandr.c, that would be better for me.
(In reply to comment #8) > Even if we fill outputs[i].scale from gdk-window-scaling-factor in > meta-monitor-manager-xrandr.c, that would be better for me. OK fair enough.
(In reply to comment #9) > (In reply to comment #8) > > Even if we fill outputs[i].scale from gdk-window-scaling-factor in > > meta-monitor-manager-xrandr.c, that would be better for me. > > OK fair enough. Hmm actually no ... we don't know whether mutter gets the xrandr events first or g-s-d so we have a race here and might end up setting the wrong value. Unless we want to connect to the signal in mutter and keep updating it.
Created attachment 275761 [details] [review] compositor: Add meta_get_primary_scale_factor api This gets used by gnome-shell to query the scale factor. -- Fix whitespace and rebase bug. Still using the xsetting though.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.