We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Great that they finally fixed it!

Are you sure that info.dwBuildNumber == 16299 really is the only one affected, i.e. no other buildnumbers between that and the fixed one were released?

(In reply to Daniel Gibson from comment #1)
> Are you sure that info.dwBuildNumber == 16299 really is the only one
> affected, i.e. no other buildnumbers between that and the fixed one were
> released?

No, I am not.  Build 17134 is the released one as v1803, so it is
the only one that matters IMO.

I wonder if it's worthwhile to just pull the workaround out of SDL altogether. People that were hit by the bug were eager upgraders that will eagerly upgrade to the next major Win10 patch just the same, and no one else will see the problem ever. If someone hits it, we can tell them to run a system update to resolve it, and we don't have to have special case code for an increasingly-obsolete revision of the OS.

Just an idea, though.

--ryan.

I already had the same thought.
Especially considering how aggressively MS now enforces updates, it seems unlikely to me that (enough to be worthwhile) people will still run a buggy version of Win10 now or in a few weeks.
So unless you're gonna release SDL2 2.0.9 this week, I think it should be safe enough to dump that workaround.

(Which reminds me, I still haven't tested the fixed Win10 version..)

(In reply to Ryan C. Gordon from comment #3)
> I wonder if it's worthwhile to just pull the workaround out of SDL
> altogether. People that were hit by the bug were eager upgraders that will
> eagerly upgrade to the next major Win10 patch just the same, and no one else
> will see the problem ever. If someone hits it, we can tell them to run a
> system update to resolve it, and we don't have to have special case code for
> an increasingly-obsolete revision of the OS.

I agree with this completely.

Created attachment 3235 [details]
revert r3931 changes

Attached a patch that simply reverts the workaround.

Workaround removed, thanks!
https://hg.libsdl.org/SDL/rev/719dece50dde

Created attachment 3240 [details]
testcase for still broken warping

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

(Reopening this, as the issue isn't fixed for me on Windows and thus the workaround shouldn't be removed from SDL after all)

Change reverted, thanks for the update!
https://hg.libsdl.org/SDL/rev/4cc8aad8d434