Controller has no function in the game (amiberry-v5.7.3-debian-buster-armhf-rpi3)

[NoobieMaks]

@midwan Thank you so much for your efforts and your Buster binaries for rpi3!!! It's really no pleasure for me to write about my test results:

I do the simplest start a user of RetroPie can do. I start the games from the RetroPie Emulaton Station section Amiga, I think you would say it's a start from the console via command line.

The games start, but I have no game function of my controllers (tried PS3 wireless and DragonRise wired). ISSUE I can go into the Amiberry GUI per retroarch Hotkey-binding. OK I can see the custom controls pre sets of the XML-file. OK I can navigate and change everything I want with the controllers -OK-, but when I leave the GUI back to the game I only get an abort and fall back to the Emulation Station screen of section Amiga. ISSUE

So I have currently 2 big problems:

• No function of my controllers in the games
• No possibility TO CHANGE something in the GUI panels AND going back to the game TO SEE what it has done to the game,
• as a consequence of that it is no more possible to start a savestate, it also leads to the abort

Changes in the GUI panels are only possible if I save them per uae-file, then I can see these changes at the next start and entry of the GUI, but when I want to go back to the game I fall out of Amiberry. In this way I tried different controllers and also different modes (Default, Joystick, Gamepad, Analog Joystick, CD32 pad), nothing made it better.

_For me is still 5.7.0 the best version for my simple usage of RetroPie, I just want to run the games direct from the ES with the button functions which are coming from the slave and/or from the XML-file. If they are not appropriate for me I want to overwrite them per uae-file. BattleIsle was not possible to start, also not with the C1=3 trick in the uae-file, starting via savetate was my workaround. And overwriting of XML custom controls was also not possible but with editing/clearing the XML-file it was managable.

Maybe my logfiles can give you some hints to my problems. amiberry.log_withoutuae.txt amiberry.log_withuae.txt

[midwan]

I'm sorry you're facing issues. I think the crash you're seeing only happens in Buster, as I cannot recreate it anywhere else. It's either related to the SDL2 version there, or a system library - I guess both are older and probably contain bugs regarding KMSDRM. The older version worked because it used only one window, the newer versions use separate windows for GUI and emulation, and probably trigger the issue due to that.

But what I'm not sure about is the controller input. That should have worked, at least with the defaults. We went through several days of testing it (together with custom controls loading) before the release, so I find it very surprising that something doesn't work for you there.

I'll need to investigate this on RetroPie itself, as it seems to be the only place where it can be recreated.

[midwan]

I can recreate it on RetroPie, possibly an issue when using Retroarch mappings. You can expect a fix ASAP.

[midwan]

For the record, it does not occur on the latest Debian 12 when installing RetroPie on top of it. I tested setting up a VM for that, but it works normally there, which leads me to believe it's not related to retroarch, but perhaps older versions of libs (like SDL2), which Buster has.

[giantclambake]

FWIW, I was getting crashes in libc.so.6 on debian buster (amd64 x11) some time ago with amiberry (occurred with window creation) ; at the time, I dug into it and believe I determined the cause to be Glibc version. That observation had me conclude the quickest resolve, was to update to debian bullseye, as that was the only way to get to a newer Glibc version ~ it of course worked, after upgrading to bullseye, the issue went away and amiberry started and runs fine (same since the update to bookworm). The 'clue' to all this, was my LFS 11.3 build, which has glibc-2.37 and didn't display any problems (used gdb/strace on debug builds of amiberry, comparatively, to find the root cause...in glibc =)

In this case wrt arm, and the failure of __default_rt_sa_restorer, even now (glibc-2.38.x) debian are still patching that call in arm/libc_sigaction.c ..which of course haunts my hate for coincidences.

In a week or so, debian buster gets relegated, being at the end of it's LTS cycle. "In a perfect world", I suggest RetroPie should release a debian bullseye (at least) compliant package, as I feel these sorts of issues will simply 'go away'.

The controller issue is a different problem of course ;) That said and as above (colloquially)..."If only they could hit a bullseye, we'd have a winner!"...

[midwan]

Unfortunately I cannot seem to be able to use a VM to setup Buster + RetroPie here either. I've installed Buster in a VM, then added the RetroPie-Setup script, which seems to work mostly, until this step:

So I'm afraid this will have to wait until I get back to an actual RPI for testing further.

[midwan]

Another minor update, as I got a few hours to look into this yesterday:

• This only happens if using Retroarch mapping.
• If we skip the retroarch mapping (by for example, changing the path Amiberry looks for retroarch controllers/configs), then Amiberry uses the normal mapping and controller handling, and things work fine there.
• The issue happens because of the changes in 930d8fbd39968a66b9e4dfa7a7c6e2aefaca57a7 - In that commit, a change was made to only trigger a re-importing of joysticks (and therefore, of their mappings) if the joystick GUID was not already initialized before. This change was needed, to avoid losing custom controls after loading a config file and starting emulation, as when joysticks got re-initialized, they got their default mapping applied again (or retroarch mapping, in the case of RetroPie). That would overwrite the custom controls that would be contained in the config file.

I'm planning to do some more tests to see how this can work for RetroPie under Buster. I'm still not sure why, but it works fine on RetroPie under Bookworm, when I tested the same thing in a VM.

[giantclambake]

Considering what we found that was participle to that commit, you'd have to suspect something in the SDL2 versions has something to do with it...ie; it's a big leap from SDL 2.0.x to SDL 2.26+...

[midwan]

I actually managed to recreate the same issue on the RPI5, when using a retroarch.cfg and retroarch-generated cfg file for my controller. Which is good in a way, because that means I don't need RetroPie to test/fix it (which itself is a pain).

[giantclambake]

What grinds my gears, is this...

....it's one thing to state that ~ it's quite another to provide a link pointing folks back to the buster release...sad...

...on the plus side though, it's enough incentive to install RA here, to provide a wider testing coverage ;)

[midwan]

@giantclambake Careful about installing RetroPie on top of your existing system, as it can bring in its own versions of libs (like SDL2) and break things. It's not a clean, isolated installation.

But you don't need the whole of RetroPie to test things that use RetroArch mapping. It's enough to use the retroarch.cfg file in conf and a mapping for your controller (named exactly as it's detected in RetroPie) in the controllers directory. If those two are detected, Amiberry will automatically load them up and skip the internal/default controller mapping.

Note: Things work fine with the internal controller mapping on RetroPie as well, they only seem to break when using the retroarch mapping.

[giantclambake]

@midwan Thanks for the warning and testing details ~ that's given me enough to sink my teeth into...

[midwan]

The above commits seem to have fixed the issue, but I only did a quick test (with and without custom mapping on the controller). Would be good to do some more extensive testing regarding Joysticks, with more controllers (I've only tested it with a PS4 one).

[NoobieMaks]

@midwan I guess I cannot help testing with my PS3 or Dragonrise Controllers because of my RasPi 3 buster RetroPie version. Therefore I would need a apropriate binary, isn't it?

[giantclambake]

@NoobieMaks --- yes, if you can't compile from the git branches, you'll need wait for a binary to test the changes.

[midwan]

@NoobieMaks

Here's a build of the current master branch, for RPI3, 32-bit, Buster. Let me know if this helps with the issue you had.

amiberry_master_rpi3_buster.zip

[NoobieMaks]

@midwan Thanks a lot for your new master binary.

I tested it and will tell you what I saw:

1. controller function general:

   • seems to work now as it should do, tested with Gremlins 2:
   • default XML custom controls are shown in the GUI and also recognized in the game
   • until they are overwritten with an personal uae-file = perfect

2. controller function "D-Pad right"

   • There must be something wrong in the background, because everytime I push this button to move my character in the game the Amiberry GUI window opens, which leads to my next problem (see 3.)
   • I also can't overwrite this behaviour with the uae-file (DPad right= Joy2 right) - does not help - it always opens the GUI

3. When I am in the GUI there is no chance for me to go back to the game, when I do so the game aborts

   • I think you already explained why this happens (https://github.com/BlitterStudio/amiberry/issues/1363#issuecomment-2179944421), but this doesn't help me for using your new binary, because I would not be able to use save states

4. VKBD and WHDLoad

   • I tested both functions with Battle Isle (issue with C1=3), and they work as expected

So I can summarize that the controller issue is nearly solved perfectly, I guess you will find the wrong background mapping to D-Pad right very quickly.

In my excel-file you can see that now all my issues would be solved but the abort-issue makes all useless for me, because I can't use save-states or all other GUI-in game-corrections/adaptions.

[midwan]

@NoobieMaks Hm, I cannot recreate the D-Pad issue you mentioned above. Is that using the DragonRise controller? It sounds like it's mapped to the Enter GUI event, maybe a combination with the set hotkey is incorrectly being picked up? Hard to say without seeing it here, and stepping through the code when it happens.

I'll see if I can recreate it using various other configs or controllers.

[midwan]

I can't really recreate it here I'm afraid, with my configs and controllers. I'm guessing it has to do with the controller mapping you have there, possibly with the button configured as a hotkey.

[NoobieMaks]

@midwan Sorry for the late answer, summer flu.

So I tried my 4 different types of controllers/connections:

• DragonRise = my selfmade Arcade-Joysticks don't have any D-Pad, so no problem (wired Controller)
• PS3-Controller - wired = no problem -> D-Pad works fine
• PS3-Controller - BT connected via sixaxis-driver = no problem -> D-Pad works fine
• PS3-Controller - BT connected via ps3controller-driver = D-Pad right opens the GUI! - only in this constellation I have the problem I can't see the difference in the controller configs, if you also want to take a look on it take the ones I have already uploaded (https://github.com/BlitterStudio/amiberry/issues/1355#issuecomment-2166430097) Or should I give you some other files to solve the riddle?

I really never took any D-Pad button as hotkey, so no idea where the problem could be located. But this would not be a problem for me anymore because I know now that using the sixaxis driver does not have this issue.

A certain time I thought I have to use the ps3controller-driver for my whole RasPi-baby to get rid of the very unfunny "ghost input problems" I had with my PS3-Controllers, because I read that this driver is not so sensitive to this problem, but now I know that was stupid, now I know the problem is the controller itself, when you open the controller and renew the foam-pad direct under the analogstick the issues are gone. So simple! So no importance for me anymore for the ps3controller-driver, the sixaxis is better, open for more.

[NoobieMaks]

@midwan @cmitu Please allow me a question regarding the current amiberry version using the RetroPie-Setup update from source or binary. Which version is there now available? Is it still the 5.7.1 with some manual (cmitu) code fixes taken from 5.7.2? Or is it any newer? Best case would be the new 5.7.4/master I tested here above. Where can I see this easily? Especially possible differences between source and binary? My point of view is - RasPi 3B Rev. 1.2 - RetroPie 4.8.6 buster

[midwan]

@NoobieMaks If the issue seems resolved with my latest commits, then I suggest we move forward with a new release, which will allow the RetroPie team (@cmitu ?) to use that as well, if they wish.

I can include a Buster-based pre-compiled binary for this version as well, since this was a bug that affected the previous releases, so we should have a "final" working version at least.

[cmitu]

Please allow me a question regarding the current amiberry version using the RetroPie-Setup update from source or binary. Which version is there now available?

You can see what Amiberry version (and git commit) you have installed from RetroPie-Setup, from the Package version information menu of the packge itself.

Is it still the 5.7.1 with some manual (cmitu) code fixes taken from 5.7.2?

For the RaspiOS version based on Debian Buster, yes. Newer version are getting 5.7.2 or - for x86 platforms - the 6.3.3 version.

Also, please ask RetroPie specific questions in the RetroPie forums.

[NoobieMaks]

@midwan Indeed, the issue seems resolved to me! I would even say amiberry seems perfect to me now. New release would be great. A "buster-based pre-compiled binary" is not useable for me, isn't it? Because of the GUI-abort-issue of my RPI3-RetroPie-Setup? Am I right, I have to wait until cmitu has included the new bugfixes in the last RetroPie package for Buster (amiberry 5.7.1 with manually integrated bugfixes of 5.7.2 and hopefully soon also the bugfixes of the upcoming 5.7.4)?

@cmitu Sorry to bother you again in the wrong forum. Can you please give me the links for the correct RetroPie forums I have to observe for amiberry news, where I can see when a new amiberry version is available for my RaspiOS based on Debian Buster. Because the current version has issues which would be solved in the upcoming new release from midwan.

[midwan]

@NoobieMaks Not sure what triggers that for you, so I can't say. If you need a DispmanX version, then you'll have to get it from RetroPie's setup indeed. Otherwise, the SDL2 one will be available in the Releases, so you can give it a try and see.

[NoobieMaks]

@midwan I think the trigger for my amiberry version is the RetroPie version I use. I have a RPI3B (also my friends) and so I use the only download version for it from RetroPie.org.uk.

This means I don't use amiberry standalone, I use it as a part of the also very great RetroPie project environment. I use more than 1.000 arcade games there and also pcengine, nes, snes, n64, nds, megadrive, masterdrive, psx, ports and gb games. But Amiga games have been my youth, I had a very fine Amiga 500 and a large collection of games - so amiberry is a kind of favourite for me. Thats why I try to help to make it better also for my old platform. No idea how I could install a SDL2 version into my RetroPie build instead of the default DispmanX version. I will say, I never had a choice in there.

I thought only the DispmanX version can run under the Buster RetroPie Version, thats the reason why RetroPie (cmitu or ?) had to freeze amiberry with 5.7.1 there and all new bugfixes must be done now with manual edits.

[midwan]

On a Pi3, your best bet for decent performance is the Dispmanx version, so you'll have to wait for RetroPie's update in that case.

On anything faster, the SDL2 version is preferred.