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 2742 - Add support for joysticks with integrated touchpads
Summary: Add support for joysticks with integrated touchpads
Status: ASSIGNED
Alias: None
Product: SDL
Classification: Unclassified
Component: joystick (show other bugs)
Version: HG 2.1
Hardware: x86_64 All
: P2 enhancement
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
: 2741 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-09-27 18:35 UTC by Frank
Modified: 2017-08-14 05:00 UTC (History)
2 users (show)

See Also:

Attachments
Add touchpad support via the existing touch system (15.45 KB, patch)
2014-09-27 18:37 UTC, Frank 		Details | Diff
Add touchpad support with new events (21.57 KB, patch)
2014-09-27 18:38 UTC, Frank 		Details | Diff
Add touchpad support with new events v2 (21.56 KB, patch)
2014-09-27 21:23 UTC, Frank 		Details | Diff
Show Obsolete (1) View All 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 Frank 2014-09-27 18:35:42 UTC 
These patches add support for joysticks with integrated trackpads such as the DualShock 4.  Two different forms of implementation are included here: one that uses the existing multitouch system and another that implements joystick touch events separately from others.  There are advantages and drawbacks to each approach as outlined below:

In the version that uses the existing touchpad system the function SDL_JoystickGetTouchDevice() was added to the joystick API to retrieve the SDL_TouchID of the associated touchpad.  Touch events are sent with the existing SDL_FINGER* events and it's up to the application to use the touch device id to determine from which device the touch originated.  This approach uses less code overall and allows for the use of the gesture system on controller touchpads, but it also means that applications that just blindly parse touch events without checking which device they came from may have undesired behavior.

The second approach adds SDL_JoystickNumTouchFingers() and SDL_GetTouchFinger() to the joystick API and sends new SDL_JOYTOUCH* events via a new SDL_JoyTouchEvent struct.  This adds a bit more code but it makes sure that events from joystick touchpads and other devices like touchscreens are explicitly separated.  Applications that don't expect multiple touchpads won't have issues since support for joystick touch events must be handled separately.

In both cases the testjoystick application was updated to demonstrate the new functionality.
Comment 1 Frank 2014-09-27 18:37:05 UTC 
Created attachment 1884 [details]
Add touchpad support via the existing touch system

Add patch #1
Comment 2 Frank 2014-09-27 18:38:27 UTC 
Created attachment 1885 [details]
Add touchpad support with new events
Comment 3 Frank 2014-09-27 21:23:20 UTC 
Created attachment 1886 [details]
Add touchpad support with new events v2

Fixed a parameter name in the second patch and added a check to make sure a finger index isn't negative.
Comment 4 Gabriel Jacobo 2014-10-16 11:50:03 UTC 
*** Bug 2741 has been marked as a duplicate of this bug. ***
Comment 5 Alex Szpakowski 2015-09-15 21:33:23 UTC 
The new Apple TV's remote can act like a joystick and includes a touch surface (although SDL doesn't support tvOS yet.)

tvOS and iOS 9.1 have the ability to tell you where each touch press originated (a 'direct touch' - i.e. a touchscreen touch, an 'indirect touch' - i.e. from the remote or a joystick, and a stylus touch.)

It makes sense to me to adopt version #1 of your proposal, with the addition of a new SDL_Touch API that identifies the type of touch/finger press, if possible.
Comment 6 Alex Szpakowski 2015-09-15 21:35:26 UTC 
It's also worth mentioning that SDL already reports non-screen touches on platforms like OS X (when the trackpad is used), and there isn't a good way to detect the difference between that and a touchscreen touch currently, so having a way to identify the type of touch press would be a benefit even without support for the DS4 touch surface.