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