Add support for extra and potentially unbound GamePad buttons (Fixes GitHub #11273)

[XerTheSquirrel]

Guidelines

1. Rebase before opening a pull request
2. If you are sending several unrelated fixes or features, use a branch and a separate pull request for each
3. If possible try squashing everything in a single commit. This is particularly beneficial in the case of feature merges since it allows easy bisecting when a problem arises

Description

Allows for extra actions to be defined for inputs so that potentially less important or lesser used actions could still potentially be bound to a button.

Related Issues

GitHub #11273.

Related Pull Requests

None currently.

Reviewers

None currently, in draft.

[i30817]

Could you add savestate_1, savestate_2... and loadstate_1...

For controller overlay setups where you're trying to purposefully limit the amount of savestate slot juggling, by presenting fixed numbers.

Of course, then I'd ask for a overlay long touch modifier so I could save on a touch and load on long touch, but that's different.

[LibretroAdmin]

Can you fix the UWP build? See the failed CI pass.

[hizzlekizzle]

This is probably the single most common request from core authors. Thanks for working on this Xer!

[XerTheSquirrel]

Could you add savestate_1, savestate_2... and loadstate_1...

For controller overlay setups where you're trying to purposefully limit the amount of savestate slot juggling, by presenting fixed numbers.

Of course, then I'd ask for a overlay long touch modifier so I could save on a touch and load on long touch, but that's different.

Not sure what you mean, this sounds like something that would be an unrelated change/feature with regards to this one.

[XerTheSquirrel]

Current progress wise, I have all 128 logical buttons showing in Main Menu -> Settings -> Input -> RetroPad Defaults?. They currently do not appear in the Quick Menu -> Input... not entirely sure about how to go about that.

There is an extra "Unknown" key at the end of the list.

Additionally, every driver is hard coded at 16 buttons for their input, so if an input driver for a front end were to support directly inputting logical keys. Hypothetically the logical keys, from the last 127 to first, could be used to add more standard RetroPad keys such for L4/R4/L5/R5. However, this is out of scope for this branch and I will not be considering any driver changes or fixed buttons.

[XerTheSquirrel]

Current TODOs:

• Why is there an "Unknown" option at the end of the main menu inputs?
• Getting the logical keys into the Quick Menu Inputs.
• Ditto for core and content specific overrides.
• Fix configuration saving and loading so binds are remembered.
• Essentially rewrite the input descriptor left/right callbacks to go through all of the logical keys as well.
• Hide any logical keys which are not defined by the core.
• Handle all of the extra logical keys in netplay, probably would be best to just indicate which logical keys were pressed rather than sending a large bit/byte array.
• Figure out how to alias/bind the logical inputs so that they are detected by the front end.
• Sending of the inputs to cores.

Long term plans:

• Keep the extra inputs environment callback setting marked as experimental until more things are fleshed out accordingly.

[XerTheSquirrel]

Okay so update, by adding the appropriate value in config.h.keybinds.def.h I was able to save and load the following input for mapping a logical button to a given key on the RetroPad Binds menu. Still have not figured out how the core input menu works though.

[i30817]

Oh it's about core defined combos in retropad. I thought it was expanding hotkeys that you can call in overlays\the hotkeys menu.

[XerTheSquirrel]

Oh it's about core defined combos in retropad. I thought it was expanding hotkeys that you can call in overlays\the hotkeys menu.

It is whatever a core wishes to define, for example mine will be using it for volume keys, and other misc. buttons.

[XerTheSquirrel]

Seems the last 12 menu items in the binds list has the same mapping to them. Maybe a limitation of the menu code? There should probably be a sub menu for the logical buttons since there are lots.

[hizzlekizzle]

There should probably be a sub menu for the logical buttons since there are lots.

is there a way to only enumerate the ones the core actually uses? I believe currently the controls menu only shows the core functions that are actually used (i.e., if the core doesn't use analogs, you won't see them in the list), so if that behavior could be preserved...

[XerTheSquirrel]

There should probably be a sub menu for the logical buttons since there are lots.

is there a way to only enumerate the ones the core actually uses? I believe currently the controls menu only shows the core functions that are actually used (i.e., if the core doesn't use analogs, you won't see them in the list), so if that behavior could be preserved...

This is the generic button mapping configuration which sets the default buttons/keys for RetroPad buttons. Have not figured out how to get the logical buttons showing on the core/content specific control menu yet.

[hizzlekizzle]

oh gotcha. So, settings > input > retropad binds > port 1 controls? Yeah, having 128 lines in there would be pretty hairy. Probably wouldn't want them in the automated 'bind all' process, either.

[i30817]

Does it really need to show more buttons than the connected device has? Overlay or actual device. It's not like you can use them without, due to the pidgeonhole principle unless I'm missing some combo or multi device capability I don't understand.

I understand if you're using a keyboard or a "real" keyboard in a strange core like a midi syth composer you could possibly want the 128, but if you're using the retropad overlay you'll likely use... how many keys that particular retropad overlay has for each type I guess, and the leftovers get into those new ones. Same idea for real devices.

If the world was perfect settings->input->retropad binds wouldn't even exist too, so I don't mind too much if they appear there, as long as they don't leak into the quick menu generic control mappings or core specific core settings control mappings, but it seems to be that the best way of preventing that is to limit it there.

That it wasn't done already indicates it's probably harder than I think it is though.

[RobLoach]

Adding that .idea directory? Intentional?

[XerTheSquirrel]

Yes.

[RobLoach]

Could we define this as a RARCH_NUM_BIND_GAME_CONTROLLER or similar macro in input_defines.h rather than looking like a function? It's rather confusing when it looks like a func.

[XerTheSquirrel]

Not sure yet on how I want to do it, with a static define or function.

[matheuswillder]

oh gotcha. So, settings > input > retropad binds > port 1 controls? Yeah, having 128 lines in there would be pretty hairy. Probably wouldn't want them in the automated 'bind all' process, either.

Maybe there could be some kind of filter that would show the buttons according to the current input method selected? For example, physical keyboard, generic gamepad, and so on.

It's just an idea. I had to go back to using standalone Dolphin because some Wii games that require lots of motion inputs are basically impossible to map with the current limitation, that doesn't happen in standalone Dolphin, so I hope this gets merged some day :)

Edit: Just now I saw that @i30817 already suggested the same above, so sorry about that.