[Custom Controls] not saved/applied when using DMX and --autoload

[nemo93]

Describe the bug I still have issue with Custom Controls and more Retropie users are reporting identical issues. You have 2 scenario and I decided to merge the 2 in a single ticket for now.

1. Custom Controls defined in XML are either applied ok (Banshee) or not at all (Zool).
2. Custom Controls saved in .uae are properly written down in that file yet not picked up by Amiberry.

To Reproduce where Custom Controls defined in XML

1. Run Banshee (AGA)
2. Bring up the GUI and go to Custom Controls
3. Check that 'West' is bound to 'Space'
4. Now run Zool
5. Bring up the GUI and go to Custom Controls
6. Check that 'North' is NOT bound to 'Space' as it should be ('None' instead)

To Reproduce where Custom Controls defined in .uae

1. Run any game
2. Bring up the GUI and go to Custom Controls
3. Assign some keys
4. Go to Configurations and Save the file
5. Check the .uae generated contains lines like eg. joyport1_amiberry_custom_none_b=F1
6. Run Amiberry with this .uae
7. Open GUI and check binding is not applied ('None' value instead) => some users report that opening/closing the GUI once will make the binding to properly appear. I can't confirm this on my setup.

Expected behavior Custom Controls to be applied either from XML and/or from .uae.

Additional context This is continuation of #956 given more Retropie users have reported similar issues. I'm using Banshee and Zool as examples provided their Custom Controls are quite simple. It's a single binding to one key/button. There's no blank or weird characters in the binding definition it's just one button assigned to the 'Space' key. I wonder how Custom Controls could work for one game and not for another. I've checked XML file values for Custom Controls are there.

I'm running 5.2 on Retropie 4.8 on Pi4. Buster / 32-bit / DMX. Everything (.uae, .chd, .lha) is therefore launched with the --autoload parameter.

[midwan]

@nemo93 Which Zool game instance are you testing with? There are several in the XML, and not all of them have assigned custom controls (e.g. the CD32 ones don't). If you are testing a CD32 one, it would be normal behavior to not have any custom controls, for example.

When I test it with Zool_v2.0_AGA_1675, I can see that North is mapped to Space as expected, in my dev environment (Manjaro Linux). However, testing it on the latest RetroPie afterwards, shows no Custom Controls indeed - so this seems to be specific to RetroArch environments, at least at this point. Needs further investigation...

[midwan]

Actually, if I use a retroarch config on Manjaro (to enable the retroarch-specific code), it still works as expected with Zool. So the problem is not related to retroarch itself, it seems. Perhaps SDL2 version?

Manjaro has 2.0.22 installed, but RetroPie is still on 2.0.10, which is quite older, and supported a smaller number of controller buttons/axes. At least we have some more info now.

[midwan]

I managed to recreate this, only under a single scenario:

• Use the DMX version (SDL2 one works fine always)
• Use the --autoload command line option (doing the same from the GUI works always)

Retroarch is not related to the problem, as I can now recreate it on non-RA systems as well, but only using the above combination.

[HoraceAndTheSpider]

Syntax appears to have changed - backwards compatibility would be ideal, otherwise we will need to update the custom files in the XML builder (which we can do) joyport0_amiberry_custom_none_b=F5. new layout joyport0_amiberry_custom_none_east=F5. old layout

[HoraceAndTheSpider]

More old syntax

joyport0_amiberry_custom_none_dpad_up=Cursor Up
joyport0_amiberry_custom_none_dpad_down=Cursor Down
joyport0_amiberry_custom_none_dpad_left=Left Alt
joyport0_amiberry_custom_none_left_shoulder=N
joyport0_amiberry_custom_none_north=ESC
joyport0_amiberry_custom_none_south=Space
joyport0_amiberry_custom_none_east=Right Alt
joyport0_amiberry_custom_none_west=Return
joyport0_amiberry_custom_none_start=F1
joyport0_amiberry_custom_none_right_shoulder=Y

vs new

joyport0_amiberry_custom_none_a=
joyport0_amiberry_custom_none_b=
joyport0_amiberry_custom_none_x=
joyport0_amiberry_custom_none_y=
joyport0_amiberry_custom_none_start=
joyport0_amiberry_custom_none_leftshoulder=
joyport0_amiberry_custom_none_rightshoulder=
joyport0_amiberry_custom_none_dpup=
joyport0_amiberry_custom_none_dpdown=
joyport0_amiberry_custom_none_dpleft=
joyport0_amiberry_custom_none_dpright=

[midwan]

@HoraceAndTheSpider The syntax was changed to comply with what SDL2 reports back as the "human readable" text for each button/axis, so we'll be sticking to that one going forward. The XML was already updated by @nemo93 to reflect that, so it would be best to update anything else relying on the old syntax accordingly.

But all of that is not related to this bug case, as the syntax was identical between the tests.

[midwan]

@nemo93 Possibly related bugfix, regarding the loading of .uae configs: https://github.com/BlitterStudio/amiberry/issues/986

[midwan]

@nemo93 I've finally managed to track this down. It only happens if SCREEN_AUTOHEIGHT is set to TRUE, and only on Dispmanx targets (since in SDL2 ones that feature activates AutoCrop, which is implemented differently).

[midwan]

Should be fixed with b603415ab1bd178ed6c1b339bff4aaade12aa5c5

[nemo93]

Another issue due to the 'old' platform I'm afraid. Thanks for tracking this down and for the fix. Retropie will be updated to 5.3 in the very short term.

[nemo93]

I'd like to reopen this ticket. The fix is working for Zool yet it's only partial for Indy Heat and Hammerfist for instance. For those 2 games just few controls are assigned not all of them. E.g. Indy Heat: only Cursor Up / Cursor Right / Right Shift are assigned.

[midwan]

Sounds a bit weird, as it's an all or nothing approach normally, but I'll take a look at those specific games to see.

[midwan]

Fixed as part of #1013