You can use backport for MESA (24.2.8)/Vulkan 1.2.289

Now I did it properly and test it. I saw a massive performance increase for game loading and a better performance with Vulkan. Unfortunately , Vulkan 1.3 is not officially available yet for Pi, only 1.2.289 is available .You can get it only with MESA 24.3 but it should be soon.

Here's what I did :

1- Create an empty file /etc/apt/sources.list.d/debian-12-backports.list and write this inside with a file editor

deb http://deb.debian.org/debian bookworm-backports main

You must change the folder restriction first
2 - update MESA

sudo apt update && sudo apt upgrade sudo apt install -t bookworm-backports mesa-va-drivers

3- Double check your installed packages with:

dpkg-query -W | grep '~bpo'

4 - Update Vulkan if needed

sudo apt install mesa-vulkan-drivers/bookworm-backports

Note : - Do a backup first
- I also recommend to update cmake sudo apt install cmake/bookworm-backports.

@gare You can get RetroArch to run in verbose mode by choosing to launch with verbose logging. Seems like an issue with the audio - perhaps PulseAudio/Pipewire gets stuck ? Does it happen also with standalone emulators (i.e. Mupen64plus or PPSSPP) ?

@Aroenai said in Fresh RetroPie install on Debian 12 x86_64, keyboards not recognized in emulationstation:

Built From: Debian 12 net install (no GUI, installed to external USB 3.1 flashdrive) installation script from https://github.com/RetroPie/RetroPie-Setup

Actually now I noticed this - we don't support nor test running from the CLI on a PC, a desktop environment (X11/Wayland) is required on that platform.

If you still want to run it via KMS/DRM, check if your user is part of the input/video/render groups.

Issues solved.

The problem was that emulationstation didn't have permission to right to /opt/retropie/configs/all. All keybidnings are working fine now.

@voidka
I have been monitoring the GitHub page and it appears there has been an increase of work on the next image. I may be wrong but I would expect it to come out in the next month or so.

So most likely the USB hub is disconnecting at some point and EmulationStation crashes during that moment. Can you try and get a separately powered USB HUB ? Or perhaps a newer PC, since the one you have is more than 10 years old ?

I'm not sure what exactly I touched, but it seems to be working better now.

I found that my /opt/retropie/configs/all/retroarch.cfg had sdl2 driver set as default ... I changed that to udev. Now, both my controllers seem to work.

I had originally thought that my old PC had a legacy BIOS/usb option that was doing something ... but didn't prove out to be anything useful. I think the change from sdl2 to udev in the default config was what did it. I don't have a verbose logging or capture of files to prove that, but my verbose logging now shows that udev device being used. Spot check of a few other games seems to have good results. I have a feeling that my install for some reason defaulted to sdl2 driver and what was my issue.

Thanks for the help

@jhny try reinstalling retropiemenu in core packages and restarting emulation station.

Btw bullseye support is still a wip.

raspi-config should be installed by default even on raspbian lite (it used to be). Please provide more details of your setup (see link at top of forum).

@mitu thanks, I had a look around and as I'm building on top of an existing OS was told I should be using this one.

Can you point me in the direction of the dev/stable branch? I figure I can just let it start and leave it to compile. - thanks!

Just wanted to confirm that building RetroPie on current Debian ‘testing’ using RetroArch’s 1.10.3 source works perfectly.

Thanks!

@mitu That's actually an excellent question.
I have been using my own launcher which only has the command 'emulationstation' -This was the error. If I run the command in a terminal window or use the rpie launcher which does the same; Everything works. So a massive thanks to you!

@tsukisuperior can use

sudo CC="whatever" ./retropie_setup.sh

This may not work for all modules as some module code may override it.

distcc can be used automatically by setting DISTCC_HOSTS="192.168.0.1/4,lzo" etc in the same way. It will get added to start of system PATH and added to MAKEFLAGS also.

@yfzdude said in Should i get Debian x64 ?:

@crush
Dolphin does require a 64-bit operating system. To fix that you need to reinstall using the x86-64 or amd64 version of the installer or image.

When any documentation here mentions x86 it is simply using it as a term to indicate PC/Laptop hardware as opposed to ARM based hardware.

Ok thanks, i had misunderstood then, and you're right, it works fine now on the x64 distribution.

@posti85
the workaround is to check you gcc version on your setup for example mine is 9.3
in CLi type
gcc --version

then in the scriptmodule as @mitu advised initially find the 2 entries pointing gcc-6 lines 20 and 32 (im having 4.7.2 rpie setup script) and in my case i added gcc-9 fo example
save, start or restart rpi setup and should compile ok
BUT again as @mitu
i d recommend lr-mgba which is better for gba

In scriptmodules/system.sh:

# Debian unstable is not officially supported though if [[ "$__os_release" == "unstable" ]]; then __os_debian_ver=11 fi

So, I added the following after this:

if [[ "$__os_release" == "testing" ]]; then __os_debian_ver=11 fi

This did not change anything (or using 10 there). So, this is likely a bit more than not detecting the debian version correctly.

The only issue with mupen64plus is that the system will try to compile that by default during installation and this ends up in error.

@warpath0007 Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

I took the command from the retropie.desktop application which was

gnome-terminal --hidemenubar -e emulationstation

Now it works smooth.
Thanks!

Looks like the performance is pretty poor, even without sound. What emulators are you running and what resolution are you using ?
Can you run with verbose logging enabled (switch it on in the Runcommand launch menu) and then post the log from /dev/shm/runcommand.log ?