sway 1.5 sends spurious pointer motion events to mpv

[Dudemanguy]

Description:

Sorry I only noticed just now (shows you how much I pay attention to the cursor). I think sway is sending spurious pointer motion events which confuses mpv (and maybe some other applications). I bisected the change to specifically to this commit: 6ea4539.

Debug Logs:

Log with 6ea4539 applied
Log with 6ea4539 reverted

Reproduction

Play a video with mpv (non-fullscreen), make sure that your mouse cursor is in the mpv window when it launches, wait for the cursor to autohide, then go to fullscreen.

Expected Result

The cursor stays hidden.

Actual Result.

The cursor appears on the screen.

I'm not sure exactly why this is happening, but that commit causes sway to send a pointer motion event when mpv goes in/out of fullscreen (regardless of the mouse moving or not; which causes the cursor to appear). From the wayland spec:

<description summary="pointer motion event">
  Notification of pointer location change. The arguments
  surface_x and surface_y are the location relative to the
  focused surface.
</description>

Since the pointer's location isn't changing, I wouldn't expect to receive this event here so I don't think the client should add extra code to handle this case (a motion event with no change in position).

[Dudemanguy]

Updated the issue to hopefully be more clear on what's going on here.

[Xyene]

Well, https://github.com/swaywm/sway/commit/6ea45395c70939a6d855736cabfe75ad9cf4a0ae has two parts, one where it rebases the cursor when its constraint changes, and one where it sends a motion event post-rebase. The first part isn't the problem, since I can't see any constraints being created in your log.

That leaves the second part. wlroots has code to not send duplicate motion events, but the check is performed in surface-local coordinates. When the mpv surface is resized, we (correctly) rebase the cursor, but the surface-local coordinates of the cursor have changed (the surface has gotten bigger), so we send a motion event even though the cursor hasn't _technically_ moved.

I'm not sure this is a bug though, and it sounds like the correct behavior to me. Consider an application that hides the cursor and draws its own (e.g. a game), and a Sway where we don't rebase the cursor. As a concrete example, in the game below the real cursor is hidden and a software cursor is drawn in the bottom right corner where the last motion event received was:

On making the game fullscreen, we want the cursor to remain in the same position:

If we don't rebase, the game will think the cursor is in the last surface-local location, which doesn't match the actual mouse location:

This will cause a jump to the correct location the next time the cursor is moved, which is not ideal.

[Dudemanguy]

If I understand the Osu example correctly, if you rebase the cursor but don't send the motion pointer event, the cursor location would still appear to change because surface local coordinates have changed correct?

[Xyene]

"Rebasing" just means to "make the cursor consistent with what's underneath it". Rebasing in this case means sending that motion event.

...if you rebase the cursor but don't send the motion pointer event, the cursor location would still appear to change because surface local coordinates have changed correct?

It'll look like my third screenshot, where the _real_ mouse is still in the bottom-right corner, but the cursor is (incorrectly) drawn under the osu logo.

[Dudemanguy]

Okay, thanks for the help. Then this should be fixed on our end.