wlserver: keep cursor position in sync when constraint rejects motion#2100
Open
Krakty wants to merge 1 commit intoValveSoftware:masterfrom
Open
wlserver: keep cursor position in sync when constraint rejects motion#2100Krakty wants to merge 1 commit intoValveSoftware:masterfrom
Krakty wants to merge 1 commit intoValveSoftware:masterfrom
Conversation
When --force-grab-cursor is active and the inner client has a locked pointer constraint, wlserver_apply_constraint() rejects the motion but the cursor position isn't updated. This causes the absolute position to go stale at the lock point. When the constraint is later released (or on the next accepted motion), the cursor jumps from its stale position, which shows up as the camera snapping to a fixed angle in games that use both relative motion and absolute position via XWayland. Fix this by updating cursor position, notifying the seat, and clamping even when the constraint blocks the motion. This keeps absolute coordinates consistent with the relative deltas that were already forwarded by wlserver_perform_rel_pointer_motion().
This was referenced Mar 4, 2026
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When
--force-grab-cursoris active and the inner XWayland client sets a locked pointer constraint,wlserver_apply_constraint()rejects the motion and returns early. The problem is that the early return skips updatingmouse_surface_cursorx/cursory, even though relative motion was already forwarded bywlserver_perform_rel_pointer_motion()just above.This means the absolute cursor position gets stuck at wherever it was when the constraint kicked in. Games that use both relative motion (camera/mouselook) and absolute position (UI clicks) via XWayland see the camera snap to a fixed angle because the stale absolute coords get used on the next accepted motion or button event.
I hit this running EverQuest under Wine in multiple concurrent gamescope instances (6 clients, each in its own gamescope with
--force-grab-cursor). A single instance worked fine — the issue only appeared with multiple instances. EQ uses DirectInput for mouselook (relative) and XWayland absolute positioning for UI interaction, so the stale coordinates caused the camera to fight the player on every mouselook release.The fix keeps the cursor position tracking in sync even when the constraint blocks. Only runs under
g_bForceRelativeMouseso normal constraint behavior is untouched.Related issues: #1748 #1428 #1470