Otherwise we'll have a cursor sprite backed by a surface that no longer
exist. This usually doesn't happen, but can happen in rare situations
related to pointer capability changes Wayland client cursor changes and
hotplugs.
Fixes the following crash:
#0 meta_wayland_buffer_get_resource() at ../src/wayland/meta-wayland-buffer.c:128
#1 realize_cursor_sprite_from_wl_buffer_for_gpu() at ../src/backends/native/meta-cursor-renderer-native.c:1649
#2 realize_cursor_sprite_for_gpu() at ../src/backends/native/meta-cursor-renderer-native.c:1869
#3 realize_cursor_sprite() at ../src/backends/native/meta-cursor-renderer-native.c:1887
#4 meta_cursor_renderer_native_update_cursor() at ../src/backends/native/meta-cursor-renderer-native.c:1100
#5 meta_cursor_renderer_update_cursor() at ../src/backends/meta-cursor-renderer.c:414
#6 meta_cursor_renderer_force_update() at ../src/backends/meta-cursor-renderer.c:449
#7 update_cursors() at ../src/backends/meta-backend.c:328
#8 meta_backend_monitors_changed() at ../src/backends/meta-backend.c:338
#9 meta_monitor_manager_notify_monitors_changed() at ../src/backends/meta-monitor-manager.c:3590
#10 meta_monitor_manager_rebuild() at ../src/backends/meta-monitor-manager.c:3678
#11 meta_monitor_manager_native_apply_monitors_config() at ../src/backends/native/meta-monitor-manager-native.c:343
#12 meta_monitor_manager_apply_monitors_config() at ../src/backends/meta-monitor-manager.c:706
#13 meta_monitor_manager_ensure_configured() at ../src/backends/meta-monitor-manager.c:779
#14 meta_monitor_manager_reconfigure() at ../src/backends/meta-monitor-manager.c:3738
#15 meta_monitor_manager_reload() at ../src/backends/meta-monitor-manager.c:3745
or the following on gnome-43:
#0 meta_wayland_surface_get_buffer at ../src/wayland/meta-wayland-surface.c:441
#1 meta_cursor_sprite_wayland_get_buffer at ../src/wayland/meta-cursor-sprite-wayland.c:83
#2 realize_cursor_sprite_from_wl_buffer_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1612
#3 realize_cursor_sprite_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1836
#4 realize_cursor_sprite at ../src/backends/native/meta-cursor-renderer-native.c:1854
#5 meta_cursor_renderer_native_update_cursor at ../src/backends/native/meta-cursor-renderer-native.c:1087
#6 meta_cursor_renderer_update_cursor at ../src/backends/meta-cursor-renderer.c:413
#7 meta_cursor_renderer_force_update at ../src/backends/meta-cursor-renderer.c:448
#8 update_cursors at ../src/backends/meta-backend.c:344
#9 meta_backend_monitors_changed at ../src/backends/meta-backend.c:354
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2185113
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2968>
This directory implements a framework for automated tests of Mutter. The basic
idea is that mutter-test-runner acts as the window manager and compositor, and
forks off instances of mutter-test-client to act as clients.
There's a simple scripting language for tests. A very small test would look like:
---
# Start up a new X11 client with the client id 1 (doesn't have to be an integer)
# Windows for this client will be referred to as 1/<window-id>
new_client 1 x11
# Create and show two windows - again the IDs don't have to be integers
create 1/1
show 1/1
create 1/2
show 1/2
# Wait for the commands we've executed in the clients to reach Mutter
wait
# Check that the windows are in the order we expect
assert_stacking 1/1 1/2
---
Running
=======
The tests are installed according to:
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
if -Dtests=true is passed to `meson configure`. You can run them uninstalled with:
ninja test
Command reference
=================
The following commands are supported. Quoting and comments follow shell rules.
new_client <client-id> [wayland|x11]
Starts a client, connecting by either Wayland or X11. The client
will subsequently be known with the given client-id (an arbitrary
string)
quit_client <client-id>
Destroys all windows for the client, waits for that to be processed,
then instructs the client to exit.
create <client-id>/<window-id> [override|csd]
Creates a new window. For the X11 backend, the keyword 'override'
can be given to create an override-redirect and the keyword 'csd'
can be given to create a client-side decorated window.
show <client-id>/<window-id>
hide <client-id>/<window-id>
Ask the client to show (map) or hide (unmap) the given window
activate <client-id>/<window-id>
Ask the client to raise and focus the given window.
local_activate <client-id>-<window-id>
The same as 'activate', but the operation is done directly inside Mutter
and works for both backends
raise <client-id>/<window-id>
lower <client-id>/<window-id>
Ask the client to raise or lower the given window ID. This is a no-op
for Wayland clients. (It's also considered discouraged, but supported, for
non-override-redirect X11 clients.)
minimize <client-id>/<window-id>
unminimize <client-id>/<window-id>
Ask the client to minimize or unminimize the given window ID. This older
term for this operation is "iconify".
destroy <client-id>/<window-id>
Destroy the given window
wait
Wait until all requests sent by Mutter to clients have been received by Mutter,
and then wait until all requests by Mutter have been processed by the X server.
assert_stacking <client-id>/<window-id> <client-id>/<window-id> ...
Assert that the list of client windows known to Mutter is as given and in
the given order, bottom to top. The character '|' can be present in the
list of windows to indicate the guard window that separates hidden and
visible windows. If '|' isn't present, the guard window is asserted to
be below all client windows.
This function also queries the X server stack and verifies that Mutter's
expectation of the X server stack matches reality.
867494d3df