GNOME Bugzilla – Bug 729012
Don't set scale factor when running under xwayland
Last modified: 2017-07-07 13:22:30 UTC
There is no way to let the compositor know that some apps are scaled and some aren't so we should simply not set the scale factor at all and rely on apps that want to scale up by themselves (mostly gtk3 apps anyway) to use the native wayland backend.
How do I detect XWayland? Is the XSettings manager (eg. gnome-settings-daemon) running once per XWayland instance (for each app) or for all the X11 apps inside the same wayland compositor?
(In reply to comment #1) > How do I detect XWayland? There might be a better way but currently simply by checking the xrandr output names that have "XWAYLAND" in their name ex: DISPLAY=:1 xrandr -q Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192 XWAYLAND0 connected 1024x768+0+0 222mm x 125mm 1024x768@0.1Hz 0.0*+ > Is the XSettings manager (eg. gnome-settings-daemon) > running once per XWayland instance (for each app) or for all the X11 apps > inside the same wayland compositor? There is only one xwayland instance there are plans to start xwayland on demand but there is no point in running more the one.
All X11 apps have the same Xwayland instance. Otherwise, legacy apps that use multiple processes and connections wouldn't work.
Which means 2 copies of gnome-settings-daemon running, one with the X11 connection and one with the Wayland connection (in which case we'd need to make changes to gnome-settings-daemon to allow 2 instances running), or a single one running that would automatically spawn XWayland? I don't think that our current code can cope with both Wayland and X11 connections in the same process, or with X11 coming and going.
g-s-d runs on a Wayland connection? Why would it do that?
(In reply to comment #5) > g-s-d runs on a Wayland connection? Why would it do that? Because there are a number of plugins that still make sense inside a Wayland session, unless we're moving all those plugins to the compositor (power, xrandr, remote-display, etc.).
Created attachment 275216 [details] [review] xsettings: Skip resolution check on xwayland There is no way to let the compositor know that some apps are scaled and some aren't so we should simply not set the scale factor at all and rely on apps that want to scale up by themselves (mostly gtk3 apps anyway) to use the native wayland backend. --- OK here is a (not yet tested) patch that does that .. re on demand xwayland this is a different issue and should be handled in a different bug currently we have one global xwayland that always runs.
(In reply to comment #6) > Because there are a number of plugins that still make sense inside a Wayland > session, unless we're moving all those plugins to the compositor (power, > xrandr, remote-display, etc.). What does xrandr do? The other two don't seem like they would need to take X11 connections.
Created attachment 275248 [details] [review] xsettings: Skip resolution check on xwayland There is no way to let the compositor know that some apps are scaled and some aren't so we should simply not set the scale factor at all and rely on apps that want to scale up by themselves (mostly gtk3 apps anyway) to use the native wayland backend. -- Tested one (the previous patch had backwards logic).
So not sure if we want this if we do https://bugzilla.gnome.org/show_bug.cgi?id=729132 instead (in that case old apps should scale up like they do know).
Review of attachment 275248 [details] [review]: If that was the way we wanted to go, this is what we'd need to change. I'm not sure that's the way we want to go anyway... ::: plugins/xsettings/gsd-xsettings-manager.c @@ +504,3 @@ primary_monitor_should_skip_resolution_check (GnomeRROutput *primary) { + if (primary_monitor_is_x_wayland (primary)) I'd do that directly in get_window_scale().
This is basically obsolete by bug 781534