Skip to content

seat/impl: Wait for pointer constraining when updating viewports

It is generally assumed here and there that the pointer at all point in time is within some logical monitor, if there is any logical monitor to be within.

With the input thread, this was for a short amount of time not reliable, resulting in crashes in combination with hotplugging or suspend/resume, where monitors come and go quickly.

What happens is that the pointer at first is within a logical monitor, but when that logical monitor is removed, while the new monitor viewports are handed to the input thread, the constraining happens asynchronously, meaning there is a time between between the new viewports are sent, and before clutter_seat_query_state() starts reporting the constrained position.

If a new client mapped a maximized window during this short time frame, we'd crash with

#0 meta_window_place at ../src/core/place.c:883
#1 place_window_if_needed at ../src/core/constraints.c:562
#2 meta_window_constrain at ../src/core/constraints.c:310
#3 meta_window_move_resize_internal at ../src/core/window.c:3869
#4 meta_window_force_placement at ../src/core/window.c:2120
#5 xdg_toplevel_set_maximized at ../src/wayland/meta-wayland-xdg-shell.c:429
#6 ffi_call_unix64 at ../src/x86/unix64.S:105
#7 ffi_call_int at ../src/x86/ffi64.c:672
#8 wl_closure_invoke at ../src/connection.c:1025
#9 wl_client_connection_data at ../src/wayland-server.c:437

The fix for this is to make sure that the viewports are updated and pointers constrained synchronously, i.e. the main thread will wait until after the input thread is done constraining before continuing.

Related: https://bugzilla.redhat.com/show_bug.cgi?id=2147502


Tried adding a test case for this using metatests, but the only way to trigger it was sneaking in a strategic sleep(1) at exactly the right time in the input thread, so perhaps not very nice of a test.

Merge request reports