[PATCH 0/1] MR9068: winewayland: don't discard absolute motion events if in relative mode
There exist clients that disable hardware cursors, and instead draw a software cursor during their renderloop. Such clients incorrectly cause winewayland to enable relative pointer motion because winewayland thinks the cursor is not visible, when it is in fact visible and just drawn by the client instead. Enabling relative pointer motion breaks compositors that simulate wl_pointer from tablet tool motion. sway is one such compositor that supports sending wl_pointer events for clients that don't understand tablet-v2. Fix this by not discarding absolute motion events even in the case that relative pointer motion is active. When relative pointer was implemented, winewayland didn't support SetCursorPos and accepting absolute motion events would break mouselook in 3D games. However, now it does support SetCursorPos so there should be no harm in accepting absolute motion events as well. This allows tablet devices to work with winewayland running badly behaved clients that do software rendering of cursors on compositors that do simulate wl_pointer from tablet motion, despite winewayland not supporting tablet-v2 yet. Signed-off-by: Gopal Prasad <llyyr.public(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9068
From: llyyr <llyyr.public(a)gmail.com> There exist clients that disable hardware cursors, and instead draw a software cursor during their renderloop. Such clients incorrectly cause winewayland to enable relative pointer motion because winewayland thinks the cursor is not visible, when it is in fact visible and just drawn by the client instead. Enabling relative pointer motion breaks compositors that simulate wl_pointer from tablet tool motion. sway is one such compositor that supports sending wl_pointer events for clients that don't understand tablet-v2. Fix this by not discarding absolute motion events even in the case that relative pointer motion is active. When relative pointer was implemented, winewayland didn't support SetCursorPos and accepting absolute motion events would break mouselook in 3D games. However, now it does support SetCursorPos so there should be no harm in accepting absolute motion events as well. This allows tablet devices to work with winewayland running badly behaved clients that do software rendering of cursors on compositors that do simulate wl_pointer from tablet motion, despite winewayland not supporting tablet-v2 yet. Signed-off-by: Gopal Prasad <llyyr.public(a)gmail.com> --- dlls/winewayland.drv/wayland_pointer.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/dlls/winewayland.drv/wayland_pointer.c b/dlls/winewayland.drv/wayland_pointer.c index c4fdb33a766..93baddd4c43 100644 --- a/dlls/winewayland.drv/wayland_pointer.c +++ b/dlls/winewayland.drv/wayland_pointer.c @@ -170,11 +170,6 @@ static void pointer_handle_motion_internal(wl_fixed_t sx, wl_fixed_t sy) static void pointer_handle_motion(void *data, struct wl_pointer *wl_pointer, uint32_t time, wl_fixed_t sx, wl_fixed_t sy) { - struct wayland_pointer *pointer = &process_wayland.pointer; - - /* Ignore absolute motion events if in relative mode. */ - if (pointer->zwp_relative_pointer_v1) return; - pointer_handle_motion_internal(sx, sy); } -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/9068
I also would like to add that the relative events should be consumed when the compositor confirms that the pointer is locked or confined. zwp_confined_pointer_v1_listener and zwp_locked_pointer_v1_listener should be used to listen for events, because the protocol does not guarantee immediate locking. Compositor may never lock the pointer or may unlock it at will, so there is a little sense in relative events without confirmed locks. However, maybe this is a task for another patch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9068#note_119696
participants (3)
-
llyyr -
llyyr (＠llyyr)
-
Stanislav Aleksandrov (＠lightofmysoul)