Wayland: GdkMonitor size and position wrong with fractional scaling enabled.
Description:
mutter/gnome-shell supports fractional scaling (even though it's disabled by default).
To achieve a fractional scaling while the scale is an an integer value, mutter will advertise a higher scale value and then scale down the client surface.
The Wayland backend however tries to compute the actual output size and position based on the reported scale, which will give wrong results when fractional scaling is enabled.
The xdg-output aims at describing outputs in a way which is more in line with the concept of an output on desktop oriented systems and provides the size and locations of the monitors in globa lcompositor space, i.e. there is no need for gdk to try to guess the output size from the scale if it were using the xdg-output protocol.
Xwayland already has support for xdg-output so that using the X11 GDK backend (GDK_BACKEND=x11
) on Wayland gives the expected result.
Steps to reproduce:
-
Enable fractional scaling support in mutter
-
Select a fractional scale in gnome-control-center (e.g. 150%)
-
Save and build one of the following test client:
- gtk3: screensize.c
- gtk4: screensize4.c
-
Run the client with either the X11 backend and the Wayland backend, and note the discrepancies.
E.g. with a single 1920x1080 monitor at 150%:
With gtk3 using the x11 backend on Wayland:
The system has 1 monitor(s) attached:
* monitor #0, (0,0) [1280×800]
With gtk3 using the Wayland backend on Wayland:
The system has 1 monitor(s) attached:
* monitor #0, (0,0) [640×400]
This is actually affecting Firefox Wayland because Firefox tries to account for the output size when placing its popup windows (https://bugzilla.mozilla.org/show_bug.cgi?id=1534089)
Additional info
There've been an attempt to fix this in mutter (mutter!510 (closed)) but this would be a hack and misusing the wl_output protocol in an incompatible way.
The solution is to use xdg-output in GDK Wayland backend which would solve that issue nicely.