Provide SDL2 button mappings for convenience

[emilyst]

I'm opening this issue to split off SDL2 mapping discussion from issue #7. Please refer to that issue for context.

Quoting from #7 (comment):

Looking for SDL mappings for https://github.com/gabomdq/SDL_GameControllerDB, both wired and wireless. Mapping tool: https://www.generalarcade.com/gamepadtool/
I have the SNES and N64 pads and got those covered, but not the Genesis.

Okay, I think I see. You want someone to run that program and supply you the output.

I think your request should go into a new issue. If you want to open a dedicated issue, please do. If you have a new topic to discuss, even if it's related to an existing one, it's encouraged to open a new issue for that topic. That way it's easier for myself and others to keep track of.

This has gotten pretty off-topic for six-button Genesis controller support, so I'd like to ask that we stop discussing the SDL mappings here.

I think I can find time today to try to run that program with a three-button controller using the hid-nx module, but I am not certain. This request is a little beyond the scope of a problem, bug, or other issue with my module, so it's a lower priority.

[emilyst]

In reference to #7 (comment):

Looking for SDL mappings for https://github.com/gabomdq/SDL_GameControllerDB, both wired and wireless. Mapping tool: https://www.generalarcade.com/gamepadtool/
I have the SNES and N64 pads and got those covered, but not the Genesis.

@offalynne I believe I've already given you the mappings for the 3btn controller here: gabomdq/SDL_GameControllerDB#546

Is this not what you needed?

It's likely that the hid-nx module has slightly different mappings than the vanilla hid-nintendo controller. That could be the issue there.

[offalynne]

Correct. All that's required for support are mapping strings composed while using hid-nx, since the GUID does come out uniquely. I have already committed maps for SNES and N64 pads.

[emilyst]

Correct. All that's required for support are mapping strings composed while using hid-nx, since the GUID does come out uniquely. I have already committed maps for SNES and N64 pads.

Just checking, the GUID you refer to, what does that look like? (If it's based on the vendor and device ID, those actually weirdly change and even overlap depending on the situation.)

[nfp0]

Ah yes. I understand what you mean now @offalynne

[offalynne]

@emilyst see
mdqinc/SDL_GameControllerDB@67fdcdd
and
mdqinc/SDL_GameControllerDB@dbcb77c

Mappings authored using SDL seem to provide a unique GUID with hid-nx (the "version" field in the descriptor, I believe), so no collisions seem to arise with prior mappings.

[offalynne]

If you want to open a dedicated issue, please do. If you have a new topic to discuss, even if it's related to an existing one, it's encouraged to open a new issue for that topic. That way it's easier for myself and others to keep track of.

For what it's worth, I am sympathetic to this and hope continuing the conversation in this new issue (thanks for making it) is suitable to you. I apologize for sidebarring in the other issue. I have learned the hard way through years of managing large repos with many collaborators to try and reach people immediately wherever they are actively posting on any given subject, even where tangential, because attention is scarce and people are busy (eg. your dialogue with the upstream submitter Daniel). I realize this can muddy issue organization for a smaller project.

[emilyst]

@emilyst see gabomdq/SDL_GameControllerDB@67fdcdd and gabomdq/SDL_GameControllerDB@dbcb77c

Mappings authored using SDL seem to provide a unique GUID with hid-nx (the "revision" field in the descriptor, I believe), so no collision issue with the different mapping.

Okay, cool. For what it's worth, SDL seems to call these "controller GUIDs," but they're not really GUIDs as the broader industry has defined them, but instead derived from the product, vendor, and name of the device.

Anywho, I'll try to remember to do this sometime soon.

If you want to open a dedicated issue, please do. If you have a new topic to discuss, even if it's related to an existing one, it's encouraged to open a new issue for that topic. That way it's easier for myself and others to keep track of.

For what it's worth, I am sympathetic to this and hope continuing the conversation in this new issue (thanks for making it) is suitable to you. I apologize for sidebarring in the other issue. I have learned the hard way through years of managing large repos with many collaborators to try and reach people immediately wherever they are actively posting on any given subject, even where tangential, because attention is scarce and people are busy (eg. your dialogue with the upstream submitter Daniel). I realize this can muddy issue organization for a smaller project.

Thanks for being considerate. My ability to keep on top of and respond to issues depends on the issues being focused and well organized, so I suppose I'm unusual in that respect, but it really helps me.

[offalynne]

SDL seems to call these "controller GUIDs," but they're not really GUIDs as the broader industry has defined them

Correct, they're identifier strings with a number of different formats and features meant to be unique within the list (with several exceptions) and don't meet the common definition of GUID