amiberry
amiberry copied to clipboard
BlitterStudio
Gamepadcontrollers with less than 15 buttons do not get all button functions mapped
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:
- Have a gamepad controller connected with <16 buttons defined. The controller does not report/use a hat.
- Have it configured in RetroPie / EmulationStation
- Launch Amiberry
- 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.cfgis 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_realcontain the pyhsical buttons, assetup_mappingis using the full 15 buttons. But for some reason the buttons reported frommap_from_retroarch()don't end up in the final result. - If you can provide some hints I could implement and test a fix
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.
- 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.
- 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.
- 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?
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.
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).
@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?
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.
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.
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.)
@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.
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).
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.
OK, let me see if I can find any controller here that has less buttons and they are mapped as such, instead of axis.
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++)
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.
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.
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.
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.
Just buttons used, and they were sequential as well (button 0 until button 7).
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?
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
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.
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.
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).
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)....
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,'
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.
Coming back to this, after some time. The PR you provided, only affected the case where the gamepad is used as an SDL Controller, with the mapping applied to that. However, you mentioned that the issue only happens when using RetroArch mapping, which overrides any controller mapping of course. When Retroarch is detected, Amiberry skips the controller mapping and uses that instead. Therefore, your PR did not apply for retroarch mapping at all, so I don't see how that could possibly help resolve this.
Either the PR was incorrect, or if it did indeed resolve the issue, the description of when it happens is incorrect. But based on the tests you reported above, it seems that it works fine with the default controller mapping if you bypass retroarch, so I'm inclined to think that the problem is in the PR itself.
If you're still interested in finding a working solution for this, let me know. As I cannot recreate the problem with any controller I have here, it's a bit hard to find something that works, without verification/testing.
Thanks, yeah has been a while.
Let me sum up my findings so far. As I stumbled across this when trying to use the arcade-dt [1] driver I will start with that and then give some advice on how to reproduce it with any USB-controller.
The arcade-dt driver provides a full gamecontroller with buttons and dpad and no (analog) axis and hats. It runs with all buttons+dpad detected
- in any retroarch based libretro core.
- in the "native" SDL based emulators which do initialize SDL_INIT_GAMECONTROLLER, those which only do SDL_INIT_JOYSTICK do miss some if not all buttons
IIRC Amiberry does also use SDL_INIT_GAMECONTROLLER, thus I assumed it should behave like the "native" (i.e. not libretro cores) emulators.
Now, how to elicit this behaviour with an USB-Controller? I guess you did change the RetroPie / retroarch controller mapping to all buttons and assigned the dpad directions to some spare buttons (L/R button, aso.) but not using the physical D-pad of the controller. (cf. https://github.com/BlitterStudio/amiberry/issues/1493#issuecomment-2643520270) Additionally it is crucial to forcefully remove any hats and axis' from the SDL-reported set. (That's the second part of the comment I just linked to). The button count should be set static to 13 for example and the reported buttons count from SDL should be ignored (see also the patch in the comment I linked).
What then happens is that input_left_btn and input_right_btn from this array are still parsed from the retroarch controller config, but later this loop stops at 13 and not at 15 (or higher), in turn these buttons are never read during the game loop and that is what I noticed in the Amiga Test Kit.
HTH
[1] https://github.com/gemba/arcade-dt
@Gemba OK, so then I understand that there are some important details:
- The arcade-dt driver works properly when mapped as an SDL GameController
- It's missing some buttons when mapped as an SDL Joystick
Assuming the above is correct, that corresponds to the discussion earlier - that when the Retroarch mapping is bypassed, it works as expected in Amiberry. Which is normal, considering that Amiberry disables the SDL GameController mappings when Retroarch is detected, in order to use the mapping from there (retroarch uses joystick mode and generates a mapping based on that).
Could it be that the issue here is the retroarch mapping then?