If ClipCursor is called while the seat doesn't have a pointer and the call qualifies for locking the pointer, it would have tried to lock a null wl_pointer.
For example, I'm launching a fullscreen application (which causes ClipCursor calls on startup) in a headless compositor before I launch my virtual keyboard/pointer client. While the pointer is deinitialized and there cannot be a focused hwnd, the cursor wl_surface will not be set, making it qualify for pointer locking.
From: Attila Fidan dev@print0.net
If ClipCursor is called while the seat doesn't have a pointer and the call qualifies for locking the pointer, it would have tried to lock a null wl_pointer. --- dlls/winewayland.drv/wayland_pointer.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/dlls/winewayland.drv/wayland_pointer.c b/dlls/winewayland.drv/wayland_pointer.c index 6c852292c1d..957b4ce6d52 100644 --- a/dlls/winewayland.drv/wayland_pointer.c +++ b/dlls/winewayland.drv/wayland_pointer.c @@ -864,6 +864,12 @@ BOOL WAYLAND_ClipCursor(const RECT *clip, BOOL reset) wayland_win_data_release(data);
pthread_mutex_lock(&pointer->mutex); + if (!pointer->wl_pointer) + { + pthread_mutex_unlock(&pointer->mutex); + return TRUE; + } + if (wl_surface && pointer->pending_warp) { wayland_pointer_update_constraint(wl_surface, NULL, FALSE, TRUE);
Another alternative would be to encode the wl_pointer requirement in `needs_lock` and `needs_confine` in `wayland_pointer_update_constraint`. This has the extra benefit that it moves us towards better handling of dynamic removals, since we will then destroy any inert zwp constraint proxies without any special code paths (we are not completely there yet, since we don't guarantee reapplication of the cursor clip on wl_pointer removal, but it's a step in the right direction). Does such a change work for your use case?
-
Alexandros Frantzis (＠afrantzis) -
Attila Fidan
-
Attila Fidan (＠atticf)