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.

Bug 4713

Summary: [PATCH] Spurious mouse events from touch devices in relative mode
Product: SDL Reporter: Cameron Gutman <cameron.gutman>
Component: eventsAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: icculus, sezeroz, superfury
Version: 2.0.10Keywords: target-2.0.10
Hardware: x86   
OS: Windows 10   
Attachments: Patch to ignore synthetic mouse events for touchscreens

Description Cameron Gutman 2019-07-07 18:27:56 UTC 
Windows generates synthetic WM_INPUT mouse events for touchscreens for backwards compatibility. We reported those as regular mouse events, so it led to the double reporting where some events would sneak in without SDL_TOUCH_MOUSEID via WM_INPUT, in addition to those we received through the WM_TOUCH codepath.

Example of spurious which=0 mouse events:
INFO: SDL EVENT: SDL_MOUSEBUTTONDOWN (timestamp=41099 windowid=2 which=4294967295 button=1 state=pressed clicks=1 x=0 y=0)
INFO: SDL EVENT: SDL_FINGERDOWN (timestamp=41099 touchid=74843435 fingerid=572 x=0.823958 y=0.509259 dx=0 dy=0 pressure=1.000000)
INFO: SDL EVENT: SDL_MOUSEBUTTONUP (timestamp=41187 windowid=2 which=4294967295 button=1 state=released clicks=1 x=1 y=0)
INFO: SDL EVENT: SDL_FINGERUP (timestamp=41187 touchid=74843435 fingerid=572 x=0.824479 y=0.503703 dx=0 dy=0 pressure=1.000000)
INFO: SDL EVENT: SDL_MOUSEBUTTONDOWN (timestamp=41190 windowid=2 which=0 button=1 state=pressed clicks=2 x=1 y=0)
INFO: SDL EVENT: SDL_MOUSEBUTTONUP (timestamp=41193 windowid=2 which=0 button=1 state=released clicks=2 x=0 y=0)
Comment 1 Cameron Gutman 2019-07-07 18:28:44 UTC 
Created attachment 3869 [details]
Patch to ignore synthetic mouse events for touchscreens

This patch uses the lower bits of GetMessageExtraInfo() as mentioned here https://docs.microsoft.com/nl-nl/windows/win32/tablet/system-events-and-mouse-messages to filter these touches by checking the touch bit (0x80). I don't think this will work for pens (spurious events will still get through, same as today), but it's still a major improvement for most touch-enabled PCs which lack pen support anyway.

Tested on a touch-enabled Win10 1903 machine.
Comment 2 Ryan C. Gordon 2019-07-08 18:29:15 UTC 
Looking at this.

--ryan.
Comment 3 Ryan C. Gordon 2019-07-08 23:08:49 UTC 
Okay, I think this patch is reasonable. It's now https://hg.libsdl.org/SDL/rev/92e72926b7f5, thanks!

--ryan.
Comment 4 Sam Lantinga 2019-07-08 23:26:38 UTC 
Does this have the same problem as on Mac, where the OS synthesized mouse events are better than the ones synthesized in SDL?
Comment 5 Cameron Gutman 2019-07-09 06:08:23 UTC 
No, SDL's synthesized mouse events look fine. It's the fact that we were getting 2 sets of synthesized mouse events that caused issues. The ones from SDL get properly marked as SDL_TOUCH_MOUSEID, but the OS synthesized ones didn't and looked like real mouse input.

If you're handling both touch and mouse events, it looked to your app like someone was moving the mouse and touching the screen at the same time.
Comment 6 Sam Lantinga 2019-07-09 06:13:14 UTC 
Okay, thanks!
Comment 7 Ryan C. Gordon 2019-07-09 06:17:04 UTC 
(In reply to Sam Lantinga from comment #6)
> Okay, thanks!

Also, this was specifically for RAWINPUT: when SDL_SetRelativeMouseMode() was enabled. The non-relative codepath already filtered these out.

--ryan.
Comment 8 Ozkan Sezer 2019-07-09 06:22:35 UTC 
According to MSDN, the GetMessageExtraInfo() check added here is valid
only on Vista and newer, but not XP:
https://docs.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages
Also see: https://bugzilla.libsdl.org/show_bug.cgi?id=4704#c45
Comment 9 Ryan C. Gordon 2019-07-09 06:30:17 UTC 
(In reply to Ozkan Sezer from comment #8)
> According to MSDN, the GetMessageExtraInfo() check added here is valid
> only on Vista and newer, but not XP:

I'm assuming it's always 0 on XP (which is to say: it leaks through, but I can't really distinguish further on XP in any case).

--ryan.
Comment 10 superfury 2019-07-12 20:46:06 UTC 
My bugcheck will probably work on XP as well, since it also checks for the low 7 bits(which are non-zero for touch and zero for mouse), as well as counting the special ID that's in the other bytes of the returned value(other than bits 0-7) as touch input(as is documented), which, according to Microsoft identifies "Tablet PC pen or touch screen" input.

So that ID (0xFF515700) identifies touch input when it's in the upper bytes, and when bit 7 is set(on Vista or newer only, otherwise ignore) and bits 0-7 are set(indicating non-mouse input) also indicates touch input when true.

My code (at bug https://bugzilla.libsdl.org/show_bug.cgi?id=4704 (bug 4704) ) takes that into account, also fixing the issue with touch events that somehow cause mouse motion events when they shouldn't(which messed up things as well).