HID driver ignores most non-standard buttons
connorjclark opened this issue · comments
Here is the output for all buttons found on my Xbox One controller:
0x10751f810 type: 2 usage: 1
0x10751f960 type: 2 usage: 2
0x10751f180 type: 2 usage: 3
0x10751fc10 type: 2 usage: 4
0x10751fd60 type: 2 usage: 5
0x10751feb0 type: 2 usage: 6
0x107520000 type: 2 usage: 7
0x107520150 type: 2 usage: 8
0x1075202a0 type: 2 usage: 9
0x1075203f0 type: 2 usage: 10
0x107520540 type: 2 usage: 11
0x107520690 type: 2 usage: 12
0x107520930 type: 2 usage: 13
0x107520a80 type: 2 usage: 14
0x107520bd0 type: 2 usage: 15
0x107520d20 type: 2 usage: 548
The last one is the select button (opposite of the start button, looks like two interlacing squares), but being over the max _AL_MAX_JOYSTICK_BUTTONS it is dropped.
Do the usage values here have any particular meaning? I've been trying to find documentation on how HID gaming controllers work, but can't seem to find a standard definition for the usage codes of gaming controllers. If there is no such standardization, are we free to just accept the first 32 (value of _AL_MAX_JOYSTICK_BUTTONS) buttons, instead of just the ones less than 32?
Could this constant simply be bumped to something like 1024? Might end up doing that in my fork.
For some reason the select button on this X360 controller is mapped to usage page 0xC, kHIDPage_Consumer, not a button - so the recent PR still doesn't allow the select button to be used.
Maybe it mapping to a consumer input is by design, and this is meant to be a system button? Except I'd then expect the big center Xbox Logo home button to be a consumer input too, but that's actually in the button usage page!
Does the HID controller/driver code live on a device, or is this something Apple messed up? Is the fix here "don't use HID"? 🤷
EDIT:
This is a bluetooth X360 controller. I learned Apple is the one providing the driver for this to work as a HID device. Drivers are packaged in OS updates. I'm on 12.6 Monterey still, will update to 14.3.1 Sonoma and see if there is a better driver.
EDIT v2:
Nope :/
FWIW, the SDL backend works just fine for all buttons.
The examples on the official website don't work with gamepads, since they haven't been updated, but when I fixed that bug I uploaded demos here.
The reason I added a page check was because for my controller the select button was mapped to both a button, and also a 'back' system action, so I figured I'd just filter them out that way. We can take a look at what other libraries do for this (if they use HID)
Looks like SDL admits both kHIDPage_Consumer and kHIDPage_Button, so we can do the same here.
Well... I guess it admits actually quite a few pages. GLFW does as well. Probably just need to copy over the logic in its entirety to match the behavior.
I see in SDL's hidapi that it seems to collect all usages, and yeah it treats button and consumer the same way. Interesting to see how it uses all the other types.
FWIW this is the commit where they added handling consumer type: libsdl-org/SDL@9c51c4a