darthcloud
Implement SInput Gamepad Support
Answers checklist.
- [x] I have read and will follow the terms above.
- [x] I have read the documentation BlueRetro wiki and the issue is not addressed there.
- [x] I have updated my BlueRetro to latest version available.
- [x] I have searched the issue tracker for a similar issue and not found a similar issue.
BlueRetro firmware version
N/A
BlueRetro firmware specification
HW1
BlueRetro firmware variant
Universal
BlueRetro hardware type
External adapter dongle (1 port only)
Manufacturer
N/A
System used
Nintendo GameCube
Bluetooth controller brand & name
No response
What is the problem? (only list ONE problem per report)
We had discussed earlier implementing an open protocol (https://github.com/darthcloud/BlueRetro/issues/1081). I've since redone and formalized an input standard that can be used by all of my gamepads.
The protocol and all struct definitions can be found here: https://docs.handheldlegend.com/s/sinput
This protocol supports dual analog joysticks, along with analog triggers. Dual-stage triggers are supported as part of the protocol (Digital ZL/ZR are considered the 'full press' basically)
Some specific VID/PIDs that you may want to utilize for better mappings:
GC Ultimate Product (Name varies for model variants, do not use as a means of locating): GC Ultimate VID: 0x2E8A PID: 0x10DD
This has the analog triggers as well as the digital press. Let me know if you have any questions here.
ProGCC Product (Name varies for model variants, do not use as a means of locating): ProGCC VID: 0x2E8A PID: 0x10DF
This features digital triggers only
Hoja Gamepad Product (Name varies for model variants, do not use as a means of locating): Generic Gamepad Fallback VID: 0x2E8A PID: 0x10C6
This is basically for hobbyists to have a way to target this input protocol and have an expected/supported means of achieving digital + analog triggers, gyro etc. Of course the gyro/accelerometer is irrelevant here but still worth noting why I'm including it.
Feature Flags For the feature flags, unless you intend on utilizing motion features, you can pretty much ignore it, unless you want to have a simpler time dealing with determining whether or not one of these 'SInput' gamepads supports a specific feature such as analog triggers etc.
Haptics Haptic output is defined with a neat organized structure. There's a structure type designed for typical ERM style feedback with a brake parameter.
Player Number Assignment There is an HID Output report command that supports setting player number. Any 8 bit value is supported.
What did you expect to happen?
N/A
Attach BlueRetro debug trace here
No response
I've pushed out a release candidate for this input method today: https://github.com/HandHeldLegend/SInput-HID/releases/tag/v1.0.0-rc1
I've also nearly finalized the SDL driver, which you may find useful for implementation from a host side. Note that the button mask is meant for SDL, for this specific use case you can just ignore it, and use the defined structure of where the various buttons will be.
I recommend using the ERM simulation packets for GameCube and other retro consoles.
SDL Pull request for driver reference https://github.com/libsdl-org/SDL/pull/13343
Everything you see will remain unchanged unless I get some type of significant feedback and find something that is severely broken or needs to be changed.
Edit:
Release v1.0.0 is up https://github.com/HandHeldLegend/SInput-HID/releases/tag/v1.0.0