Mouse/Trackball/Spinner Woes - Devices get crossed
Tango last edited by Tango
I have been asking for help with other posts, but this focuses on what seems to be a specific issue with the directional input devices (mouse/trackball/spinner) and I thought it might need a separate thread.
The main issue is that there is confusion with RetroPie and the mouse, trackball, and spinner inputs. When I test for the devices, the trackball is 0, the mouse is 1, and the spinner is 2. But in practice, that's not the case.
So, after a number of attempts, I overwrote /opt/retropie/configs/mame-libretro/retroarch.cfg with retroarch.cfg.rp-dist from the same directory to erase a lot of my previous attempts. I also overwrote /opt/retropie/configs/all/retroarch.cfg with the .rp-dist version of the same file in that same directory. The idea being to erase anything I've messed up along the way. I also copied /opt/retropie/configs/all/emulationstation/es_input.cfg to a backup. I left the existing one in place, which had the config for the keyboard mode for the controller.
Also, I'm using a Rec Room Masters Emulator Edition Plus controller. I was using this in keyboard mode and the spinner would work, but not the trackball. (I use Mame-Libretro to test both devices, using Tempest for the spinner and Centipede for the trackball.) (You can check this thread I mentioned above to see all I had done on that.) I have found that, no matter what I do, I apparently will never be able to use both Player 1 and Player 2 controls with the device in Keyboard Mode. So I changed it to D Input mode, which means RetroPie sees the controls as a Ultramarc Mini-Pac. My understanding is that this is set up so one Mini-Pac controller handles the joysticks for both players and all the buttons (and the trackball) and the 2nd Mini-Pac handles only the spinner.
Aslo, for debugging purposes, I'm using a FenniFox keyboard and mouse combo. While these two are wireless, they are not bluetooth. There is one USB connector to plug into the computer that takes input for both the keyboard and the mouse. The result is that as long as I have the keyboard in use, the mouse is in use, as well, whether it's on or not. The Pi will still "see" that mouse as an existing USB connection.
The advantage is that this means all the mouse-type input devices are "stable." I'm not adding or removing any.
What I'm Doing
After deleting or replacing the config files, I changed the mode on my controller from Keyboard to D-Input, so it looks like 2 Mini-Pac controls and I configured them. (Reminder: This does not include any mouse-type device configuration at this point.) Once that was done, I went back to EmulationStation and dropped into the command line and did this:
And rebooted, to be sure the assignments for the devices were the same and did this:
(Sorry for the fuzziness - the forum forced me to reduce it to about 15% of the original image size to get it under 1 MB.)
When I typed
cat /dev/input/mouse0, it responded only to the trackball. Then I tried
cat /dev/input/mouse1and it responded only to the mouse. When I tried
cat /dev/input/mouse2it responded only to the spinner.
From that, and previous experiments, I think it's safe to say I have this configuration:
Mouse0 = Trackball
Mouse1 = Mouse
Mouse2 = Spinner
(And, a side note here: Under my previous configuration, everything was the same and the spinner always worked with Tempest.)
So I tested this configuration out in Centipede. No joy.
I went to RGUI to edit /opt/retropie/configs/all/retroarch.cfg. I went to Settings->Input->Port 1 Binds and verified it was using Mouse0, which I would suspect would be the default. It was:
I went back, then, and tried all 3 devices. The mouse now had control over the player in Centipede. Well, that's progress since that's the first time I've seen ANYTHING other than the joystick move anything in Centipede.
Then I went back and edited the same file (/opt/retropie/configs/retroarch.cfg) and changed the Mouse Index to 1, saved, and restarted. Now nothing had control of the shooter in Centipede other than the joystick. I went back and changed the Mouse Index to 2 and saved. This time the spinner moved the mouse left and right, but that's it. (Well, that's what spinners do, anyway.)
At this point it doesn't make sense. The device on mouse0 is not recognized, but the device on mouse1 is treated as mouse0 and mouse2 is like it should be.
Just to double-check, I went back and changed the Mouse Index to 0, saved, and tried again. The mouse had control. The trackball was ignored.
So the bottom line is that the trackball is on /dev/inputs/mouse0 when I check it, but it's not recognized by anything using Retroarch.cfg. The mouse, on /dev/inputs/mouse1 is recognized by games as mouse0 and mouse2 is mouse 2.
What's going on here? Why is the device on mouse0 being ignored?
This explains, in some weird way, why I could follow the instructions for setting up a trackball and not get it working - something is wrong, somewhere, so there is confusion between mouse0 and mouse1. So what can I do to fix that?
I started to wonder if there could be anything odd about the mouse, since it was a wireless keyboard/mouse combo and rather cheap. I got a USB cable and connected another keyboard, removing the previous keyboard/mouse combo.
When I did
cat /dev/input/mouse0I would get results when I moved the trackball but not the spinner. So far it's what I expected. Then I typed
cat /dev/input/mouse1and got input displayed when I used the spinner. Again, as I expected. The actual mouse, no longer being connected, was not there and the spinner that was mouse2 went down a notch to mouse1. I also shut down the Raspberry Pi and connected the main controller to a Macbook. The trackball worked and controlled the mouse pointer on the Macbook, which confirms that the trackball works properly.
So I had proof that mouse0 was the trackball and mouse1 (the only other mouse) was the spinner.
I checked /opt/retropie/configs/all/retroarch.cfg and the mouse for player 1 was mouse0.
I ran Centipede:
Note that it's being launched with lr-mame2003. I've read here, "As of August 4, 2016, mame2003-libretro has been capable of trackball and spinner support." That tells me I'm using a version that does support a trackball. But when I started it, using mouse0 in the config file, the spinner controlled the shooter. When I started it using mouse1 in the config file, there was no control by trackball or spinner.
So what's happening, somehow, is that the trackball is seen by the Raspberry Pi. When I test it by using
catto see the output of a device, it's there and works. But somehow, whenever I launch the emulator, the mouse device with the trackball disappears. Suddenly /dev/input/mouse0 points to the next device instead of the trackball.
I don't know if I can test this in EmulationStation to verify ES "sees" the mouse. I do know that right now EmulationStation is running and I'm logged in via ssh and I can see both /dev/input/mouse0 and /dev/input/mouse1.
Does anything happen when ES launches an emulator that would change the input configuration? Is there any reason that the emulator would not see a device that I can prove is there and working?
I think this shows what is happening. There's one more thing I can check. Tomorrow I can launch Centipede under lr-mame2003 and double-check that the /dev/input/mouse* files are both still there. I don't see how an emulator could get rid of a device that way, so it's more likely that, somehow, Mame is not seeing the trackball at all.
I found this thread that gives me a few things to try for when I am able to get to my machine again. (My arcade machine is not in my house. I can ssh to it from home, but I have to go out to get to the machine and try any emulators.)
@caver01 , I see you had a lot of input into that thread. I see it's 2-3 years old. I see how the switch from lr-mame2003 to AdvancedMame made things work, but you felt lr-mame2003 should still work. Given the time between that thread and now, do you still feel that there should be a way to get the trackball working with lr-mame2003? I'm open to any input on that.
When I'm at the machine again, I'm going to try AdvancedMame, as well as the suggestions in that thread for lr-mame2003. It just seems the situations are similar, so I'm going to try all the suggestions in that thread. I'm just wondering if there is reason to believe the situation has changed since that thread a few years ago.
Got it working under Mame-lr2003, but not sure why. See the ending of this thread for my post about it.