tree fc040f14f3e3b9ab3f465a49f96000c5e2e1a0ab
parent 40f5b815531d8efde6e84e784492fb82c875bbf2
author Sam Lantinga <slouken@libsdl.org> 1525749012 -0700
committer Sam Lantinga <slouken@libsdl.org> 1525749012 -0700

Reverted change for bug 4152 - restrict the win10 mouse bug workaround to win10 v1709 only

Daniel Gibson

Sorry, but it seems like Microsoft didn't fix the issue properly.

I just updated my Win10 machine, it now is Version 1803, Build 17134.1

I tested with SDL2 2.0.7 (my workaround was released with 2.0.8) and still got
lots of events that directly undid the prior "real" events - just like before.
(See simple testcase in attachement)
By default it sets SDL_HINT_MOUSE_RELATIVE_MODE_WARP - which triggered (and on my machine still triggers) the buggy behavior. You can start it with -raw, then it'll not set that hint and the events will be as expected.
The easiest way to see the difference is looking at the window title, which shows accumulated X and Y values: If you just move your mouse to the right, in -raw mode the number just increases. In non-raw mode (using mouse warping) it stays around 0.

I also had a WinAPI-only testcase: https://gist.github.com/DanielGibson/b5b033c67b9137f0280af9fc53352c68
It just calls SetCursorPos(320,240); on each WM_MOUSEMOVE event, and it also
logs all those events to a mouseevents.log textfile.
This log indeed looks a bit different since the latest Win10 update: It seems like all those events with x=320 y=240 do arrive - but only after I stopped moving the mouse - even though the cursor seems to be moved back every frame (or so).
So moving the mouse to the right gives X coordinates like
330, 325, 333, 340, 330, ...
and then when stopping movement I get lots of events with X coordinate 320