Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows 8 touch screen events causing SDL_MOUSEBUTTONDOWN with no SDL_TOUCH_MOUSEID #1641

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.0
Reported for operating system, platform: Windows 8, x86_64

Comments on the original bug report:

On 2014-09-10 03:21:07 +0000, Diego wrote:

After an SDL_FINGERDOWN, Windows 8 touch screen devices are causing an extra SDL_MOUSEBUTTONDOWN around when SDL_FINGERUP occurs and also around the first SDL_FINGERMOTION occurrence. These SDL_MOUSEBUTTONDOWN events are not labeled SDL_TOUCH_MOUSEID.

This can also be witnessed using the Windows Visual Studio simulator.

On 2014-11-09 14:39:30 +0000, Tamas Hamor wrote:

Created attachment 1928
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.

On 2014-11-18 14:06:57 +0000, Diego wrote:

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

On 2014-11-22 21:55:45 +0000, David Ludwig wrote:

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

On 2014-11-23 02:37:41 +0000, David Ludwig wrote:

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?

On 2014-12-12 18:28:27 +0000, Diego wrote:

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

On 2014-12-15 23:58:52 +0000, David Ludwig wrote:

Created attachment 1975
Potential fix for bug 2726, on Win32

On 2014-12-16 00:14:44 +0000, David Ludwig wrote:

Comment on attachment 1975
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.

On 2014-12-20 16:51:13 +0000, David Ludwig wrote:

Created attachment 1978
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.

On 2014-12-20 17:06:56 +0000, David Ludwig wrote:

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/

On 2015-02-19 03:53:46 +0000, Ryan C. Gordon wrote:

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

--ryan.

On 2015-04-23 00:34:25 +0000, Ryan C. Gordon wrote:

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

--ryan.

On 2015-05-28 16:55:58 +0000, Sam Lantinga wrote:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant