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

[NoobieMaks]

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

[midwan]

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

[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]

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]

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]

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 930d8fb - 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.