Assure mapping of all buttons of game controllers with less than 15 buttons

[Gemba]

Fixes #1493

Changes proposed in this pull request:

• If a gamecontroller reports via a Retroarch Controller config file less than 15 buttons (e.g. a RetroPie Setup) not all buttons got mapped
• This can happen for example if a custom controller is connected via GPIO, ready-made USB connected controllers are most likely not affected, I tested with a few
• This is a proposed fix, please let me know if you see knock-on effects

@midwan

[midwan]

I'm a bit confused by the proposed fix here.
Wouldn't hardcoding a minimum of 15 buttons, show you more buttons than are actually available on your joystick in some cases? There are certainly controllers out there with less buttons available.

I guess it's hard to understand the issue, without having a way to recreate it here. Are you saying that the controller reports less buttons than it actually has, so there are some with a missing mapping?

[Gemba]

Wouldn't hardcoding a minimum of 15 buttons, show you more buttons than are actually available on your joystick

In the Custom Controls menu in Amiberry only the physical buttons (i.e. these which the controller config file reports) are enabled. All others are greyed out / disabled.

Are you saying that the controller reports less buttons than it actually has

In retroarch.cpp, all buttons are reported, but later in the processing they get "cut off".

For instance, an Controller with 13 buttons will be processed without the Left and Right (the 14th and 15th element of the mapping table).

You may simulate this behaviour with any controller on Retropie, if it is helpful on your side:

• Set hardcoded 13 in this line instead of the function call to SDL... (if you set 12 you will notice that Down is also not available in Amiberry Test Kit, with 11 you don't get any directional buttons mapped).
• Have a Retroarch contoller mapping config file for the real controller you are using.

Mine looks like this for a DB9/Atari controller:

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 way you should able to reproduce the effect.

[midwan]

Do I understand correctly then, that this is really a GUI issue?
I'd prefer to make changes in the GUI instead, if it fixes the problem, instead of messing with the actual number of buttons returned from the device itself.

If the problem is that custom controls disables the dropdowns for any non-existing buttons, we can probably fix that in the GUI Panel there.

[Gemba]

Do I understand correctly then, that this is really a GUI issue? I'd prefer to make changes in the GUI instead, if it fixes the problem, instead of messing with the actual number of buttons returned from the device itself.

In the GUI (=the Amiberry configuration menu) all gamepad movements are functional (in this case Left and Right work in the GUI). However, the Left and Right movement do not work in-game or in the Amiga Test Kit.

If the problem is that custom controls disables the dropdowns for any non-existing buttons, we can probably fix that in the GUI Panel there.

In the Custom Controls the available buttons do reflect the actual buttons (i.e. those listed in the Retroarch Controller cfg file). Buttons not available are disabled/greyed out. No issue here.

[midwan]

Sorry, I'm still not 100% clear on where the issue is here. Let's try to drill down to what we have so far.

• It works fine in the GUI. This is not surprising, since no custom mapping or retroarch config is used there, only Amiberry's own default basic controller mapping (basically directional input and buttons for Confirm/Cancel).
• Custom Control dropdowns show correctly - only available buttons are enabled, and the rest are disabled. This means that the number of buttons reported by the SDL_JoystickNumButtons function is probably correct (?)
• In-game controls are not mapped for some buttons, when using the controller's Retroarch .cfg file
• In-game controls are mapped correctly for all available buttons, when not using the retroarch mapping file (?)

Did I get all the above correctly?

[Gemba]

Sorry, I'm still not 100% clear on where the issue is here. Let's try to drill down to what we have so far.

Nvm. The perils of remote co-op. :)

* It works fine in the GUI. This is not surprising, since no custom mapping or retroarch config is used there, only Amiberry's own default basic controller mapping (basically directional input and buttons for Confirm/Cancel).

Confirmed from my side.

* Custom Control dropdowns show correctly - only available buttons are enabled, and the rest are disabled. This means that the number of buttons reported by the `SDL_JoystickNumButtons` function is probably correct (?)

Confirmed from my side.

* In-game controls are not mapped for some buttons, when using the controller's Retroarch `.cfg` file

Confirmed from my side, iff there are less than 15 buttons configured in Retroarch's controller .cfg file.

* In-game controls are mapped correctly for all available buttons, when not using the retroarch mapping file (?)

Confirmed from my side, when the Retroarch's controller .cfg is moved away the mapping is as expected.

[midwan]

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. :)

I'll give it a try with the retroarch config you pasted above and see where we get. But this PR as it stands, will not be merged for now.