This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.5
Reported for operating system, platform: macOS 10.12, x86

Comments on the original bug report:

On 2016-12-31 04:00:10 +0000, Intellectual Kitty wrote:

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.

On 2016-12-31 21:33:07 +0000, Alex Szpakowski wrote:

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.

On 2016-12-31 21:35:34 +0000, Alex Szpakowski wrote:

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

On 2017-08-11 20:27:07 +0000, Alex Szpakowski wrote:

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.

On 2018-08-06 21:20:21 +0000, Ryan C. Gordon wrote:

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.