RetroArch for SailfishOS 4.5

I’ve backported RetroArch for SailfishOS 4.5
It is available at: Release release-20240113173734 · smokku/RetroArch · GitHub

First thing to do after installation is to go to:
Online updater / Update assets
It will download assets required to properly render the User Interface.
Then update the basic information files. The rest is not necessary (but recommended).
Then the Emulation core download should work.

The cores are extracted from Lakka-RPi3.aarch64-4.3.
Unfortunately SailfishOS has very old GCC 8 with old libstdc++ library incompatible with cores using C++, so I removed these.

In order to be able to play using touch screen, you need to enable controller overlay.
Download overlays using online updater.
Go to: Settings / User interface / On Screen Display / Screen Overlay
Enable overlay and select an overlay from gamepads/ directory.

I tried configuring the Assistant button to open the core menu (default binding F1), but failed to do so.
It should be possible when using udev keyboard driver according to Xperia 10 III support - #173 by remote

Always use the “Close RetroArch” menu item.
Closing the app using gesture will keep the emulator in background and eat your battery.

Known issues:

  • app stays in background
  • sometimes crashes when reinitializing Wayland window (I probably messed up something when restoring wl_shell support)
  • landscape mode - This is not supported by RetroArch. RetroArch assumes the OS does the screen rotation (either on the system framebuffer or XRandr)


Much appreciated thanks :+1:
EDIT: updating the database makes the app crashes on 10 III :frowning:

There is some issue with the way Wayland surface is re-created and it crashes.
Just re-run and it will be working fine.

I’m trying to setup an automated build via OBS, but I have difficulty configuring the build to use pkg/sailfishos/retroarch-sailfishos.spec as the SPEC file. By default OBS expects it in SPEC directory.

Does anyone know how to configure it?

Is there BT gamepad support?

BT gamepad should work if it is a BT-HID device.
These should work when you switch to udev input driver.

Is it possible for this app to have a more SFOS looking UI?

You can go to Settings » Drivers » Menu and change some settings.

The spec file must be in the rpm subdirectory if you are using a tar_git service file.

Oh well… I guess I will then build and release it manually.

Can’t you just move the spec?

Another way would be to have a “packaging repository” with this structure:


where the “upstream” dir is a git submodule pointing to your fork. You then give this repo’s URL to the _service file.

(note that with this structure, you need an rpm setup line like this: %setup -q -n %{name}-%{version}/upstream so that the OBS builder can find the right source tree.

1 Like

One question: if I build a core .so myself, where on the system should I install it so your package will find it?

Background is: I have a native build for dosbox_pure but haven’t been able to test it.

I was thinking about using /usr/share/retroarch/cores/ would that be ok?

Would you consider to publish this native build?

Sure. you can monitor this space:

But none of the stuff is currently tested. I haven’t even installed the build results, focussing on packaging at the moment…

Once it’s done I can either push to Chum, or create some kind of “release” repo on OBS.


Good, I’ll be looking for it, be sure :wink:
Retroarch is a nice new app to test and enjoy

1 Like

if I build a core .so myself, where on the system should I install it so your package will find it?

Cores are being downloaded to .config/retroarch/cores.

You will also need corresponding .info file.
(But these should be automatically downloaded by the online updater.)

Thanks. that is a problem for packages though, as they MUST NOT install into user dirs (home).

Is it possible to configure more than one core search path?

The package does not install to user dirs.
The app itself (the built-in updater) downloads to user dirs, which are configured as accessible for storage.

No, yes I understand that.

But if I (or anyone) builds a core, and makes an rpm package from them, that rpm can’t install to home.

Instead, I’d choose something like /usr/lib/retroarch/cores or so.

Question is, can your retroarch be told to look in both locations, the one in home and the /usr/lib one?

You can change the location of cores: Directory Configuration - Libretro Docs

If you point it to a read-only directory, the updater will not be able to download cores though.

There is a workaround I think.
Your package can copy/link the core to user-dir in a post-install script.