Erroneous relative mouse input injected when alt tabbing

[expikr]

Observed in CS2, reproduced in a modified version of WoodenEye 008.

Not sure what is the root cause of this, but when alt tabbing SDL seems to inject a large sum of relative motion from mouse id 0, resulting in you ending up aiming at the floor or turning horizontally 90 degrees after alt tabbing.

[expikr]

This seems to be related to the SDL internal cursor position moving around in relative mode, where alt tabbing out issues a warp to move the cursor to the center of the screen. You can tell by being able to manipulate the internal cursor position in relative mode to alter the direction of the erroneous jump in CS2.

warp.mp4

[expikr]

So I think this is because SDL always continues to update the internal mouse position based on WM_MOUSEMOVE events when it loses focus, causing the actual OS cursor position to override the internal mouse position and consequently SDL will send a mouse motion event corresponding to that change.

I’m thinking, maybe when SDL performs any sort of warping, whether on the internal position or physical cursor position, the corresponding event pushed into the queue should have deltas of zero and only set the x and y position. This would make much more sense since applications typically use relative mode only for relative motion and don’t care about SDL’s internal position, and those who do care about it would be monitoring the absolute coordinate for change anyways rather than relying on the event’s delta.

[Slartibarty]

Just a heads up, this may be a regression that was introduced recently because I've been running my game on a 6+ month old version of SDL3 for a long time, and only after updating a few weeks ago did this start happening to me, it might be worth tracking down the original commit that caused this before merging the PR.

[slouken]

Just a heads up, this may be a regression that was introduced recently because I've been running my game on a 6+ month old version of SDL3 for a long time, and only after updating a few weeks ago did this start happening to me, it might be worth tracking down the original commit that caused this before merging the PR.

Can you git bisect it?

[expikr]

@Slartibarty could it be this one?

57f9c6f#diff-5b3b28c770d13cfbb9626d73d0721a6d82d30f8c8dcdf7cb326a72d98c8da4ffR361

If so, then it's probably caused by the WM_MOUSEMOVE case only filtering whether raw mouse is enabled in the SDL global state, rather than whether or not the window actually intends to receive them.

In any case, the PR fixes the root cause of relative mode being being unable to distinguish between warp and move events.

@slouken I think SDL_PrivateSendMouseMotion is becoming quite the rat's nest due to being responsible for coupling so many different states together.

[Slartibarty]

@Slartibarty could it be this one?

Yep that's it, reverted back to the commit before this one and it's fine again.