Pointer warp issue in World of Warcraft after commit 6ea4539

[Morgus]

The behaviour change with pointer warping in commit 6ea4539 causes issues with World of Warcraft's use of warp. Now, the game is already a little odd with pointer warp and at the moment requires an Xwayland patch to function as it does in X11: https://gitlab.freedesktop.org/xorg/xserver/-/issues/734 . In the game, holding the right mouse button hides and warps the cursor to center and starts rotating the camera. Releasing right mouse button shows the cursor, warps it back to start and disables camera rotation. With the change in commit 6ea4539 the camera is jumping when releasing the right mouse button. My assumption is that because the warp back now causes an event, it is still taken as camera movement.

I'm a little unsure where this issue should be directed to. Under X11 everything works so the issue is in wine -> Xwayland -> sway. The breaking change is in sway, but it seems the change was made to conform to spec. The game itself is non-free and as this has been the behaviour for decades it is unlikely to change. The example program in Xwayland issue 734 shows the behaviour when the motion event print is uncommented. The position change on the first 2 motion events after button release is large.

• Sway Version: sway version 1.4-6ea45395 (May 31 2020, branch 'makepkg')
• Debug Log: https://gist.github.com/Morgus/a9105cae3f005245dfbefedfb12452ea

[Xyene]

Thanks for reporting this.

I'm assuming what's going on under the hood is Xwayland sets up a zwp_locked_pointer_v1 on RMB press, with set_cursor_position_hint. On RMB release, the locked pointer is destroyed and Sway warps the cursor to its original position (set via set_cursor_position_hint). Sway generates a motion event for this warp.

I don't think this actually contradicts the spec as written, which says:

      When unlocking, the compositor may warp the cursor position to the set
      cursor position hint. If it does, it will not result in any relative
      motion events emitted via wp_relative_pointer.

Sway doesn't send a wp_relative_pointer.motion event for this warp. It sends a wl_pointer.motion event.

I think the spirit of that paragraph in the spec is to prevent the sort of jumps you're seeing, though, so it seems reasonable to me that we shouldn't emit any motion events in that case — not just relative ones. I'll see if we can get some extra clarification on what a compositor should do in this case.

[emersion]

@Xyene Can you create a wayland-protocols issue about this?

[Xyene]

@emersion done: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/20

[fluix-dev]

I believe I have a related issue in Team Fortress 2. The cursor is normally locked to the center of the screen (it's a first person game) but occasionally it will jump down, pointing my view directly to the ground. After reverting 6ea4539 the issue seemed to go away.

[Xyene]

@Morgus could you give #5431 a try and see if it fixes your issue? I don't have any applications with which to test it myself, but I think it should work.

[nivekuil]

@Morgus could you give #5431 a try and see if it fixes your issue? I don't have any applications with which to test it myself, but I think it should work.

This patch works great for me.

[Xyene]

Thanks for testing @nivekuil!

[nivekuil]

Thanks for testing @nivekuil!

So after some more days of testing, I've occasionally seen the behavior repeat. It's much less frequent than before but I think the patch must be missing some fundamental behavior. It's kind of tricky to reproduce: the most reliable way to reproduce has been to switch between workspaces with captured-mouse games and wave the mouse around while clicking. When the cursor does go into the "warping" state, switching to another window and back doesn't fix it, while switching to another window and then clicking does.

[Xyene]

To narrow things down, if you comment out just this line, does the issue still occur?

When the cursor does go into the "warping" state

What do you mean by "warping state"? I think our terminology doesn't match here, because I don't understand what you mean in that sentence :)

The two cases where Sway post-6ea4539 emits a motion event where it didn't before are:

• if the game changed its constraint region and we had to warp the cursor as a result (if the cursor was in the overlap between the old region and the new region, we don't do anything)
• if a new constraint was created, we warp again under the same conditions

If the game lost focus and decided to create a new constraint upon regaining focus and this resulted in a warp, we should be sending a motion event there. You should be able to verify what the game is doing by inspecting Sway logs; there'll be messages about new locked pointers in there.

[Limero]

Is this the same issue as #4632?