@gaz I am out of ideas here, and having never used the Lightgun outside of the Raspberry Pi, I would definitely suggest bringing this back to the Sinden Lightgun discord, as Andy will likely be able to best help troubleshoot the scenario.
Specifically, if the gun works in other software such as the test apps, it might be something simple that I am not knowledgeable enough nor experienced enough to detect. The Linux-specific channel there might be the best to get to the bottom of this, but do share whatever you find here, as if there's something that we can change on our end I suspect we'll be happy to accommodate.
xrandr treats both displays and one large one (extended). You can see below that Screen 0: is recognized as 5760x1080 (4K TV + 1080P monitor):
Screen 0: minimum 320 x 200, current 5760 x 1080, maximum 16384 x 16384
VGA-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 800mm x 450mm
3840x2160 30.00 + 24.00 29.97 23.98
4096x2160 30.00 24.00 29.97 23.98
1920x1080 60.00* 59.94 30.00 24.00 29.97 23.98
1920x1080i 60.00 59.94
1280x1024 75.02 60.02
1280x720 60.00 30.00 59.94 29.97 24.00 23.98
1024x768 75.03 70.07 60.00
800x600 72.19 75.00 60.32
720x480 60.00 59.94
720x480i 60.00 59.94
640x480 75.00 72.81 60.00 59.94
DP-2 connected 1920x1080+3840+0 (normal left inverted right x axis y axis) 509mm x 286mm
1920x1080 60.00*+ 50.00 59.94
1920x1080i 60.00 50.00 59.94
1280x720 60.00 50.00 59.94
1024x768 70.07 60.00
800x600 60.32 56.25
720x480 60.00 59.94
640x480 66.67 60.00 59.95 59.94
HDMI-2 disconnected (normal left inverted right x axis y axis)
This is what my autostart.sh file looks like:
#set primary display and resolution.
xrandr --display :0 --output HDMI-1 --mode 1920x1080 --primary &
#call cvlc to play a startup animation. Wait for it to end before continuing.
cvlc --random --play-and-stop --play-and-exit --fullscreen --video-on-top --no-video-title-show --quiet --gl=any --preferred-resolution=1080 ~/RetroPie/splashscreens &> /dev/null
#start ES in a terminal (openbox).
gnome-terminal --full-screen --hide-menubar -- emulationstation --no-splash
Naturally, feh sees the display the same way so you need to use the --geometry switch to identify the starting pixel on the 2nd monitor. This is what my runcommand-onstart.sh looks like:
This essentially gets the full path to the romfile and trims the extension to get the rom base name.
It then builds the path to the controls image I need and displays at the starting position I tell it to (3840x0) which is the entire screen of the 2nd monitor. When I exit the game, and merely kill feh via runcommand-onend.sh:
killall feh &
This is working perfectly. Now I just need to find a fancy graphic to display on the 2nd monitor when it isn't showing controls. :)
You could change your current Ubuntu repository mirror and retry (apt update first). You can use apt-cache policy to check the troublesome packages and see what version are available and from which repository.
I was unable to find held packages, but you got me going in the right direction. For whatever reason, my sources.list file had a comment in it that suggested that because I used a smaller ISO it might not have been the full file. Perhaps a side effect of not allowing online updates during install.
So I got hold of a more 'full' listing of the official sources and ran apt update and it suddenly had way more packages to update and then the install script could find more of what it needed.
I'm still curious if any GNU/Linux wizards know why the original method was not working. Either way it is working now.
Because runcommand needs a terminal to show the launch menu, launching ES directly would break this. On Debian and friends, you can use x-terminal-emulator as the terminal starting command, which would be expanded to one of the installed terminal emulators.
Alright, update, it is still possible. I modified the code in the original post to create folders based on the game name instead of relying on ps_iso_tool to extract a game ID and creating folders based on that. Seems to be working perfectly.
(I have absolutely no idea how to code, so I'm kinda shocked I was able to figure this out.)
OK so should anyone encounter the same:
Changing from opengl to sdl2 did resolve that last issue.
A Pentium G3258 at 3.2 Ghz has some speed issues, but it works fine with 4.6 and up.
Skylake or newer Processors should do with less frequency.
It works !!!!!! but only when i launch ES in a terminal :-(
This is exactly what I said in my first reply. This is how it's configured the RetroPie launcher - as outlined in the docs.
Last question : does ES and Retropie need sudoers ?
If not, i should modify authorization in /opt/retropie/configs : actually all files are for root:root and not for my user "pi"
As runcommand try to write in the .cfg file, it couln't !!!
The /opt/retropie/configs shouldn't be owned by root - there's something that you maybe changed, because the RetroPie-Setup scripts ensure the folder is owned and writable by the installation users.
The sudo rights for the install user is needed for installing additional packages and for adding the necessary configurations needed for RetroPie. This is one of the first steps outlined in the installation docs.