Gamepadcontrollers with less than 16 buttons do not get all button functions mapped

[Gemba]

Describe the bug
Gamepadcontrollers which are identified in the gamecontrollerdb.txt but have physically than 16 buttons and do have a RetroPie Gamecontroller *.cfg file do not get all buttons mapped into Amiberry controller.

For example: A gamepad with 13 physical buttons has UP/DOWN mapped but LEFT/RIGHT (the 14th and 15th in the list, retroarch.cpp::retroarch_button_list[]) is "cut off"/ not mapped. If a gamepad has 12 physical buttons reported then also DOWN is "cut off" from the mapping.

To Reproduce
Steps to reproduce the behavior:

1. Have a gamepad controller connected with <16 buttons defined. The controller does not report/use a hat.
2. Have it configured in RetroPie / EmulationStation
3. Launch Amiberry
4. Note that not all buttons are mapped (everything between physical button count (e.g. 13) up to the possible 15th button) is missing

Expected behavior
All buttons (up to 15) defined in Controller.cfg file are mapped into Amiberry

Desktop

• Rpi5 without X/Wayland and current RetroPie
• OS: Bookworm 12.x (current), aarch, libSDL2 2.26.3+1rpi
• Amiberry Version: 5.7.1, but should also be reproducable in more recent versions

Workaround
Remove the RetroPie Gamecontoller.cfg file, then all buttons are mapped as expected.

Additional context

• retroarch.cfg is not geared/utilized to player input mapping. But if it is, the effect is most likely the same.
• From looking at the code I see the did->buttons / did->buttons_real contain the pyhsical buttons, as setup_mapping is using the full 15 buttons. But for some reason the buttons reported from map_from_retroarch() don't end up in the final result.
• If you can provide some hints I could implement and test a fix

[midwan]

Pasting this here from the closed PR, for continuation:

This seems a bit weird to me then, and especially the proposed changes don't look right.

1. When a retroarch mapping is detected, the gamepad is opened as a joystick, not a controller. However, the changes proposed here, only happen when a controller is detected - which would normally happen when not using retroarch mapping.
2. Since the issue seems to be related to the contents read from the controller's retroarch cfg file, it seems to me that the changes should be closer to that, not the amiberry_input one, which applies to all controllers (retroarch or not). But I see that we already scan for 15 buttons from the retroarch file regardless. Need further digging into this to fully understand what goes wrong.
3. The changes proposed would override what gets detected from the controller itself, but we have established that it works fine without the retroarch mapping file, so that number is reported correctly from SDL2. Overriding it there, would potentially create issues for other controllers, with different number of buttons (regardless of them having a retroarch mapping or not).
   Considering all the above, I think we need a different kind of fix. And I need to recreate this locally, in order to better understand what is happening, in order to fix it. :)

Meanwhile, I did a quick test to recreate this here, with your posted retroarch config. I have a PS4 controller here, which I tested first without any retroarch config enabled, and AmigaTestKit.

Then I enabled the retroarch config, and removed the mapping for most buttons, leaving only the left analog for direction, and button A.

The tests in AmigaTestKit show that it still works as expected, having all the available buttons from retroarch working. Directional with the Left stick and a single button only.

The view in Custom Controls was not correctly showing this, having most dropdowns disabled. That's why I was asking, is this a GUI issue in the end, in Custom Controls?

[Gemba]

I tested also on my side with an XBox 360 Controller.
Having removed the analog stick mappings and leaving the buttons and the dpad/hat enabled in the retroarch gamecontroller mapping I get this result:

• To my surprise, in the GUI I can navigate with the analog stick, although it should be disabled to my understanding and Left X/Y, Right X/Y and also DPad buttons display disabled in Custom Controls where I would DPad to show as enabled.
• In contrast in game / Amiga Test Kit the DPad works all directions (=as expected) and the analog sticks are disabled (=as expected), also the buttons B1, 2, 3 get properly mapped.

[midwan]

The GUI behavior is expected - it doesn't check the retroarch config for the built-in navigation, it uses a standard internal/default mapping for all joysticks for that. So, even if you had removed some of the lines from your retroarch config file, the GUI would still open the controller with a default mapping and use directional navigation and 2 buttons (for OK/Cancel).

[midwan]

@Gemba
I'm not sure where we stand after the latest findings then. Do we keep this open and try to figure out more? Do we close this?

[Gemba]

Leave it open, please. I guess I can provide more clues.

When there is a SDL compliant controller attached which reports less than 15 buttons, this loop does not get the 14th and 15th mapping from the previously done RA controller mapping in retroarch.cpp:map_from_retroarch().

A more elaborated fix would be to check which buttons are reported from SDL here and compare them with the ones from the retroarch button names.

Edit:
After further analysis this approach would be super awkward as in the main_window.cpp::check_input() the respective button is checked against the SDL_GameControllerButton which must match the mapping.button from the controller setup earlier. Thus my initial PR made sense to enforce that any controller detected from the SDL gamecontroller DB must iterate over 15 buttons (even if there are not 15) and have the respective retroarch button value at the same the array/enum position as in SDL.