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.

Created attachment 1928 [details]
Set SDL_TOUCH_MOUSEID as button.which value for mouse events generated by touch events

I encountered this problem and the changes in the attached patch fixed it for me.

Thank you! Can this be committed to the main branch?

Thanks for the info on this!  I'll plan on taking a look at this within the next week or so.

I pushed out a modified version of Tamas' patch, via changeset https://hg.libsdl.org/SDL/rev/bea2e725e29a .  All mouse events, including SDL_MOUSEBUTTONDOWN, SDL_MOUSEBUTTONUP, and SDL_MOUSEMOTION, will now set the 'which' field to SDL_TOUCH_MOUSEID, rather than 0 (which was getting set for both real mouse events, and virtual/touch mouse events).  Strictly-speaking, this bug appears to be fixed.

I did stop short of attaching real mice's WinRT 'PointerId', which the attached patch also did, and didn't seem necessary in order to fix the described bug.  Is this needed by anyone (listening to this) for anything particular?

This is not a WinRT exclusive problem. The problem still persists on a normal win32 desktop application.

Created attachment 1975 [details]
Potential fix for bug 2726, on Win32

Comment on attachment 1975 [details]
Potential fix for bug 2726, on Win32

I attached a potential patch.  Ignore this for now, please.  I found an additional bug in it, just after attaching it: it doesn't work with mouse-motion events.  I'll try updating this patch, shortly.

Created attachment 1978 [details]
Partial, Win32-specific fix for Bug 2726

This is a partial, Win32-specific fix for Bug 2726.  It makes sure SDL_TOUCH_MOUSEID gets applied for 'mouse' events coming from a touch device, but only if relative-mouse-mode is OFF.  It does not cover cases when relative-mouse-mode is ON, as Microsoft does not document whether or not these events (which come from WM_INPUT messages) can be discerned as touch-specific or not.

Hi Sam,

It looks like this bug is still occurring on Win32 (it has previously been fixed, but only for WinRT).  I've attempted to write a Win32-specific fix, a patch for which is attached to this case, however I'm not nearly as familiar with SDL's Win32 code, and as such, have held back on pushing it out to hg.libsdl.org.

The patch seems to fix this for any 'mouse' event that occurs with relative-mouse-mode being off.  It does not work when relative-mouse-mode is on.  I was able to find documentation on MSDN for detecting touch-input via WM_*BUTTON* and WM_MOUSEMOVE [1][2], but not for WM_INPUT.  Unofficially, it might be possible to detect touch in WM_INPUT events, something that has been described at least one non-Microsoft blog post [3], however the patch I've attached limits things to what's described in official, MSDN documentation.

If you like, I'd be happy to push this patch out to HG, but wanted to run it by you first.


[1] MSDN, "System Events and Mouse Messages", "Distinguishing Pen Input from Mouse and Touch": http://msdn.microsoft.com/en-us/library/windows/desktop/ms703320(v=vs.85).aspx

[2] MSDN, "Troubleshooting Applications" (with regards to Touch Input): http://msdn.microsoft.com/en-us/library/windows/desktop/dd693088(v=vs.85).aspx

[3] Jonathan Blow, "WM_TOUCH is totally bananas.": http://the-witness.net/news/2012/10/wm_touch-is-totally-bananas/

Sam, do we want to deal with the win32 patch for 2.0.4, or let it ride for now?

--ryan.

Gonna put this on the 2.0.4 list so we don't forget it.

--ryan.

Patch looks good, we can punt on this for relative motion, for now. Thanks!
https://hg.libsdl.org/SDL/rev/6ab4d6f34afb