I have several obscure controllers that aren't yet in SDL's database, so I'm unable to use the GamePad API with them. MonoGame loads the SDL controller database on startup, but there is no way to supply your own file to load in, if, for instance, the player's controller isn't supported by SDL. While I plan to submit a PR with the mappings for my controllers to SDL, the average player won't be willing to do this to play a game they bought with their favorite controller.
The idea would be to provide something like a static GamePad.LoadMappingsFromFile(string file) method that would call Sdl.RwFromMem followed by Sdl.GameController.AddMappingFromRw to register the new controller mappings, just like the initial database load.
You can just call the native Sdl method if you need to.
If you are playing your game using Steam, and you configured the controller in the Steam big picture mode, the games that are using Sdl will recognize your controller.
I tested this out using the native SDL calls and there's a caveat: if the controller is already plugged in before adding the mappings, the player will need to unplug and replug the controller because the controller isn't recognized as a gamepad yet. This would be required on every launch of the game.
However, I found that the controller is picked up as a gamepad while plugged in only if the mappings are added before the first SDL event loop is fired, which means it has to be in the constructor to your game (Ex. Game1.cs). I feel there may be some room for improvement (Ex. a ReconnectDevice method the developer can call if a Joystick is connected but the GamePad at the same index isn't).
I'm fine with adding API to check for gamepads.
Edit: actually would it be enough to let users specify a custom gamepad mapping file?
I'm fine with adding APIs per platforms (I know of a few I could use myself), but we need to setup an API for that. We shouldn't be just adding it to the Gamepad class, etc.
I really dislike fragmentation in the API between platforms. It forces me to write code like https://github.com/Apostolique/Apos.Input/blob/master/Source/InputHelper.cs#L112
https://github.com/Apostolique/Apos.Input/blob/master/Source/InputHelper.cs#L166
(If there's a better way to do what I did above, I'd be really interested.)
If the API is different in some platforms, I think a stub that does nothing should be provided for the other platforms.
Yes, that is why I said what I said above.
Yes, I believe all API should be shared as well. Per platform API is very bad for portability, which is supposed to be a key selling point of MG, so we don't want to compromise on it.
But in this case I think we can have a build setting to override the gamepad mapping file, so we don't have to add API that does not make sense for all platforms.