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 3542 - SDL_TOUCH_MOUSEID not reported as mouse ID for MacBook Pro trackpad
Summary: SDL_TOUCH_MOUSEID not reported as mouse ID for MacBook Pro trackpad
Status: RESOLVED ABANDONED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: 2.0.5
Hardware: x86 macOS 10.12
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-31 04:00 UTC by Intellectual Kitty
Modified: 2018-08-06 21:20 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Intellectual Kitty 2016-12-31 04:00:10 UTC 
On my MacBook Pro, the trackpad generates mouse events, finger events, and gesture events.  Unfortunately, despite what the online documentation states (for example https://wiki.libsdl.org/SDL_MouseButtonEvent), specifically that "[the which field] may be SDL_TOUCH_MOUSEID, for events that were generated by a touch input device, and not a real mouse. You might want to ignore such events, if your application already handles SDL_TouchFingerEvent," the which field in the mouse events returns 0 rather than SDL_TOUCH_MOUSEID.  This makes it impossible to separate mouse events and finger events.

This may be related to bug #2931, except that the bug that I am filing is basically all-encompassing.  A review of the SDL project in Xcode finds that SDL_TOUCH_MOUSEID is not used anywhere.  Specifically, it is defined in SDL_touch.h [#define SDL_TOUCH_MOUSEID ((Uint32)-1)] and it is listed in three comments in SDL_events.h [Uint32 which;       /**< The mouse instance id, or SDL_TOUCH_MOUSEID */] for the mouse event structures, but it is otherwise unused and unimplemented.  Also, a further review of the macOS code indicates that 0 is simply hardcoded as the mouse ID for mouse events.
Comment 1 Alex Szpakowski 2016-12-31 21:33:07 UTC 
The trackpad in macOS is a little tricky. It acts as both a real mouse and an indirect (non-screen) touch surface, and the fact that it's an indirect touch surface means the reported mouse movements and positions can actually have little to do with the reported touch positions and movements.

Code that makes use of SDL_TOUCH_MOUSEID will often choose to ignore mouse events in favour of touch events because the touch events directly generated the mouse events (with a 1:1 mapping between touch positions and mouse positions) but this is not the case for the trackpad, and SDL provides no API to determine if a touch device is a direct (touchscreen) or indirect surface.

Therefore, simply adding SDL_TOUCH_MOUSEID to trackpad-generated mouse events in macOS may break shipping code and will cause unintuitive behaviour for new code, unless more APIs are added.
Comment 2 Alex Szpakowski 2016-12-31 21:35:34 UTC 
(In reply to Alex Szpakowski from comment #1)
> The trackpad in macOS is a little tricky. It acts as both a real mouse and
> an indirect (non-screen) touch surface, and the fact that it's an indirect
> touch surface means the reported mouse movements and positions can actually
> have little to do with the reported touch positions and movements.

An example of this is if I tap once on the left side of the trackpad, lift my finger up, and tap on the right side. The touch APIs will report a press/release in two positions on opposite ends up the device. The mouse API will report no movement.
Comment 3 Alex Szpakowski 2017-08-11 20:27:07 UTC 
I have a fork of SDL which adds touch device type information (direct versus indirect): https://bitbucket.org/slime73/sdl-experiments/branch/TouchDeviceType

Even with those fork's changes, I still think changing Mac trackpad mouse events to generate SDL_TOUCH_MOUSEID is a bad idea for 2.0.x, since it would break a lot of existing apps that don't handle touch device types.
Comment 4 Ryan C. Gordon 2018-08-06 21:20:21 UTC 
Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.