Configure Linux x86/x64 Retropie to Work Like Raspberry Pi

gaz

Is it possible to configure RetroPie on x86 to run exactly like it does on a Raspberry Pi?

On x86, Retroarch appears to require a xserver to run and it seems to have issues with multi-mouse support. Multi-mouse works fine on a Raspberry Pi, while it seems broken on x86. Under x86, mouse indexes don't work with any driver, including udev. Mouse inputs get combined, making it impossible to play light gun games with multiple players. I've tried it under both Ubuntu and Debian.

I think getting the xserver out of the way would solve a lot of problems. I also just like the idea of having a x86 system dedicated to emulation. I love my Raspberry Pi, but it doesn't have the power to play some of the higher end games.

Thanks in advance.

mitu

@gaz said in Configure Linux x86/x64 Retropie to Work Like Raspberry Pi:

I think getting the xserver out of the way would solve a lot of problems. I also just like the idea of having a x86 system dedicated to emulation. I love my Raspberry Pi, but it doesn't have the power to play some of the higher end games.

On x86 platforms, RetroPie is supported only with a desktop env. Is the regular/standalone RetroArch (if you download it separately as a snap/flatpak) having the same issue ?

gaz

@mitu said in Configure Linux x86/x64 Retropie to Work Like Raspberry Pi:

@gaz said in Configure Linux x86/x64 Retropie to Work Like Raspberry Pi:

I think getting the xserver out of the way would solve a lot of problems. I also just like the idea of having a x86 system dedicated to emulation. I love my Raspberry Pi, but it doesn't have the power to play some of the higher end games.

On x86 platforms, RetroPie is supported only with a desktop env. Is the regular/standalone RetroArch (if you download it separately as a snap/flatpak) having the same issue ?

I haven't tried standalone RetroArch, but it is worth seeing if it helps my multi-mouse issues.

I found a forum post here, that said a bunch of input changes occurred in RetroArch between 1.9.5 and 1.9.6. When I started playing with RetroPie x86, I was using 1.9.4. When I updated RetroArch through the RetroPie interface, I ended up with 1.9.7. The behavior of multi-mouse in 1.9.7 is different, but still not right.

Doesn't RetroPie x86 and Pi share a common code base that gets compiled for one target vs. another? If I were to use similar compilation flags for an x86 build, wouldn't it work more like the Pi version? If my thinking is correct, can you point me in the right direction for what I'd have to change?

mitu

@gaz said in Configure Linux x86/x64 Retropie to Work Like Raspberry Pi:

Doesn't RetroPie x86 and Pi share a common code base that gets compiled for one target vs. another? If I were to use similar compilation flags for an x86 build, wouldn't it work more like the Pi version? If my thinking is correct, can you point me in the right direction for what I'd have to change?

The 'common code base' in this case is the RetroArch's source code. You can find the compilation flags used by RetroPie here, they're mostly related to the video rendering capabilities included and not directly related to the input system.

dankcushions

tagging in @pjft as maybe this change is related? https://github.com/libretro/RetroArch/pull/11388

gaz

@dankcushions I'd been mostly working with a custom version of lr-mame2016 that included changes specifically for Sinden Lightguns. Your post gave me the idea to be more scientific by trying out other cores with actual mice instead of with the lightguns. It appears my multi-mouse problem may be a different than I thought.

Here is what I found on my RetroPie x86 when using actual mice:

lr-mame2003 - Multi-mouse works, although there is a strange conflict between the player one device analog stick and the assigned mouse index. Input from the analog stick would some times cause the pointer to stop registering on a mouse axis. The affected axis seemed linked to the last input the analog stick received.

lr-mame2003-plus - Seems to work correctly.

lr-mame2016 (RetroPie build) - Mouse support seems completely borked.

lr-mame2016 (Sinden build) - Seems to work just fine... when actual mice are used.

After these findings, I tried the Sinden lightguns and couldn't get them to work right. In all cores, the mouse pointer would end up hugging the border of the screen when receiving input from a gun. I also have a track ball hooked up and the input from it was handled properly. I remember the lightgun input working well before I updated RetroArch with the exception of the issue that caused all mouse inputs to drive all pointers.

The Sinden Lightgun test program works properly, so I'm inclined to think there is still a new issue with RetroArch on RetroPie x86. All works fine on my Raspberry Pi, although it is still running 1.9.4. I have a backup of my image, so I may try updating RetroArch on the Pi just to see what happens.

On the Sinden discord, someone mentioned that the changes in the Sinden build were accepted into the RetroPie code base for lr-mame2016, which might help with getting some of these issues worked out.

pjft

@gaz Thanks for raising this, and thanks @dankcushions for the heads up.

I worked on the Linux support for multi-mouse on the udev driver, for Retroarch. That being said, I could only test it on Ubuntu and on a Raspberry Pi, so it might be that there are still other things missing.

It's been a long time since looking into this, but just confirming: I only had instances of the mouse pointer hugging the border of the screen when the gun did not detect the Sinden white border, for alignment. Do you confirm that you are loading the recommended borders/overlays for the gun to calibrate? It's an easy thing to miss, but thought it'd be worth bringing it up.

Is that the case?

I personally never found lr-mame2016 to be especially user friendly to calibrate, but since most of your challenges seem to come from "it works with a mouse, not with the gun", I'd check the borders and/or if the actual drivers are running in the background (just use top/htop in a SSH session).

Let us know more, and happy to try to dig into it.

gaz

@pjft Yes, I'm using the white overlay borders made for use with the Sinden lightguns.

I created emulationstation event scripts that start the lightgun drivers when a game is launched and stops them when the game exits. This method works on my Raspberry Pi and I did experiment with reverting my x86 setup back to using the "ports" launch script method to make sure there wasn't some kind of race condition causing my issue.

I'm confident the drivers are launching, but I'm not entirely convinced the camera inputs are actually being received. I want to believe they are active because the test program works, but I can't be sure there isn't some kind of device access permissions issue occurring when I initialize the drivers outside of the test program. I'm thinking about changing my desktop background to include a white border to see if the lightguns move the pointer around with the driver loaded. For reference, I'm using the 1.6 drivers with 1.5 firmware.

My lightgun issue is even occurring with the nes core. It has been my experience that when all else fails, Duck Hunt seems to be the one game that works. Sadly, it is no longer working for me under RetroPie x86.

pjft

@gaz Got it.

Something that helped me when troubleshooting at the time was to manually launch the Sinden drivers from a console, rather than as a service.

Specifically, SSH into the machine, go to the Player 1 or 2 drivers folder and run

sudo mono LightgunMono.exe

It should launch the driver and show all events in the console. That way it might be easier to understand whether it's running or not, what events is it recording - and if not, what's happening. In my case, at some point the drivers were crashing after a few minutes, and only using the console did I become aware of this.

Note that this is different from the actual command from the bash files, which is

sudo mono-service LightgunMono.exe

that launches it as a service. If you launch it as a service you will not get the logs, as it'll run in the background.

Let me know if this helps, and/or what logs do you get.

gaz

@pjft This is what I see on my RetroPie x86/x64 environment when I run the driver as a console program:

Copyright Sinden Technology 2020.
Version 1.6
Only for use with offical Sinden Lightguns.
Starting.....
CameraName: SindenCameraL
Recoil Off
CalibrationX from gun: 0.72
CalibrationY from gun: -3.23
Lightgun Firmware: v1.5
Found Camera SindenCameraL on /dev/video0
Exposure AutoSet to 78 (-7)

The lightgun worked fine as a mouse outside of RetroArch when I loaded up one of the border images on my desktop.

Unfortunately, things in RetroArch were still bad. lr-mame2003 and lr-mame2003-plus seemed like they kinda worked, but were hypersensitive. The nes core was still hugging the border. The lr-mame2016 Sinden build didn't seem to register any movement input from the gun.

I was running the driver from a SSH session and could see the driver was still active when in RetroArch. I even tried bouncing the driver while some of the cores were running and saw no success.

I also tried by updating RetroArch on my Raspberry Pi to see if that cause similar input issues. After updating RetroArch, the Sinden lr-mame2016 just crashes out when loading a game. I also built the lr-mame2016 from RetroPie source hoping that the Sinden patches were already merged in. I didn't see any difference from the latest binary that didn't work at all. I backed up the image before I ran my experiment, so at least I can go back.

pjft

@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.

Sorry about that.