Bug 514628

Summary: Mouse cursor fails to get re-centered by Hytale when fullscreen
Product: [Plasma] kwin Reporter: vnndvp
Component: inputAssignee: KWin default assignee <kwin-bugs-null>
Status: ASSIGNED ---    
Severity: normal CC: duha.bugs, kdedev, kostadinshishmanov, vnndvp, xaver.hugl
Priority: NOR    
Version First Reported In: 6.5.5   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=514685
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: log from KWIN_DEBUG=1
WAYLAND_DEBUG log

Description vnndvp 2026-01-15 02:28:38 UTC
SUMMARY
On Hytale (native linux, Wayland, flatpak), the cursor will fail to get centered when using menus with varying consistency. It happens only when the game is fullscreen and not in Windowed mode. Disabling compositing for the client with Kwin rules didn't help.

STEPS TO REPRODUCE
1. Open a menu while the game is fullscreen
2. Move the cursor and close the menu
3. May have to be repeated a few times.

OBSERVED RESULT
Mouse cursor didn't get centered.

EXPECTED RESULT
For the mouse cursor to be centered.

SOFTWARE/OS VERSIONS
Kernel Version: 6.18.5-arch1-1 
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.22.0
Qt Version: 6.10.1

ADDITIONAL INFORMATION
I'm using a Radeon 7800xt with Mesa. I repeated the steps above on Gnome, and the mouse got consistently centered, fullscreen or not.
Comment 1 vnndvp 2026-01-15 05:13:53 UTC
I went a bit further. I could not reproduce this on my Intel/Nvidia laptop running Arch, with the same KDE version. I reproduced this bug on my AMD PC on CachyOS.
Comment 2 vnndvp 2026-01-15 15:12:25 UTC
Further update: Enabling adaptive sync or forcing tearing on the client through Kwin rules fixed the cursor centering. Unsure if centering the cursor is supposed to break if adaptive sync or tearing are disabled, so I'll leave the bug report up.
Comment 3 Zamundaaa 2026-01-19 15:06:28 UTC
*** Bug 514685 has been marked as a duplicate of this bug. ***
Comment 4 Zamundaaa 2026-01-19 15:07:59 UTC
Please run the game with WAYLAND_DEBUG=1 set, reproduce the issue, close it (ideally with a keyboard shortcut) and attach the output of that here. You can grep for "pointer" to reduce the noise and irrelevant output
Comment 5 kostadinshishmanov 2026-01-19 15:45:03 UTC
Created attachment 188686 [details]
log from KWIN_DEBUG=1

I think the relevant stuff starts after the [2115172.667] timestamp.
Comment 6 Zamundaaa 2026-01-19 16:36:24 UTC
It looks like a bug in the game to me. Here it locks the pointer, and leaves it locked for some time
> [2128517.570] {Default Queue}  -> zwp_pointer_constraints_v1#14.lock_pointer(new id zwp_locked_pointer_v1#69, wl_surface#46, wl_pointer#41, nil, 2)
> [2128517.573] {Default Queue}  -> wl_pointer#41.set_cursor(34341, nil, 0, 0)
> [2128523.645] {Default Queue} zwp_locked_pointer_v1#69.locked()

but it never sets the position hint on that, and instead does
> [2129776.851] {Default Queue}  -> zwp_locked_pointer_v1#69.destroy()
> [2129776.856] {Default Queue}  -> zwp_pointer_constraints_v1#14.lock_pointer(new id zwp_locked_pointer_v1#68, wl_surface#46, wl_pointer#41, nil, 2)
> [2129776.859] {Default Queue}  -> zwp_locked_pointer_v1#68.set_cursor_position_hint(3153.00000000, 565.00000000)
> [2129776.862] {Default Queue}  -> zwp_locked_pointer_v1#68.destroy()
> [2129776.867] {Default Queue}  -> wl_pointer#41.set_cursor(34341, wl_surface#57, 0, 0)
> [2129776.873] {Default Queue}  -> zwp_pointer_constraints_v1#14.lock_pointer(new id zwp_locked_pointer_v1#70, wl_surface#46, wl_pointer#41, nil, 2)
> [2129776.875] {Default Queue}  -> zwp_locked_pointer_v1#70.set_cursor_position_hint(960.00000000, 540.00000000)
> [2129776.876] {Default Queue}  -> zwp_locked_pointer_v1#70.destroy()

which is to say, instead of just setting the position hint before unlocking, it
- unlocks the pointer
- locks it again
- sets the position hint to a position that's completely out of the window
- unlocks the pointer again
- locks the pointer again
- sets the position hint to what would be the center of a 1080p window
- unlocks the pointer again

There's two issues with this:
1. setting the position outside of the window is wrong (obviously). We can add checks in KWin to prevent this from causing issues though
2. lock + set position + unlock without waiting for the pointer to be actually locked is not something you can expect to work reliably

If the game wants to warp the cursor, it should use the pointer-warp-v1 protocol, but really it should set the correct position hint before unlocking the pointer in the first place.
Comment 7 Bug Janitor Service 2026-01-19 16:43:29 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8674
Comment 8 vnndvp 2026-01-19 19:30:30 UTC
Created attachment 188695 [details]
WAYLAND_DEBUG log

Uploading my log. Menu was opened ~3 times. On the last open, the cursor did manage to center itself.