Xwayland may post damages for an X11 window as soon as the frame
callback is triggered, while the X11 window manager/compositor has not
yet finished updating the windows.
If Xwayland becomes compliant enough to not permit updates after the
buffer has been committed (see [1]), then the partial redraw of the X11
window at the time it was posted will show on screen.
To avoid that issue, the X11 window manager can use the X11 property
`_XWAYLAND_ALLOW_COMMITS` to control when Xwayland should be allowed to
post the pending damages.
Add `freeze_commits()` and `thaw_commits()` methods to `MetaWindowX11`
which are a no-op on plain X11, but sets `_XWAYLAND_ALLOW_COMMITS` on
the toplevel X11 windows running on Xwayland.
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/316
See-also: https://gitlab.gnome.org/GNOME/mutter/merge_requests/855https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
This is a workaround for X11 games which use randr to change the resolution
in combination with NET_WM_STATE_FULLSCREEN when going fullscreen.
Newer versions of Xwayland support the randr part of this by supporting randr
resolution change emulation in combination with using WPviewport to scale the
app's window (at the emulated resolution) to fill the entire monitor.
Apps using randr in combination with NET_WM_STATE_FULLSCREEN expect the
fullscreen window to have the size of the emulated randr resolution since
when running on regular Xorg the resolution will actually be changed and
after that going fullscreen through NET_WM_STATE_FULLSCREEN will size
the window to be equal to the new resolution.
We need to emulate this behavior for these games to work correctly.
Xwayland's emulated resolution is a per X11 client setting and Xwayland
will set a special _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on the
toplevel windows of a client (and only those of that client), which has
changed the (emulated) resolution through a randr call.
This commit checks for that property and if it is set adjusts the fullscreen
monitor rect for this window to match the emulated resolution.
Here is a step-by-step of such an app going fullscreen:
1. App changes monitor resolution with randr.
2. Xwayland sets the _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on all the
apps current and future windows. This property contains the origin of the
monitor for which the emulated resolution is set and the emulated
resolution.
3. App sets _NET_WM_FULLSCREEN.
4. We check the property and adjust the app's fullscreen size to match
the emulated resolution.
5. Xwayland sees a Window at monitor origin fully covering the emulated
monitor resolution. Xwayland sets a viewport making the emulated
resolution sized window cover the full actual monitor resolution.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/739
It's a UI pattern that has been superseded by client-side decorations,
apps that used to set the hint have generally moved on to headerbars.
Given that and the limitation to server-side decorated X11 windows,
GTK4 removed the client-side API for setting the hint, it's time to
follow suite and retire the feature.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/221
Add a new client message "_XWAYLAND_MAY_GRAB_KEYBOARD" that X11 clients
can use to tell mutter this is a well behaving X11 client so it may
grant the keyboard grabs when requested.
An X11 client wishing to be granted Xwayland grabs by gnome-shell/mutter
must send a ClientMessage to the root window with:
- message_type set to "_XWAYLAND_MAY_GRAB_KEYBOARD"
- window set to the xid of the window on which the grab is to be issued
- data.l[0] to a non-zero value
Note: Sending this client message when running a plain native X11
environment would have no effect.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
To keep feature parity with the Wayland backend, and
to improve the overall tiling experience with GTK apps,
add the _GTK_EDGE_CONSTRAINTS X11 atom and update it
when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
