Extend SDL_GamepadCapSenseType definitions

[mitchellcairns]

This PR draft expands on #15627 by @ceski-1 to implement more types of capacitive sensing surfaces.

Real world references for the expansion:

• Gamepads such as OculusMeta Quest Touch controllers feature individual sensing on face buttons, finger rest areas, and triggers/bumpers: https://developers.meta.com/horizon/documentation/unreal/unreal-touch-controller/
• An open source gamepad known as the Alpakka controller features a conductive surface area encompassing the entire SEWN button area: https://inputlabs.io/alpakka

Other considerations:

• I have not seen a gamepad featuring a dpad with the capacitive sensing, but I figure it's a better shorthand to deal with the left-hand VR gamepads instead of splitting up SEWN across left/right and making that more messy.

[ceski-1]

I'll share some notes I took, which is pretty close to what you've come up with for additions. Let's start by looking at the whole collection of capacitive touch types. There are probably even more I haven't considered:

Capacitive touch types:

• Thumbs
  • Specific
    • Dpad Up
    • Dpad Down
    • Dpad Left
    • Dpad Right
    • North Face Button
    • South Face Button
    • West Face Button
    • East Face Button
    • Left Thumb Stick
    • Right Thumb Stick
  • General
    • Left Thumb Rest (i.e. a neutral position)
    • Right Thumb Rest
• Index fingers (and possibly middle fingers, depending on grip style)
  • Specific
    • Left Bumper
    • Right Bumper
    • Left Trigger
    • Right Trigger
  • General
    • Left Index Finger Rest
    • Right Index Finger Rest
• Other fingers
  • Specific
    • Left Paddle 1
    • Right Paddle 1
    • Left Paddle 2
    • Right Paddle 2
  • General
    • Left Grip Sense
    • Right Grip Sense

But are all of those needed? If we try to find the right balance of options, the list may collapse to something like this (for example):

• Left Thumb Stick
• Right Thumb Stick
• Left Thumb Rest
• Right Thumb Rest
• Left Index Finger Rest
• Right Index Finger Rest
• Left Grip Sense
• Right Grip Sense

Maybe that's not enough, but it's just an example.

Also, in the future, if enough controllers report more than just a "down" state (some VR controllers), then the event structure could be extended to account for that:

• Touch (event.gcapsense.down, already present)
• Near Touch (event.gcapsense.near)

[mitchellcairns]

I think that the expanded capacitive touch types you've laid out covers all of the major use-cases, and fits in 24 bits.

I think it's worth using the expanded types over the condensed, for the reason that it more accurately represents what gamepads are already implementing today such as the Meta Quest controllers which have individual sensing for each button/trigger. Besides that, it's helpful from a game dev and gamepad configuration perspective to know where a capacitive sensing location is physically located. IE if a gamepad has a grip sensor, and a paddle sensor, a developer or configuration software knowing that there's a distinction rather than having to collapse them into a single state is preferred in my opinion.

I think the only additional suggestion I'd have is to have a few MISC labels as well, to cover odd or weird use-cases that may not fit the rest.

[ceski-1]

I don't mind the whole set. Maybe there are some caveats I haven't considered, but nothing is immediately sticking out to me. I'm not an expert in this, but hopefully my list helps with brainstorming.

[mitchellcairns]

I'll work on extending what you've laid out; thanks for helping to push this forward so quickly!

[slouken]

How many controllers provide information for each of these, and how many applications care about contact vs press?

[mitchellcairns]

How many controllers provide information for each of these, and how many applications care about contact vs press?

Most of the gamepads that currently provide capacitive sensing are VR-centric gamepads.

Notable ones:

• PSVR2
  • Face Buttons
  • All 4 triggers
  • Both sticks
• Oculus Quest/Meta Quest
  • Face buttons
  • All 4 triggers
  • Both sticks
  • Finger 'resting' pads (Might not be on the newest)
• Steam Controller/Steam Deck (Covered by the initial PR)
• Alpakka Controller
  • Capacitive sensing area explicitly for enabling gyro input

In terms of the application area, most of the software is VR-centric currently. I do think there is a lot of potential use-case with Steam to allow for custom layers etc. by means of capacitive sensing vs just pressing.

[slouken]

Most of the gamepads that currently provide capacitive sensing are VR-centric gamepads.

Okay, so the current use case is more for showing hand positioning in VR than using contact for control, is that right?

[mitchellcairns]

Most of the gamepads that currently provide capacitive sensing are VR-centric gamepads.

Okay, so the current use case is more for showing hand positioning in VR than using contact for control, is that right?

I think there's other use-cases that go beyond VR positional handling. It's something I'm exploring with our own gamepads, but there's currently not a great pathway to allow for support within games.

• Controls display on screen, but only when your hand is touching a control surface.

• Furthermore, you can get visual feedback for what button your hand is over without needing to look away from the display.

• Gyro-enable being able to be mapped to different surfaces or combinations of capacitive surfaces is a benefit.

• One phenomenon with joystick inputs is that if you do a 'flick', even if the intention is for the stick to return to neutral, the joystick overshoots and causes an unwanted input.

• The use of a capacitive sensor in the joystick can stop unwanted joystick inputs as it can detect the lack of presence of a finger after an intentional flick. Having this visible to a game/software adds more configuration to the setup.