https://bugs.winehq.org/show_bug.cgi?id=57909
Bug ID: 57909 Summary: Star Citizen WineWayland Cursor Warping Product: Wine Version: 10.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs@winehq.org Reporter: mactan@edgetransit.dev Distribution: ---
star citizen has a cursor warp issue on wayland that spins the camera down to stare at the ground or the cursor's last position on mouse move
observed behavior on 10.2 mainline nonstaging winewayland session. cursor flickers instead of being held and the cursor does not warp to center when the interact key is held, and the camera warps to the cursors last position https://youtu.be/rkWaCgDNZeo https://youtu.be/hvb-BOVlsew
these are examples of the expected behavior as observed on 10.2 x11 session, when the interact key (default F) is held, the cursor warps to the middle of the screen and the user can move the cursor freely from there. upon release and holding again, cursor warps to center when the key is held https://youtu.be/5cfveNGmHRI https://youtu.be/NKBSWfQrfCw
observed behavior on 10.2 wayland xwayland session. the cursor does not warp to center when the interact key is held, and the camera warps to the cursors last position https://youtu.be/9I3g-fbxMUQ https://youtu.be/MAm85csb4Lk
observed behavior with patches !7352 !7353 !7368 !7457 !7475 applied. cursor flickers instead of being held and constantly warps to the display center instead of being allowed to move about the screen after the initial warp. attached log with +waylanddrv,+win https://youtu.be/XxRbAljl49w https://youtu.be/RyS8UjzH9hs
https://bugs.winehq.org/show_bug.cgi?id=57909
--- Comment #1 from mactan@edgetransit.dev mactan@edgetransit.dev --- Created attachment 78153 --> https://bugs.winehq.org/attachment.cgi?id=78153 winewayland-no-enter-move-if-relative patch
One of our players shared this patch which attempts to calm down the warping behavior but is a temporary workaround
https://bugs.winehq.org/show_bug.cgi?id=57909
Attila Fidan winebugs@print0.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winebugs@print0.net
--- Comment #2 from Attila Fidan winebugs@print0.net ---
cursor flickers instead of being held
Is this maybe a key repeat issue causing the interact key to be repeatedly pressed/released? Without doing any pointer motion, does holding the interact key flicker the cursor, and only after the configured (from the compositor) repeat delay amount of milliseconds has elapsed?
If you change `delay = max(0, min(3, round(delay / 250.0) - 1));` in wayland_keyboard.c:keyboard_handle_repeat_info to `delay = max(0, min(999, round(delay / 250.0) - 1));` so that the repeat delay is allowed to become very large, and configure your desktop's repeat delay to be several thousand milliseconds, does it then take that amount of time after holding the interact key before the cursor flickers?
https://bugs.winehq.org/show_bug.cgi?id=57909
--- Comment #3 from mactan@edgetransit.dev mactan@edgetransit.dev --- Thank you, I applied that delay change on wine git and increased my desktop's delay to several thousand milliseconds and the cursor was able to behave correctly until the delay time was met and then the flickering begins
10.0 non-staging winewayland with !7352 !7353 !7368 !7457 !7475 applied behaves as we expect it to for me on arch kde plasma 6.3.2-1 mesa 25.1 devel
10.0 staging winewayland with !7352 !7353 !7368 !7457 !7475 applied warped to feet severely with no flicker
10.0 staging winewayland cursor warped to feet severely no flicker 10.0 non-staging winewayland cursor warp no flicker
10.2 staging winewayland cursor warped to feet severely with flicker 10.2 non-staging winewayland cursor warp with flicker
I can work my way through bisect of non-staging wine when I next have the time to identify the flicker
https://bugs.winehq.org/show_bug.cgi?id=57909
--- Comment #4 from mactan@edgetransit.dev mactan@edgetransit.dev --- I believe the bisect I did narrowed the flicker to https://gitlab.winehq.org/wine/wine/-/commit/fab15336250afcfa97e3581ebdf2618...
its predecessor dd790850 does not have the flicker issue
https://bugs.winehq.org/show_bug.cgi?id=57909
--- Comment #5 from Attila Fidan winebugs@print0.net --- Oh, this is probably due to server-side key repeat. In retrospect, it was probably a really bad idea to have that upstreamed with the current state of wayland protocols/compositors if this will break certain kinds of games. Though, if you do not have an IME enabled I am surprised this behaviour exists in kwin. I'm not sure if it can be fixed except for reverting those commits or adding a way to tell drivers when it should enable/disable text input so it doesn't have to always be enabled.
https://bugs.winehq.org/show_bug.cgi?id=57909
--- Comment #6 from mactan@edgetransit.dev mactan@edgetransit.dev --- Thanks this does indeed appear to be a conflict with IME, I toggled off the virtual keyboard in system settings and the cursor stays constant in desired position instead of being affected by key repeat
-
WineHQ Bugzilla