[WIP] Add partial support for SDL GamePad layouts
PR Details
Description
Currently Stride only supports XInput family and DualShock4 gamepads. This PR aims to address that by including a generic layout factory that uses a community managed controller layout mapping for SDL (gabomdq/SDL_GameControllerDB).
The support is partial because the SDL format supports half axis and dpad remapping. I didn't look too closely but I believe supporting that would require a bit more changes than just a new layout. Out of 348 controller definitions for Windows, 68 would have issues because of that (including unfortunately the XBox Adaptive Controller).
I'm including a copy of the controller mapping file and it's configured to be copied to the output directory of the consumer of Stride.Input package. By default we exclude all content assets in the project templates so at this moment the user would have to explicitly include the package.
That's why I set WIP - should I include the mapping file within the assembly? Pros: no additional files in the output folder of the game, no need for users to explicitly include the package Cons: need to recompile assembly to include new mappings, additional load time required for parsing a lot of mappings the user might not need and can't exclude
Related Issue
N/A
Motivation and Context
I have an XBox One Elite controller that wasn't being picked up by XInput. With changes it works (I haven't yet tested all buttons, or other controllers).
Types of changes
- [ ] Docs change / refactoring / dependency upgrade
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist
- [ ] My change requires a change to the documentation.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
I'm confused, there's already a 'GamePadSDL' in source, isn't this feature already supported ?
In the InputSourceSDL an instance of GamePadSDL is only created if there is a layout for the device (the device is represented by GameControllerSDL). I'm not sure if the ProductID by which we recognize controllers is something unique to SDL or if it will be usable by other windowing systems. I will take a look if there's a way to use SDL's native parts to take care of the parsing of the file for me (but then it will be limited to SDL).