[PATCH 0/1] MR7475: winewayland: Ignore relative motion while pointer lock is deactivated.
If the lock is deactivated, mouselook won't work properly, and the user probably doesn't want mouselook to be active. For example: * if the user is making their compositor inhibit constraints to temporarily prevent applications from disrupting pointer movement. * if the keyboard is unfocused on the window, the lock is almost certainly deactivated. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56681 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7475
From: Attila Fidan <dev(a)print0.net> If the lock is deactivated, mouselook won't work properly, and the user probably doesn't want mouselook to be active. For example: * if the user is making their compositor inhibit constraints to temporarily prevent applications from disrupting pointer movement. * if the keyboard is unfocused on the window, the lock is almost certainly deactivated. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56681 --- dlls/winewayland.drv/wayland_pointer.c | 34 ++++++++++++++++++++++++++ dlls/winewayland.drv/waylanddrv.h | 1 + 2 files changed, 35 insertions(+) diff --git a/dlls/winewayland.drv/wayland_pointer.c b/dlls/winewayland.drv/wayland_pointer.c index 52aaa337aac..6b389700e28 100644 --- a/dlls/winewayland.drv/wayland_pointer.c +++ b/dlls/winewayland.drv/wayland_pointer.c @@ -251,17 +251,44 @@ static const struct wl_pointer_listener pointer_listener = pointer_handle_axis_discrete }; +static void locked_pointer_v1_handle_locked(void *data, + struct zwp_locked_pointer_v1 *zwp_locked_pointer_v1) +{ + struct wayland_pointer *pointer = &process_wayland.pointer; + pthread_mutex_lock(&pointer->mutex); + pointer->lock_active = TRUE; + pthread_mutex_unlock(&pointer->mutex); +} + +static void locked_pointer_v1_handle_unlocked(void *data, + struct zwp_locked_pointer_v1 *zwp_locked_pointer_v1) +{ + struct wayland_pointer *pointer = &process_wayland.pointer; + pthread_mutex_lock(&pointer->mutex); + pointer->lock_active = FALSE; + pthread_mutex_unlock(&pointer->mutex); +} + +static const struct zwp_locked_pointer_v1_listener locked_pointer_v1_listener = +{ + locked_pointer_v1_handle_locked, + locked_pointer_v1_handle_unlocked +}; + static void relative_pointer_v1_relative_motion(void *private, struct zwp_relative_pointer_v1 *zwp_relative_pointer_v1, uint32_t utime_hi, uint32_t utime_lo, wl_fixed_t dx, wl_fixed_t dy, wl_fixed_t dx_unaccel, wl_fixed_t dy_unaccel) { + struct wayland_pointer *pointer = &process_wayland.pointer; INPUT input = {0}; HWND hwnd; POINT screen; struct wayland_win_data *data; + if (!pointer->lock_active) return; + if (!(hwnd = wayland_pointer_get_focused_hwnd())) return; if (!(data = wayland_win_data_get(hwnd))) return; @@ -316,6 +343,7 @@ void wayland_pointer_deinit(void) { zwp_locked_pointer_v1_destroy(pointer->zwp_locked_pointer_v1); pointer->zwp_locked_pointer_v1 = NULL; + pointer->lock_active = FALSE; } if (pointer->zwp_relative_pointer_v1) { @@ -775,6 +803,7 @@ static void wayland_pointer_update_constraint(struct wl_surface *wl_surface, TRACE("Unlocking from hwnd=%p\n", pointer->constraint_hwnd); zwp_locked_pointer_v1_destroy(pointer->zwp_locked_pointer_v1); pointer->zwp_locked_pointer_v1 = NULL; + pointer->lock_active = FALSE; pointer->constraint_hwnd = NULL; } @@ -822,7 +851,10 @@ static void wayland_pointer_update_constraint(struct wl_surface *wl_surface, if (!pointer->zwp_locked_pointer_v1 || pointer->constraint_hwnd != hwnd) { if (pointer->zwp_locked_pointer_v1) + { zwp_locked_pointer_v1_destroy(pointer->zwp_locked_pointer_v1); + pointer->lock_active = FALSE; + } pointer->zwp_locked_pointer_v1 = zwp_pointer_constraints_v1_lock_pointer( process_wayland.zwp_pointer_constraints_v1, @@ -830,6 +862,8 @@ static void wayland_pointer_update_constraint(struct wl_surface *wl_surface, pointer->wl_pointer, NULL, ZWP_POINTER_CONSTRAINTS_V1_LIFETIME_PERSISTENT); + zwp_locked_pointer_v1_add_listener(pointer->zwp_locked_pointer_v1, + &locked_pointer_v1_listener, NULL); pointer->constraint_hwnd = hwnd; TRACE("Locking to hwnd=%p\n", pointer->constraint_hwnd); } diff --git a/dlls/winewayland.drv/waylanddrv.h b/dlls/winewayland.drv/waylanddrv.h index c389167c3b7..67982dd57ba 100644 --- a/dlls/winewayland.drv/waylanddrv.h +++ b/dlls/winewayland.drv/waylanddrv.h @@ -110,6 +110,7 @@ struct wayland_pointer uint32_t enter_serial; uint32_t button_serial; struct wayland_cursor cursor; + BOOL lock_active; pthread_mutex_t mutex; }; -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/7475
The problem described in the linked bug is that the app is reacting to mouse events sent while the pointer is moving over it when it does not have the keyboard focus. However, in general, this is acceptable behavior for both Wayland and win32: keyboard focus is not a requirement to receive mouse events. It's up to the application to react (or not) to such mouse events, a decision that may or may not take into account the current keyboard focus. My guess is that the fundamental problem at play in this particular case is that since winewayland does not clear the win32 focus state when a surface loses the Wayland keyboard focus, the game thinks it's still focused and acts accordingly (instead of, e.g., having dropped the confinement and shown the cursor when focus was lost). I don't know of any good-for-all-cases answer to the more general question about what to do when the lock is disabled by the system itself, since AFAIK this is not a possible scenario under win32. All of the following are viable options depending on the application: 1. Do nothing (current code, i.e., keep relative motion enabled) 2. Block all pointer motion events (this MR, but what about mouse button/axis events?) 3. Switch to absolute events (e.g., if we are not dealing with a mouselook scenario) One concern I have with option (2) is that the cursor will just disappear when entering the unfocused window and leave the user without any feedback about what's going on. My personal preference is maintaining the current, more unopinionated "do nothing" approach and try to make some progress fixing the real underlying issue that's causing the bug. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7475#note_96762
My guess is that the fundamental problem at play in this particular case is that since winewayland does not clear the win32 focus state when a surface loses the Wayland keyboard focus, the game thinks it's still focused and acts accordingly (instead of, e.g., having dropped the confinement and shown the cursor when focus was lost).
Oh, right. I quickly added `NtUserSetForegroundWindow(NtUserGetDesktopWindow());` to the end of `keyboard_handle_leave` and that behaves more like winex11/xwayland. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7475#note_96764
On Tue Mar 4 14:38:47 2025 +0000, Attila Fidan wrote:
My guess is that the fundamental problem at play in this particular case is that since winewayland does not clear the win32 focus state when a surface loses the Wayland keyboard focus, the game thinks it's still focused and acts accordingly (instead of, e.g., having dropped the confinement and shown the cursor when focus was lost). Oh, right. I quickly added `NtUserSetForegroundWindow(NtUserGetDesktopWindow());` to the end of `keyboard_handle_leave` and that behaves more like winex11/xwayland. Hi! I reached here from the bug page and I encountered the same bug 56681. I have some questions and am hoping for some hints...
Yes for Wayland compositors, it's possible to send `wl_pointer::motion` and `zwp_relative_pointer_v1::relative_motion` even if the window is not keyboard-focused (`wl_keyboard::focused`) but pointer-focused (`wl_pointer::enter` i.e. cursor passing above the window). So if a game does not have such an "ignore mouse events if not focused" logic, under Wayland, the camera-unexpected-moving issue will happen.
in general, this is acceptable behavior for both Wayland and win32: keyboard focus is not a requirement to receive mouse events. It's up to the application to react (or not) to such mouse events, a decision that may or may not take into account the current keyboard focus.
I wrote a winit program which literally simulates what a typical 3D game does (let's call it `game-sim.exe`; actually the code is [here](https://github.com/bczhc/cursor-lock-demo/blob/d8990bd134d4353ea3c2978e32ba3...)): lock the pointer + hide the pointer, then handles the raw input mouse events to update the camera. The program does not have an "ignore mouse if not focused" logic, and when I run it on Wayland, it has the issue; however when I run it on Windows, it doesn't have the issue. Does that mean, on Windows, - 1. Windows actually _doesn't_ send mouse events to an app if it's not focused? 2. Or, winit has special handling for it i.e. not let the Rust code receive `DeviceEvent::MouseMotion`s when the window is not focused? Idk..
My guess is that the fundamental problem at play in this particular case is that since winewayland does not clear the win32 focus state when a surface loses the Wayland keyboard focus, the game thinks it's still focused and acts accordingly (instead of, e.g., having dropped the confinement and shown the cursor when focus was lost).
I can confirm. https://bugs.winehq.org/show_bug.cgi?id=59740 seems to be related and I uploaded a demonstration video there. For my demo game-sim.exe, if I launched it in a `wineconsole`, an extra black console was displayed. In this case if I switched the focus from game-sim to the wineconsole, game-sim receives a focus-loss event and stops receiving raw input mouse events (the expected behavior!) But notably, game-sim _doesn't_ have an "ignore mouse event when not focused" logic. Since you said option (2) (`Block all pointer motion`) is not what wine does currently, how could the above happen... And one more question, since from my tests I've observed, a wine app will no longer receive raw input events if it _correctly_ gets notified a focus loss event, does this mean, once bug 59740 gets fixed bug 56681 can be fixed automatically? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7475#note_142413
participants (4)
-
Alexandros Frantzis (＠afrantzis) -
Attila Fidan
-
Attila Fidan (＠atticf)
-
Zhai Can (＠bczhc)