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.

[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++)

[midwan]

OK, following your example then:

I edited my PS4 controller config, and left only 8 buttons mapped (0-7), replacing the HAT ones:

input_device = "Sony Interactive Entertainment Wireless Controller"
input_driver = "udev"
input_vendor_id = "1356"
input_product_id = "2508"
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_y_btn = "3"
input_y_btn_label = "Square"
input_x_btn = "2"
input_x_btn_label = "Triangle"
input_b_btn = "0"
input_b_btn_label = "Cross"
input_a_btn = "1"
input_a_btn_label = "Circle"
input_up_btn = "4"
input_up_btn_label = "Dpad Up"

Then I edited fix_didata to hardcode did->axles = 0; and also:

did->buttons_real = did->buttons = 8;

After that, I run AmigaTestKit, configured to use the controller in CD32 mode (so that I can test more buttons).
The D-PAD and the N/S/E/W buttons still worked as expected, so the mapping worked.

In other words, I still cannot recreate this.

[Gemba]

The D-PAD and the N/S/E/W buttons still worked as expected

Yes, the real d-pad still works also on my side, but try to use the newly assigned buttons to test the issue. (I used jstest to identify the four spare shoulder button numbers for this test.)

I changed in the Amiga UI -> Input -> Port 1 (Logitech RumblePad 2) the mode from Default to CD32 pad on the fly (=no persistent configuration) and can still note the absence of button actions (left and right in my case) when using the shoulder buttons.

When setting 8 as button count I don't get any input from the shoulder buttons.

[midwan]

You will obviously only get input from the buttons that were mapped on startup - meaning, only the number of buttons available. In my case, that was 8 buttons total (since I hardcoded it to that), and all of them are mapped as expected. 4 for the D-Pad movement, and 4 for N/S/W/E actions. All of them show up as expected in AmigaTestKit, when CD32 type is selected (both in Amiberry and in AmigaTestKit, of course).

Are you trying to use more buttons than detected/set in the did->buttons value? That won't work.

Buttons 0-7 on my controller, referred to the D-Pad and N/W/S/E of course. The extra buttons (shoulder buttons, Start, Select, L/R stick buttons and the various axes) are not included in the mapping, so they do nothing.

[Gemba]

The buttons you do assign, are these button numbers from an axis / d-pad or just buttons?
I used 4 from the shoulder and did not use the d-pad at all.

Here is my excerpt from the amiberry.log:

Controller #0: Logitech RumblePad 2
      GUID: 0300a0916d04000018c2000010010000
Controller 0 is mapped as "0300a0916d04000018c2000010010000,Logitech RumblePad 2,a:b1,b:b2,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,leftshoulder:b4,leftstick:b10,lefttrigger:b6,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b11,righttrigger:b7,rightx:a2,righty:a3,start:b9,x:b0,y:b3,platform:Linux,".
Joystick name: 'Logitech RumblePad 2 USB', sanitized to: 'Logitech RumblePad 2 USB'
Checking for Retroarch cfg file: '/opt/retropie/emulators/amiberry/controllers/Logitech RumblePad 2 USB.cfg'
Retroarch controller cfg file found, using that for mapping
Controller Detection: input_enable_hotkey_btn : -1
Controller Detection: input_exit_emulator_btn : -1
Controller Detection: input_reset_btn : -1
Controller Detection: input_menu_toggle_btn : -1
Controller Detection: input_osk_toggle_btn : -1
Controller Detection: input_b_btn : 1
Controller Detection: input_a_btn : 2
Controller Detection: input_y_btn : -1
Controller Detection: input_x_btn : -1
Controller Detection: input_select_btn : -1
Controller Detection: input_menu_toggle_btn : -1
Controller Detection: input_start_btn : -1
Controller Detection: input_l3_btn : -1
Controller Detection: input_r3_btn : -1
Controller Detection: input_l_btn : -1
Controller Detection: input_r_btn : -1
Controller Detection: input_up_btn : 4
Controller Detection: input_down_btn : 6
Controller Detection: input_left_btn : 5
Controller Detection: input_right_btn : 7
Controller Detection: input_l_x_plus_axis : -1
Controller Detection: input_l_y_plus_axis : -1
Controller Detection: input_r_x_plus_axis : -1
Controller Detection: input_r_y_plus_axis : -1
Controller Detection: input_l2_axis : -1
Controller Detection: input_r2_axis : -1
Controller Detection: input_right_axis : -1
Controller Detection: input_down_axis : -1
Controller Detection: count_hats : -1
Controller Detection: invert left  y axis: 0
Controller Detection: invert left  x axis: 0
Controller Detection: invert right y axis: 0
Controller Detection: invert right x axis: 0

This is the output from jstest:

$ jstest /dev/input/js0 
Driver version is 2.1.0.
Joystick (Logitech Logitech RumblePad 2 USB) has 6 axes (X, Y, Z, Rz, Hat0X, Hat0Y)
and 12 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn, BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6).
Testing ... (interrupt to exit)
Axes:  0:     0  1:     0  2:     0  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 

I am using the buttons 4 to 7 for movements.

[midwan]

Just buttons used, and they were sequential as well (button 0 until button 7).

[Gemba]

Just FTR:
I use Amiberry 5.7.4 with SDL2.30.8 (aarch64).
gcc version 12.2.0 (Debian 12.2.0-14)
As far as I can tell the codebase in questions has not changed im comparision to main/HEAD.

Can you share the part of the amiberry.log as it shows the controller detection on your side (same as I did before)?
Can you recompile with using static cast for axis (0) and buttons (8) to avoid potential casting knock-on effects?

[midwan]

I'm always testing with the latest from this repo. Tests were done on RetroPie (installed on top of Bookworm manually) and after that, on Debian12 with only the relevant config files from Retroarch.

GCC is 12.2.0 here as well.

SDL2 version is 2.26.5 (the one delivered from the repos)

This is the relevant extract from the amiberry.log file:

Controller #0: PS4 Controller
      GUID: 0300d0424c050000cc09000011810000
Controller 0 is mapped as "0300d0424c050000cc09000011810000,PS4 Controller,a:b0,b:b1,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:b4,leftstick:b11,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b12,righttrigger:a5,rightx:a3,righty:a4,start:b9,x:b3,y:b2,platform:Linux,".
Joystick name: 'Sony Interactive Entertainment Wireless Controller', sanitized to: 'Sony Interactive Entertainment Wireless Controller'
Checking for Retroarch cfg file: '/home/midwan/.local/share/amiberry/controllers/Sony Interactive Entertainment Wireless Controller.cfg'
Retroarch controller cfg file found, using that for mapping
Controller Detection: input_enable_hotkey_btn : -1
Controller Detection: input_exit_emulator_btn : -1
Controller Detection: input_reset_btn : -1
Controller Detection: input_menu_toggle_btn : -1
Controller Detection: input_osk_toggle_btn : -1
Controller Detection: input_b_btn : 0
Controller Detection: input_a_btn : 1
Controller Detection: input_y_btn : 3
Controller Detection: input_x_btn : 2
Controller Detection: input_select_btn : -1
Controller Detection: input_menu_toggle_btn : -1
Controller Detection: input_start_btn : -1
Controller Detection: input_l3_btn : -1
Controller Detection: input_r3_btn : -1
Controller Detection: input_l_btn : -1
Controller Detection: input_r_btn : -1
Controller Detection: input_up_btn : 4
Controller Detection: input_down_btn : 6
Controller Detection: input_left_btn : 5
Controller Detection: input_right_btn : 7
Controller Detection: input_l_x_plus_axis : -1
Controller Detection: input_l_y_plus_axis : -1
Controller Detection: input_r_x_plus_axis : -1
Controller Detection: input_r_y_plus_axis : -1
Controller Detection: input_l2_axis : -1
Controller Detection: input_r2_axis : -1
Controller Detection: input_right_axis : -1
Controller Detection: input_down_axis : -1
Controller Detection: count_hats : -1
Controller Detection: invert left  y axis: 0
Controller Detection: invert left  x axis: 0
Controller Detection: invert right y axis: 0
Controller Detection: invert right x axis: 0
Controller init_kb_from_retroarch(0): Found 
Controller init_kb_from_retroarch(1): Not found 

[Gemba]

I was able to reproduce it even with 7.0.4 Amiberry (with 2.30.8 SDL2), source build from main/HEAD.
I followed the hints you gave in RetroPie-Setup, but did put the modified amiberry sibling to the amiberry.sh and did left the launcher script amiberry.sh untouched.
Are you sure you are launching the modified (with the forged axis- and button-count) amiberry binary?

Only difference is now only the make and model of the USB Gamepad and SDL2.

[midwan]

I am debugging the changed version directly on the device, so yeah, I'm pretty sure. :)

I also think it has something to do with the device you're testing, as no other has reported something like this. I don't think it's related to the SDL2 version, as we've been running this approach for years now, with older versions of SDL2 until the latest ones. Again, no such issue reported until now. Must be some special case that triggers it.

[Gemba]

Sure, the GPIO approach is new and not widespread use, but I would claim it is correct.

I would not be that persistent if the gpio-keys setup would also showed this behaviour in Retroarch or with emulators which use the SDL2 Gamepad API, but in these contexts it works as expected (all buttons present).

[giantclambake]

This is the output from jstest

FWIW, you should be using 'sdl2-jstest' to examine this situation -> https://github.com/Grumbel/sdl-jstest (some distro repos have it as a package) ....but not debian, so a github clone is best....umm, and if you use that, you need to place the newest gamecontrollerdb.txt in the directory sdl-jstest/external/sdl_gamecontrollerdb/ ....you can use the amiberry Paths panel and the Update Controller DB button to download the latest version of this file, and copy it into the above path (on this debian system, amiberry downloads it to ~/.local/share/amiberry/controllers/ ..or whatever your controllers path is set to)....

[Gemba]

The SDL part is fine, thanks anyway @giantclambake .

$ sdl2-jstest -l
Found 1 joystick(s)

Joystick Name:     'GPIO Arcade Gamepad 1'
Joystick GUID:     1900de43010000000100000000010000
Joystick Number:    0
Number of Axes:     0
Number of Buttons: 13
Number of Hats:     0
Number of Balls:    0
GameControllerConfig:
  Name:    'GPIO Arcade Gamepad 1'
  Mapping: '1900de43010000000100000000010000,GPIO Arcade Gamepad 1,a:b0,b:b1,x:b2,y:b3,back:b6,guide:b8,start:b7,leftshoulder:b4,rightshoulder:b5,dpup:b9,dpdown:b10,dpleft:b11,dpright:b12,platform:Linux,crc:43de,'

[Gemba]

I provided another PR, without permanently changing the did->buttons value.

Even if you can not recreate it, you may recognize by reading the code that the current implementation will never resolve the upper DPAD buttons, when the physical button count is less than 15 and no hat/axis is reported by the gamepad.