Gamepadcontrollers with less than 15 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.

[midwan]

Coming back to this, after finding some time to set up a fresh Retropie installation here. I tested with Amiberry 7 on it.

I used a Competition Pro USB joystick, which only has a D-Pad and 4 buttons. Mapped those all in Retroarch on startup, then tried AmigaTestKit, to see the responses.

All mapped buttons function correctly, from what I can see.

How did you determine that some buttons did not get mapped, exactly? Maybe I'm missing something.

[Gemba]

Hi again.
I guess I have the same here ID 040b:6533 Weltrend Semiconductor Speed-Link Competition Pro, it registers the directions via EV_ABS (X/Y) and not as BTN_DPAD_UP/DOWN from what I can tell. I haven't checked in Amiberry, how is it detected there? As Gamepad or Joystick?

I have also a model with D-SUB9 which is directly wired to the GPIO and uses BTN_DPAD events with this device tree only driver. This is where I noticed the behaviour in Amiberry.

(NB The device tree implementation has most likely a bug when using EV_ABS via GPIO device tree https://forums.raspberrypi.com/viewtopic.php?t=377990 I lost track of it to report it further.)

[midwan]

@Gemba
If you're using Retroarch (that is to say, if that is detected in the paths you have configured), then Amiberry will only use Joystick mode for all connected devices.

Game Controller mode is only used if Retroarch is not enabled.

[midwan]

I'm still not sure what can be done about this. I cannot recreate it here.

• Having a gamepad detected as a Controller in SDL2 (meaning, no retroarch cfg file detected), works as expected.
• Having a gamepad with less than 15 physical buttons, using a retroarch cfg file, still works as expected in my tests. No mapped buttons missing.

Maybe this is an issue only with the GPIO connected gamepad you're testing with? That's one difference I can think of (which I don't have here to test with).

[Gemba]

Heya, I see that the USB Competetion Pro and the GPIO/DB9/Atari Competition Pro do get mapped differently from Emulationstation.

This is the USB connected:

$ cat "/opt/retropie/emulators/amiberry/controllers/A SPEED-LINK Competition Pro.cfg" 
input_device = "A SPEED-LINK Competition Pro"
input_driver = "udev"
input_vendor_id = "1035"
input_product_id = "25907"
input_left_axis = "-0"
input_right_axis = "+0"
input_down_axis = "+1"
input_a_btn = "1"
input_up_axis = "-1"

This is the GPIO connected:

cat "/opt/retropie/emulators/amiberry/controllers/GPIO Arcade Gamepad 1.cfg"
input_device = "GPIO Arcade Gamepad 1"
input_driver = "udev"
input_vendor_id = "1"
input_product_id = "1"
input_left_btn = "11"
input_right_btn = "12"
input_down_btn = "10"
input_a_btn = "0"
input_up_btn = "9"

That explains that the USB still gets mapped properly, as it has axis'es, whereas the gamepad only reports buttons as directions.

[midwan]

OK, let me see if I can find any controller here that has less buttons and they are mapped as such, instead of axis.

[Gemba]

Here is an option how to recreate with a Gamepad with many buttons (more than needed for Amiberry).

I used a 'Logitech RumblePad 2' (USB) but any should do as long as it has four spare buttons to map.

I stripped down the EmulationStation config to this below and replaced the "input_left_btn" = "h0left" with "input_left_btn" = "a_spare_button__number" (I used the four shoulder buttons for directions). It reads now:

cat /opt/retropie/emulators/amiberry/controllers/Logitech\ RumblePad\ 2\ USB.cfg
input_device = "Logitech RumblePad 2 USB"
input_driver = "udev"
input_vendor_id = "1133"
input_product_id = "49688"
input_left_btn = "5"
input_left_btn_label = "Dpad Left"
input_right_btn = "7"
input_right_btn_label = "Dpad Right"
input_down_btn = "6"
input_down_btn_label = "Dpad Down"
input_b_btn = "1"
input_b_btn_label = "2"
input_a_btn = "2"
input_a_btn_label = "3"
input_up_btn = "4"
input_up_btn_label = "Dpad Up"

Then I forged the report from SDL about the axis-count and button count:

diff --git a/src/osdep/amiberry_input.cpp b/src/osdep/amiberry_input.cpp
index 9a08170..4cc9409 100644
--- a/src/osdep/amiberry_input.cpp
+++ b/src/osdep/amiberry_input.cpp
@@ -888,10 +888,12 @@ void setup_controller_mappings(const struct didata* did, const int i)
 
 void fix_didata(struct didata* did)
 {
-       did->axles = static_cast<uae_s16>(SDL_JoystickNumAxes(did->joystick));
+       //did->axles = static_cast<uae_s16>(SDL_JoystickNumAxes(did->joystick));
+       did->axles = static_cast<uae_s16>(0);
        int hats = SDL_JoystickNumHats(did->joystick);
        if (hats > 0) hats = hats * 4;
-       did->buttons_real = did->buttons = static_cast<uae_s16>(SDL_JoystickNumButtons(did->joystick) + hats);
+       //did->buttons_real = did->buttons = static_cast<uae_s16>(SDL_JoystickNumButtons(did->joystick) + hats);
+       did->buttons_real = did->buttons = static_cast<uae_s16>(13); // anything less than 15 will reveal the issue
        if (did->is_controller)
        {
                for (uae_s16 b = 0; b < did->buttons; b++)