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

Add support for joysticks with integrated touchpads #1655

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Add support for joysticks with integrated touchpads #1655

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments


Copy link

@SDLBugzilla SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.1
Reported for operating system, platform: All, x86_64

Comments on the original bug report:

On 2014-09-27 18:35:42 +0000, Frank wrote:

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.

On 2014-09-27 18:37:05 +0000, Frank wrote:

Created attachment 1884
Add touchpad support via the existing touch system

Add patch # 1

On 2014-09-27 18:38:27 +0000, Frank wrote:

Created attachment 1885
Add touchpad support with new events

On 2014-09-27 21:23:20 +0000, Frank wrote:

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

On 2014-10-16 11:50:03 +0000, Gabriel Jacobo wrote:

*** Bug 2741 has been marked as a duplicate of this bug. ***

On 2015-09-15 21:33:23 +0000, Alex Szpakowski wrote:

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.

On 2015-09-15 21:35:26 +0000, Alex Szpakowski wrote:

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.

@SDLBugzilla SDLBugzilla added the enhancement label Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant