This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• win10-v1709 patch (11955.patch, text/plain, 2018-05-01 07:21:44 +0000, 3945 bytes)
• revert r3931 changes (11955.patch, text/plain, 2018-05-03 06:10:03 +0000, 4076 bytes)
• testcase for still broken warping (warptest.c, text/x-csrc, 2018-05-06 00:55:33 +0000, 2379 bytes)

Reported in version: HG 2.0
Reported for operating system, platform: Windows 10, All

Comments on the original bug report:

On 2018-05-01 07:21:44 +0000, Ozkan Sezer wrote:

Created attachment 3233
win10-v1709 patch

Windows 10 v1803 update seems to have fixed the jumping mouse bug
(see bug # 3931.) So restrict the workaround added in c70cf178aacb
to windows 10 v1709 only.

On 2018-05-01 21:25:06 +0000, Daniel Gibson wrote:

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?

On 2018-05-02 05:23:54 +0000, Ozkan Sezer wrote:

(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.

On 2018-05-02 16:54:25 +0000, Ryan C. Gordon wrote:

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.

On 2018-05-02 17:08:59 +0000, Daniel Gibson wrote:

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..)

On 2018-05-02 17:12:52 +0000, Ozkan Sezer wrote:

(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.

On 2018-05-03 06:10:03 +0000, Ozkan Sezer wrote:

Created attachment 3235
revert r3931 changes

Attached a patch that simply reverts the workaround.

On 2018-05-05 17:28:19 +0000, Sam Lantinga wrote:

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

On 2018-05-06 00:55:33 +0000, Daniel Gibson wrote:

Created attachment 3240
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

On 2018-05-06 00:56:34 +0000, Daniel Gibson wrote:

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

On 2018-05-08 03:10:39 +0000, Sam Lantinga wrote:

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