|Jeroen De Meerleer 3992804fe2
(fork of Kodi Standalone Service by GraySky2)
Run RetroArch as an unprivileged user in standalone mode without the need for a full Desktop Environment. X11, Wayland, and GBM are supported.
Which one to choose?
In terms of functionality, X11 is probably the most mature and feature rich. Wayland is next in line and should be considered on-par with X11, however, a known limitation of Wayland is having the resolution and frame rate set in the compositor rather than in retroarch's GUI. As well, Wayland currently does not support VT switching. GBM has some known features it lacks compared the X11 and Wayland. A complete list can be found in RetroArch issue 14876.
Another factor that may affect choice is the number of dependencies required to run which will vary distro-to-distro.
Arch Linux users (likely users of Arch clones) can find a PKGBUILD in the AUR that will take care of everything. Simply install and use.
Other distros/manual installation
Users of other distros can just run
make install as the root user. Then, as the root user, run:
Note that the retroarch user's home directory is
/var/lib/retroarch/ in this example, NOT
/home/retroarch/ like a regular user.
Note that I list some dependencies below that the Arch package already has listed as dependencies. This is to help users of other distros whose retroarch packages may not have these listed. If you're installing this from the AUR package listed above, just pay attention to pacman's post-install message which calls out the Arch-specific
optdepends needed for the various service files to work.
- retroarch (>=19.1 on Arch Linux, lower versions may work with other distros)
- cage, libinput, and xorg-xwayland (for running wayland)
- libinput (for running gbm)
- xorg-server and xorg-xinit (for running x11)
Notes for users of non-Arch Linux distros
Users of Ubuntu ≥20.0 will need to edit
/etc/sysusers.d/retroarch-standalone.confand uncomment the line adding retroarch user to the
Users of Ubuntu wishing the retroarch user to access devices on
/dev/ttyxxxx, will need to edit
/etc/sysusers.d/retroarch-standalone.confand uncomment the line adding the retroarch user to the
Notes for Users of RPiOS
To use this with RPiOS requires a few extra steps.
- Set the boot preference to boot to the console, see https://github.com/graysky2/kodi-standalone-service/issues/37
/usr/bin/retroarchwith vanilla upstream's version. See here for an example that is known to work with RPiOS as of Matrix-19.3.
Simply start/enable the requisite service.
Passing environment variables to the service
Certain use cases require environment variables to be passed to the service. Define these variables in
/etc/conf.d/retroarch-standalone and they will be passed along to the service.
Notes on system shutdown/reboot
Be aware that these services run RetroArch in systemd's user.slice not in the system.slice. In order to have RetroArch gracefully exit, the system should be called to shutdown or to reboot using the respective RetroArch actions not by a call to systemctl. Failure to do so will result in an ungraceful exit of RetroArch and the saving of GUI settings, RetroArch uptime etc. will not occur. In principal this is no different than data loss occurring from a user doing work when a sysadmin issues a reboot command without prior warning. While it is possible to run RetroArch in systemd's system.slice instead, doing so makes it difficult to use USB mounts within RetroArch and to use pulseaudio for RetroArch sessions.
Much of the credit for this service goes to the Arch Linux maintainers of the official retroarch package. Note that they removed it upon the 1.16-1 release of Xorg.
Tips and Tricks
Service not starting
Most users should not need
/etc/X11/Xwrapper.config since the created X server becomes the controlling process of the VT to which it is bound. Most users does not mean all users. There have been reports of some AMD users still requiring this file. As well, users of Xorg's native modesetting driver may also require it.
The recommendation is to first try starting
retroarch-x11.service without it, but if the service fails to start X, you may need to create
/etc/X11/Xwrapper.config which should contain the following:
needs_root_rights = yes