sinput: refactor to make unknown controllers fully dynamic #13593
Conversation
Currently, the generic raspberry pi vid:pid pair must be used for generic mask functionality. Moreover, the axes and buttons are hardcoded in different places in the hid driver, making them difficult to use. First, refactor SDL_gamepad.c to always use autodetection for unknown controllers. Then, in the HID driver, generate valid masks based on a given subtype that will always match the output SDL string and compare them to the ones in the HID descriptor. If they are different, emit a warning but use the ones from the subtype anyway. For already known controllers, add a path to skip the check and load the masks from firmware, assuming what is there matches SDL. This is done on faith, so it should be avoided for future controllers. Moving forward, this commit allows following the same procedure. Assume company X releases controller Y. If the controller uses a completely new layout, company asks for a sub_type. Company gets sub_type and puts it into the controller firmware and releases the controller. In the period that the bundled Steam SDL does not have that sub_type, it uses the full mapping which is correct for the controller and quite useable, but misses a capability match. If it does have the sub_type, capabilities are correct without any additions to SDL. And in the scenario that a controller is too obscure to warrant a sub_type, 0 can be used, and a mapping can be added to its vid:pid pair for proper capabilities to avoid using sub_types.
There was a problem hiding this comment.
I think that the changes here, which opt to make the sub-types global for all SInput devices, is not quite the direction I think it should go.
I do think that it would be wiser to have those 32 available to any owner of a particular PID. Seems more extensible that way.
There was a problem hiding this comment.
This is doable, but it is something i am more likely to be able to fix in #13565
Can we move the discussion for this there?
The only thing this PR does is centralize sub_type handling for the generic, firebird, and other devices. E.g., sub_types should do something by default. It does not preclude using special sub_types per vid:pid, and that is something that can be worked into the switch statements (as is done for the two known controllers).
|
Close in favor of a combined #13565 |
Currently, the generic raspberry pi vid:pid pair must be used for generic mask functionality. Moreover, the axes and buttons are hardcoded in different places in the hid driver, making them difficult to use.
First, refactor SDL_gamepad.c to always use autodetection for unknown controllers. Then, in the HID driver, generate valid masks based on a given subtype that will always match the output SDL string and compare them to the ones in the HID descriptor. If they are different, emit a warning but use the ones from the subtype anyway.
For already known controllers, add a path to skip the check and load the masks from firmware, assuming what is there matches SDL. This is done on faith, so it should be avoided for future controllers.
Moving forward, this commit allows following the same procedure. Assume company X releases controller Y. If the controller uses a completely new layout, company asks for a sub_type. Company gets sub_type and puts it into the controller firmware and releases the controller.
In the period that the bundled Steam SDL does not have that sub_type, it uses the full mapping which is correct for the controller and quite useable, but misses a capability match. If it does have the sub_type, capabilities are correct without any additions to SDL. And in the scenario that a controller is too obscure to warrant a sub_type, 0 can be used, and a mapping can be added to its vid:pid pair for proper capabilities to avoid using sub_types.
cc @mitchellcairns