100+ mappings broken for 8BitDo controllers by bad PRs

[offalynne]

PRs #1057, #1058, #1060 and from @davidhedlund have broken support for over a hundred 8BitDo devices when matching on input_device field due to untested garbage commits and should be reverted to restore support for these devices

[davidhedlund]

I apologize, but there's no documentation that refer to what you mentioned:

In cases where a company rebrands by changing their spelling, this should not retroactively be applied to devices that still use the old branding on the physical device, packaging, descriptors, etc. as is the case of 8BitDo here

Can we please document that?

[offalynne]

Where would you like it documented, and who would you like to do that for you?

The match is on name, you changed the name, and did not test the changes, or if you did, not properly.

I do not know how to explain to you (or anyone) that you should not manually edit fields from exported data into a different value and expect them to still be matched. It seems plainly obvious to me that would not work, and that data should not be frivolously changed. You will have to explain why that is not obvious to you.

[davidhedlund]

Where would you like it documented

As far as I know, this project lacks documentation, FAQ, etc. I think it would be useful to add these policies somewhere.

and who would you like to do that for you?

I'm happy if you do it, since you know what you are talking about.

I do not know how to explain to you (or anyone) that you should not manually edit fields from exported data into a different value and expect them to still be matched. It seems plainly obvious to me that would not work, and that data should not be frivolously changed. You will have to explain why that is not obvious to you.

The file names, and the variables, don't match in a lot of files. Example from android/8BitDo_24G_SF30_USB.cfg:

input_device = "8BitDo 8BitDo SF30 Wireless Controller"
input_device_display_name = "8BitDo SF30 2.4G"

[offalynne]

I'm happy if you do it

From my perspective, prior to now, what has proven a problem for you has not been a significant problem for 200 some other contributors, so this is not a good use of time

Once again, you need to take this up properly with the RetroArch frontend project if you would like to see a change

file names, and the variables, don't match in a lot of files

This is a non-issue as far as I am concerned. The correct approach is to map the device in RetroArch, as indicated both within the RetroArch software and it's extensive documentation, optionally add labels, and submit the file. If other contributors have made some changes in the past such as the filename in the example you provided, that is not a good reason to change 300+ files on a mistaken assumption, especially when you have not tested the outcome of your changes.

[hizzlekizzle]

That's probably a good idea to include a note about not changing any of the fields that are pre-generated in the README, which, if you haven't read through the README fully, @davidhedlund, that's a good place to start.

It looks like some of the documentation linked in there has old option names, so I should probably take some time to try and bring that stuff up-to-date on the website and/or docs site. I also didn't see any mention of assigning the menu_toggle hotkey to the 'home' button on controllers, since that's the one hotkey we allow.