Raspberry Pi 5 - official announcement

mitu

@moio said in Raspberry Pi 5 - official announcement:

Should I open a GitHub issue?

No, it's a known issue with kodi and RaspiOS Bookworm. Has been reported to the RaspiOS folks. Also, Pi5/Bookwom support is preliminary, so there's no use to open issues for it.

retropieuser555

Has anyone seen a query on raspberry pi forums, bookworm or dolphin GitHub why you can load Dolphin, AetherSX2 via GUI but not while in terminal/CLI and you get that QT5 error above?

It seems odd and I'm not quite sure where the issue is, as it occurs on Ubuntu 23.10 & raspberry Pi OS Bookworm. So it doesn't seem a problem specific to the OS? Or it's purely hardware (pi or arm64) specific? As it seems to occur on pi4 using bookworm as well

edit: managed to get it almost load turning on X11 and using startx

windg

Without have the knowledge, maybe the package for qt5 or qt6 is missing (qtbase5-dev). I haven't check this emulators yet, so the above is just a guess .

mitu

@retropieuser555 said in Raspberry Pi 5 - official announcement:

Has anyone seen a query on raspberry pi forums, bookworm or dolphin GitHub why you can load Dolphin, AetherSX2 via GUI but not while in terminal/CLI and you get that QT5 error above?

Because they need a desktop env to run ? Not all application can run outside a desktop environment (dolphin for sure does not).

windg

It's look similar then with the duckstation standalone when the dev droped the no-gui option.

retropieuser555

Okay I've got it figured out,

startx /opt/retropie/emulators/dolphin/bin/dolphin-emu-nogui -e /home/pi/RetroPie/roms/<rom name>

This works happily from Terminal/CLI. It doesn't need a desktop environment, just a window to be opened (and x org installed etc). I also fixed the tiny window issue by using this fix below, which you'd need to use for your particular display and then rebuild dolphin, I've only tested it on a 1080p display though.

https://forums.dolphin-emu.org/Thread-small-fullscreen-on-linux

So now adding startx to the emulators.cfg won't work as startx in the runcommand.sh will always turn that into xinit, but xinit doesn't work from the command line for me.

Anyone had any success getting xinit to run from command line? If we can get that working this will load fine, I'm already playing with genuine wiimotes using my dolphinbar, which is all kinds of awesome on a Pi 5 RetroPie setup.

mitu

@retropieuser555 said in Raspberry Pi 5 - official announcement:

Anyone had any success getting xinit to run from command line? If we can get that working this will load fine, I'm already playing with genuine wiimotes using my dolphinbar, which is all kinds of awesome on a Pi 5 RetroPie setup.

Yes, but I had to remove ~~xorg-server-legacy~~ xserver-xorg-legacy first, seems that on Bullseye is buggy and prevents xinit from properly starting.

windg

It's not better to try with wayland instead of xorg ?

retropieuser555

@mitu So apparently I don't have that installed so that's not the issue, I'll put up a proper error log in a bit:-

pi@raspberrypi:~ $ sudo apt remove xserver-xorg-legacy
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package 'xserver-xorg-legacy' is not installed, so not removed
The following packages were automatically installed and are no longer required:
  libdecor-0-0 libdecor-0-dev libdecor-0-plugin-1-cairo libpisp0.0.1
  libwayland-bin libwayland-dev
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 63 not upgraded.

Xinit error log: https://pastebin.com/Yr9BcCuT

I think the problem is here:-

Fatal server error:
[  9540.595] (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied)

mitu

@windg said in Raspberry Pi 5 - official announcement:

It's not better to try with wayland instead of xorg ?

For Wayland there's no similar mechanism in RetroPie like XINIT to instruct runcommand to start the emulator in an Xorg sesion. For Dolphin in particular, there's no native Wayland support so it would run under XWayland and use the x11 API anyway, so there's no benefit in running it under Wayland.

mitu

@retropieuser555 without knowing the command that started this, the error log is not much help. Regardless, I'll add at some point support for dolphin to be run directly from EmulationStation, you can wait until then to test again.

retropieuser555

@mitu Ah sorry,

Here's the command:-

xinit /opt/retropie/emulators/dolphin/bin/dolphin-emu-nogui -e "/home/pi/RetroPie/roms/gc/AC.rvz"

Must be a permissions issue, I just ran it with sudo and it worked fine.

mitu

Just prefix the emulators.cfg entry with XINIT: and it should work:

dolphin-x11-vk = "XINIT:/opt/retropie/emulators/dolphin/bin/dolphin-emu-nogui -v vulkan --config Dolphin.Display.Fullscreen=True -b -e %ROM%"
dolphin-x11 = "XINIT:/opt/retropie/emulators/dolphin/bin/dolphin-emu-nogui --config Dolphin.Display.Fullscreen=True -b -e %ROM%"

EDIT: make sure you also have installed the matchbox-window-manager package.

retropieuser555

@mitu Wow, you're right, wonder why me doing it different it didn't want to work for me, very strange.

Btw the -b batch option gave me an error (I think it's for the Dolphin-gui only) so I just removed it and it plays fine, that's awesome thank you

Ashpool

@retropieuser555 said in Raspberry Pi 5 - official announcement:

If anyone wants to try out lr-parallel-n64, add this line into /opt/retropie/configs/all/retroarch-core-options.cfg

parallel-n64-cpucore = "cached_interpreter"

Not sure if after all that time since that quoted message I should have opened another topic...

@retropieuser555 and it worked fluid for you? Just asking, because on my "Raspi OS: bookworm (64bit)" test/tryout right now on a Pi4 (4GB) regular lr-mupen64plus works like a charm (Aehm, so to say somewhat better under 64bit bookworm in comparison to 32bit Bullseye), but lr-parallel with that .cfg tweak reminds me on my 1st N64 - FZero tryouts with retropie on a Raspberry 3B (no +) [Edit: forgot to mention: lr-parallel under the 32bit bullseye condition, with the compared rom in question, is performing somewhat better than basic lr-mupen64plus (in my setup[defaults used])]
So if lr-parallel is working better for you on bookworm 64bit with cached_interpreter than regular lr-mupen64plus is: what else have you configured, or is that something that is a go ahead on a pi5 but a nogo on a pi4?

retropieuser555

@Ashpool to be honest messing with my pi5 I haven't given the pi4 a look in since. I could only really ever get lr-parallel-n64 on the pi4 to play 007 Goldeneye a few years back. Quite literally everything else would crash. Then that stopped working too recently for some reason.

Dynarec interpeter is way less intensive rather cached and pure interpeter. I think the only reason it's working well on pi5 is by pure grunt power.

One other suggestion on lr-parallel-n64 you could try angrylion rather than GLideN64? That might be better, maybe

Brunnis

I've done a bit of more testing using my Pi 5. I'm only running NES and SNES at the moment. As usual, I try to make the system match an original console in terms of input lag. I set out to verify that the Pi 5 behaves correctly in this regard, i.e. no additional delay in the video driver or any other strangeness. To test this, I configured RetroArch to what it "should" be in order to match the original consoles:

Threaded video = false
Max swapchain images = 2
Runahead = 1 frame
Frame delay = 2 ms

The frame delay setting is there to remove the input lag added by my controller setup (Raphnet USB adapter + original Nintendo controllers, measured by others at around 1.9 ms). The settings above do not take into account any input lag added by the display, so that will need to be removed when comparing to what a real console would do. I used Mega Man 2 to test, at the beginning of Heat Man's stage, running in Nestopia. This should result in an average input lag of ~2.15 frames (36 ms) on a real console: 0.5 frames average from button input to start of next frame, 1 frame "lag" in the game, 0.65 frames to scan out until reaching the Mega Man character at the bottom of the screen.

I did the test with an iPhone 15 Pro recording at 240 Hz, filming the screen and the controller and counting frames from button press to action on screen. The Pi 5 result after removing the input lag of the display I'm using (~1.05 frames): 2.11 frames

So that confirms that the Pi 5 behaves as expected in this regard and matches the "real deal" given the right settings.

Also, the tests were run with the crt-sines shader active. I can really recommend that for the Pi 5. It's more demanding than crt-pi or zfast-crt, but (in my opinion) looks better and also runs at 60 FPS on the Pi 5 even with the above settings and lr-snes9x running SuperFX games. Of course, for more demanding emulators, using this shader (or other more demanding ones) may impede performance.

Dopedtoinfinity

Is retropie-mount supported yet? I can't get my usb to show up. I'm running with an official pi 5 plug.
Just wondering, as I can't get it to recognise my USB drive (I know it's formatted with the correct folder structure as it works fine on my pi 4).

Thanks!

mitu

@Dopedtoinfinity said in Raspberry Pi 5 - official announcement:

Is retropie-mount supported yet? I can't get my usb to show up. I'm running with an official pi 5 plug.

Yes, it should work, but if you're installing manually the usbmount module may have to be installed separately.

Dopedtoinfinity

@mitu Thankyou, I will try it after work, i take it is this one?

https://github.com/rbrito/usbmount

Thanks again!