issues with RetroArch

[FollyMaddy]

I use ArchyPie now on Manjaro 23.x.x on my RPI4.
Found that on this OS somehow the params for building RetroArch are not correctly set.
RetroArch is compiled, however is complaining about not being able to switch resolutions.
In the login screen I can change between choosing "wayland" or "x11".
Tried both and got 2 non working retroarch binaries.

I stayed on "x11" and I used the params generated by the retroarch.sh module-script of RetroPie.
Pasting them in the build function compiled a working RetroArch for me.
There are a lot of params but with the ArchyPie version the x11 option is disabled.

Seems that some params are wrongly disabled resulting in a non working RetroArch.

So when I got a correct RetroArch working I noticed that the hash tables of lr-mess aren't found in the correct BIOS/mame folder.
I am not sure if this set somehow in RetroArch or if this setting has to be found in lr-mess.
Running lr-mess with RetroArch revealed that it uses the folder .config/retroarch/system/mame/hash.
That mame path is also used by lr-mess for more folders.

I tried to email you about these issues however [email protected] or [email protected] don't seem to exist.

[V0rt3x667]

Hi, if Wayland is detected then the X11 build options will be disabled and the binary will not work under an X11 desktop. I will look into the issue to see what is going wrong. Which desktop are you using? I use Budgie which is X11 only and RetroArch builds and works fine on an x86_64 machine. I do have Sway installed as well so I can test RetroArch on that as well.

[V0rt3x667]

I tested the binary built under an X11 environment on Sway with xwayland disabled and it worked fine. I built RetroArch under Sway again with xwayland disabled and it also worked fine. Looks like this may be a rpi issue. I only have an raspberry pi 2 and the last time I tested was under KMS and it worked fine. Do you have any error logs or messages? Thanks

[V0rt3x667]

I forgot to mention that if RetroArch is built under a KMS environment (no desktop) then the binary will not work under X11 or Wayland. I set it this way to create binaries without X11 dependencies for Wayland and KMS only users.

[FollyMaddy]

I use Manjaro with KDE plasma desktop on RPI4.

I can confirm that the retroarch binary on Manjaro KDE Plasma on my x86_64 VM works.
Checked the session type :

echo $XDG_SESSION_TYPE
x11

Will look at the lr-mess paths later.

Ineed, it looks like an RPI/RPI4 issue only.

When I can I will do the compiling again and add the log and the params created by the retroarch.sh script.

[V0rt3x667]

I have looked at lr-mess and I don't understand how it can work under RetroPie. The core clearly does not look for the hash folder under ${biosdir}/mame. I tried using the Coleco platform and it does not work due to not being able to find the driver which I assume it looks up in coleco.xml in the hash folder. I have also noticed an issue with how I set BIOS directories for the RetroArch cores, they are getting overwritten because retroarch.cfg is shared per platform by all cores supporting that platform. I don't want to have to patch harcoded paths for each core but I also hate throwing all bios files in a single unsorted directory like the RetroArch & RetroPie default. The lack of flexibility is frustrating!

[FollyMaddy]

Thanks for looking at the path/config issues.
You or we will sure find a solution later ;-)

Let's first focus on the params issues, agree ?

[FollyMaddy]

I added a picture with the differences between using the function build from the retropie version vs the archypie version.
( with the retropie params I had a working binary, compiling with archypie params was not an issue but the binary has resolution switching error )
Both params-lists are extracted on the RPI4 running Manjaro-kde-plasma 23xxxxx with x11 desktop selected now in the loginscreen.
I think these disabled ones should somehow be recognized and not disabled :
--disable-x11
--disable-xinerama
--disable-xrandr

[V0rt3x667]

Are you building from the setup menu or via ./archypie_packages because it looks like it is picking up the kms flag which is disabling both x11 & wayland.

[V0rt3x667]

Expected behaviour is:
Build under x11 and binary supports x11 & wayland
Build under Wayland and binary supports wayland & kms
Build under kms and binary supports kms only

The Retropie build supports x11 & kms but wayland is disabled. Looking at the text file screenshot.

I don't really want to enable x11 for kms builds because you should not need x11 dependencies for a gui-less build.

[FollyMaddy]

Are you building from the setup menu or via ./archypie_packages because it looks like it is picking up the kms flag which is disabling both x11 & wayland.

I did all the source installs via the setup menu loading the archypie-setup from the terminal.
When I had a non working binary I changed the retroarch build functions (retropie and archypie ones) to extract the params.
So I did the extracting with ./archypie_packages.

Question :
Should I load the archypie-setup from emulationstation instead so kms is disable and x11 is enabled ?

[V0rt3x667]

You should be able to run archypie-setup from the terminal and it should pick up the correct flag from XDG_SESSION_TYPE. I might incorporate this RetroPie/RetroPie-Setup#3686 as it looks less error prone than I how I have it set. For now I will set RetroArch to build like Retropie.

[V0rt3x667]

I have removed those disabled x11 options. If you could please update and test it again. Thanks

[FollyMaddy]

Great ! 👍

I tested the update and installed a working retroarch from source on x11.
I think the update doesn't break building for KMS only users or at least I hope so.

Apparently, other things have been improved now too.
I had issues with the F-keys not being recognized in lr-mess, it does work now with using this retroarch binary.
Also noticed that for handhelds in lr-mess, like kgradius, that no -frameskip 10, is needed anymore. A good thing too.
Though, don't know what is responsible for these improvements.

Strange though that the platform seems to be detected as kms in the script.
I have tested what the array ${__platform_flags[*]} from the function isPlatform() contains, this contains :
rpi4 64bit aarch64 rpi gles gles3 gles31 gles32 kms mesa
So the XDG_SESSION_TYPE isn't added to the array somehow.
If that is somehow fixed then also wayland could benefit.

Edit :
In system.sh the variable ${__XDG_SESSION_TYPE} is used to determine x11 and wayland.
Somehow the variable isn't filled correctly via the display variable that is read from the original XDG_SESSION_TYPE variable in archypie_setup.sh or archypie_packages.sh.

[V0rt3x667]

That's great thanks for testing. __XDG_SESSION_TYPE is a global variable for archypie storing the contents of the variable display which in turn stores the value of the envar XDG_SESSION_TYPE. It's very hacky and not very robust it appears either! I prefer the way that gizmo98 has come up with, it can be modified for use on all the platforms not just native.

I got coleco games working on lr-mess by storing the bios/device file in the roms folder. This is not ideal as it appears software list are like split roms. Not sure if the core can read from mame.ini so paths can be set like MAME standalone.

[FollyMaddy]

What is the solution that gizmo98 came up with ?

Btw:
FYI I don't use sudo starting archypie_setup I do however with archypie_packages.
That's the way to do it ,right ?

Indeed your lr-mess solution isn't ideal.
I think reading a mame.ini could be possible adding it in the core options or adding it to the runcommand.
However, that is also not an ideal solution and I have never experimented with that.
I will have a look later.

[V0rt3x667]

Sudo should not be used with ./archypie_packages either. It won't generate a warning though as I could never get the warning to trigger. Sorry I forgot to mention that earlier! The unmerged change to RetroPie is RetroPie/RetroPie-Setup#3686 I have created a new branch to test it.

I thought my lr-mess script is the same as the RetroPie one. Does it work correctly in RetroPie by using the mame bios directory?

[FollyMaddy]

Sudo should not be used with ./archypie_packages either. It won't generate a warning though as I could never get the warning to trigger. Sorry I forgot to mention that earlier! The unmerged change to RetroPie is RetroPie/RetroPie-Setup#3686 I have created a new branch to test it.

Happy to test if you add the changes ;-)

I thought my lr-mess script is the same as the RetroPie one. Does it work correctly in RetroPie by using the mame bios directory?

Indeed my initial look was that it was somewhat the same.
I even added a hotkey_enabled key to the regular /opt/archypie/configs/all/retroarch.cfg to test if it would load and it did.
So I would assume that the bios path would also be picked up ,but I was wrong.

I checked it manual, in the CLI, with next commands :
/opt/archypie/emulators/retroarch/bin/retroarch --config /opt/archypie/configs/all/retroarch.cfg -v -L /opt/archypie/libretrocores/lr-mess/mamemess_libretro.so 'mame -showconfig'
Which gives the correct paths.

For a system/driver I used the system specific retroarch.cfg like this ( <system> is for example coleco, I used msx2 ) :
/opt/archypie/emulators/retroarch/bin/retroarch --config /opt/archypie/configs/<system>/retroarch.cfg -v -L /opt/archypie/libretrocores/lr-mess/mamemess_libretro.so 'mame -showconfig'
Now I get wrong paths because just as you told, I saw that the system specific retroarch.cfg was already overwritten earlier and that it has the wrong system paths in it, like this one :
system_directory = "~/.config/retroarch/system"

So my hotkey_enable_key option works because it's not in the system specific retroach.cfg and therefor, when it redirects to the all retroarch.cfg it is used. For the system_directory that is not the case.

EDIT :
I completely removed my msx2 install including the msx2 specific retroarch.cfg manually and installed it again with my script (driver hbf700p).
The problem seems to be gone now.
When I load the RetroArch gui it shows that writing the config is off, so no wrong system_directory is written, so it works with my script now.
Seems the system specific retroarch.cfg was somehow written when using/testing earlier retroarch binary versions.
For now it seems to be no issue anymore.

Will have a look later at how the standard coleco will do.

[FollyMaddy]

I tested the standard coleco, indeed it works when placing the coleco bios inside the roms/coleco path.
As far as I can remember retropie has the same issue.
A fix could be to create a runcummand in the lr-mess module-script that is slightly more advanced adding the rompaths, like this :
lr-mess = "/opt/archypie/emulators/retroarch/bin/retroarch --config /opt/archypie/configs/coleco/retroarch.cfg -L /opt/archypie/libretrocores/lr-mess/mamemess_libretro.so 'mame coleco -rompath /home/pi/ArchyPie/BIOS/mame;/home/pi/ArchyPie/roms/coleco/ '%BASENAME%''"

[V0rt3x667]

Strange that this core will not find coleco.zip under the mame bios directory. I wonder if other softlists are the same? I will test the other systems set under lr-mess.sh.

On another note I am going to abandon the distinction between x11 and wayland. After doing further research there really is no accurate way to determine which session is running. If you want to build a binary via SSH for x11 or wayland it will not work due to the session type being set to tty. I will just set the scripts to build for both so the binary can be used when swapping between the two. I will let you know when I updated this.

[FollyMaddy]

Looking at the RetroPie docs it is how it originally worked with coleco, see here.
So it has never been made to find the bios in the BIOS/mame directory.

Good to hear you will try to abandon the distinction between x11 and wayland I think thats a good thing with swapping between them.
Though we still have the issue with not passing through the __XDG_SESSION_TYPE variable correctly when using Manjaro 23 on RPI4.
Or do you want to create combined binaries, KMS+X11 and KMS+wayland, when kms is detected ?
Indeed then it doesn't matter if the __XDG_SESSION_TYPE variable isn't passed.
Just and additional idea next to yours, why not try and use the default XDG_SESSION_TYPE variable instead to see if it adds to the flags.

[V0rt3x667]

Thanks for looking into that. For some reason when you run a script or command using sudo you cannot retrieve the value for certain envars like XDG_SESSION_TYPE. If I remember correctly you have to change a configuration file in Linux to change this behaviour. The only way I found to circumvent it is the one I used in the script. I never considered the impact on using SSH to run the script and build binaries or on people switching between x11 and Wayland sessions on desktops that support switching. I believe GNOME is going to remove switching by default.

For the sake of supporting all possible scenarios I will revert it back to the default RetroPie behaviour for the main branch. So binaries will either be X11/Wayland combined or KMS only. I have created a new branch test_video with modified changes for my own use and testing that retains the distinction between x11,Wayland & KMS.

[FollyMaddy]

Ok, thanks for the info.

[V0rt3x667]

I have now reverted back to how RetroPie works in the main branch.

[V0rt3x667]

If it is ok with you I will close this issue. Thanks

[FollyMaddy]

That's ok.