Are Multiple Mice Supported or Was That Feature Trashed?

[Tango]

First, when I say, "mouse," most of the time I'm talking about any pointer device that is treated as a mouse. That includes trackballs, light guns, spinners, and even mice.

The problem: I have a trackball and a spinner and I'd like to get both working so I can use each in the appropriate games that use them. I've found threads here and on the RetroArch site that are a few years old that say RetroArch supports multiple mice. But I've seen people, recently, talking about not getting more than one mouse at a time to work with RetroArch and Libretro games. That's also my experience.

This thread talks about getting more than one mouse working at a time. It's specifically about using multiple light guns in the same game. It includes a link to the basic RetroPie page on setting up mice devices, but it supposedly goes to a section on the page for multi-mice setups. That section does not exist at this point.

With that section gone, and people reporting that if they have a mouse connected to their Pi, a trackball won't work, and with my experience that with 2-3 mice connected, no matter what, only one is recognized, I am now thinking RetroPie (and maybe RetroArch?) no longer supports multiple mice.

Are multiple mice supported at this point?

If they are supported, how do I get RetroArch to recognize more than one mouse device? I can't even get the system to see two devices at all, much less two at the same time, in the same game.

Also, in terms of configuration, my understanding is that I should edit /opt/retropie/configs/all/retroarch.cfg so it uses the mouse index for the trackball, then use a special config file for each game that uses the spinner instead of the trackball. Are there other ways to do that or is that the only (or best) way?

[mitu]

Are multiple mice supported at this point?

Yes, and it's not a RetroPie feature, but something that's part of the emulator feature-set. If it doesn't work in RetroArch, then it may be a bug in RetroArch.

Are there other ways to do that or is that the only (or best) way?

Yes, you can do the configuration from the RGUI (the RetroArch menu) and save a game/core input override - https://retropie.org.uk/docs/RetroArch-Configuration/#core-input-remapping. There's no need to edit any file.

[Tango]

@mitu said in Are Multiple Mice Supported or Was That Feature Trashed?:

Are multiple mice supported at this point?

Yes, and it's not a RetroPie feature, but something that's part of the emulator feature-set. If it doesn't work in RetroArch, then it may be a bug in RetroArch.

Posted on the RetroArch forum. Actually, I asked there first, but no answer yet, so I asked here. Really hoping to get this done this weekend. The arcade cabinet is in our guest house, without a good computer there, so I tend to have to go back and forth from there to here, with the computer. It makes troubleshooting irritating and time consuming. (And, with the hill between the two places, exhausting!)

Even though this is supposed to be supported, it's tough to figure out what's going on, since it seems like everyone has the same issue: Only one pointer device per machine. That made me wonder if it was so buggy they dumped it or something like that.

Are there other ways to do that or is that the only (or best) way?

Yes, you can do the configuration from the RGUI (the RetroArch menu) and save a game/core input override - https://retropie.org.uk/docs/RetroArch-Configuration/#core-input-remapping. There's no need to edit any file.

I noticed, with runcommand, that it does give me the option to type in info for a custom RetroArch config file for a game. I also noticed no include statements in that file when I checked it. I figured I'd load from ...configs/all/retroarch.cfg, edit as needed, and save it in the right place with the ROM name, just to make sure everything was included.

[dankcushions]

if you can successfully configure retroarch to recognise each device (though not at the same time), then it's simply a matter of configuring retroarch to support one mouse device, and then the ones you want the other, create per-rom overrides as per https://retropie.org.uk/docs/RetroArch-Configuration/#example-per-rom-override-retroarchcfg

I noticed, with runcommand, that it does give me the option to type in info for a custom RetroArch config file for a game. I also noticed no include statements in that file when I checked it. I figured I'd load from ...configs/all/retroarch.cfg, edit as needed, and save it in the right place with the ROM name, just to make sure everything was included.

that's not what you were instructed to do...

[Tango]

@dankcushions said in Are Multiple Mice Supported or Was That Feature Trashed?:

if you can successfully configure retroarch to recognise each device (though not at the same time), then it's simply a matter of configuring retroarch to support one mouse device, and then the ones you want the other, create per-rom overrides as per https://retropie.org.uk/docs/RetroArch-Configuration/#example-per-rom-override-retroarchcfg

That's the catch - I have not found a way to configure RetroArch to recognize each device. It sees only ONE mouselike device and no matter what I do, it won't see the other. That's what I said in the 2nd paragraph of my post. As with other people, I can get RetroArch to see ONE device, but not others.

I had a trackball that was showing up as /dev/input/mouse0, a mouse at mouse1 and a spinner at mouse2. No matter what I did, what I set the Mouse Index to, RetroArch would ONLY see the mouse or nothing.

I pulled the mouse out. Now the spinner was at mouse1. RetroArch would see the trackball, but not the spinner, no matter what I tried. (I had verified both work by doing cat /dev/input/mouseX for each one and they were working. I even plugged each one up to a MacBook and they all worked. (The spinner, of course, only moved the pointer horizontally, but it did work.)

So I know the devices are working. I know Linux is recognizing them. But RetroArch is not aware of more than one device.

Yet I see accountings of people not only having more than one mouse type device working, but multiple ones working at the same time.

I noticed, with runcommand, that it does give me the option to type in info for a custom RetroArch config file for a game. I also noticed no include statements in that file when I checked it. I figured I'd load from ...configs/all/retroarch.cfg, edit as needed, and save it in the right place with the ROM name, just to make sure everything was included.

that's not what you were instructed to do...

Not in the same way, but it gets the same result. If I do that, then it saves a new RetroArch config either specifically for the core I'm using (such as lrmame-2003) or I can specify to save it for the particular game. I'm using different wording. That's a trick some of us with reading and learning disabilities do: reword things as a way to make sure we're putting the info together.

[dankcushions]

@Tango said in Are Multiple Mice Supported or Was That Feature Trashed?:

That's the catch - I have not found a way to configure RetroArch to recognize each device. It sees only ONE mouselike device and no matter what I do, it won't see the other. That's what I said in the 2nd paragraph of my post. As with other people, I can get RetroArch to see ONE device, but not others.

right, lets see your full configuration file for the scenarios involved. what are you changing to select mouse1 rather than mouse0? please show the specific lines.

please also show a verbose log (via runcommand 'run with verbose logging' ) of a game loading that is failing to see mouse1.

Not in the same way, but it gets the same result.

not necessarily. if someone gives you specific instructions, why not just follow them directly?

[Tango]

@dankcushions said in Are Multiple Mice Supported or Was That Feature Trashed?:

@Tango said in Are Multiple Mice Supported or Was That Feature Trashed?:

That's the catch - I have not found a way to configure RetroArch to recognize each device. It sees only ONE mouselike device and no matter what I do, it won't see the other. That's what I said in the 2nd paragraph of my post. As with other people, I can get RetroArch to see ONE device, but not others.

right, lets see your full configuration file for the scenarios involved. what are you changing to select mouse1 rather than mouse0? please show the specific lines.

Full config file posted at the end of this post.

The one line I've been dealing with has been:

input_player1_mouse_index = "0"

I'm using RGUI and changing, specifically, the Mouse Index. In this image I had to scroll down a few lines to get as much as I could on the screen. I've been changing the Mouse Index on the Port 1 Binds. What I'm not clear about is I've seen documents that say to set it to the actual mouse number (as in /dev/input/mouseX), but on the RetroArch site, I see instructions about setting it to the event number (as in /dev/input/eventX). I've tried both. At this point I'm working with JUST /opt/retropie/configs/all/retroarch.cfg. Once I can get RetroArch to recognize the spinner at all, while both it and the trackball are plugged in, then I'll deal with using the trackball by default and using the spinner in the games it works best in.

please also show a verbose log (via runcommand 'run with verbose logging' ) of a game loading that is failing to see mouse1.

I'll have to post that part separately. The arcade machine is in another building. I can get there in a few hours. I'll try it using the different mouse index numbers so I can post a log of each one.

Not in the same way, but it gets the same result.

not necessarily. if someone gives you specific instructions, why not just follow them directly?

"That's a trick some of us with reading and learning disabilities do: reword things as a way to make sure we're putting the info together."

Sometimes I have to reword things. Sometimes I have to put the pieces together in a different way to make sure I get what's being explained. It's very frustrating and it is a learning disability. (That's why I spent years as a special ed teacher - to help students dealing with the same kind of frustration I face: Trying to make sure we understand what other people mean when our brains are wired differently.) In this case, to try to get things to fit together so I was clear, I needed to try to see if I was understanding how it would fit together.

So if it doesn't get the same result, in this case, it would help me to know why.

[dankcushions]

i don't see the full config file, and we need that verbose runcommand also.

So if it doesn't get the same result, in this case, it would help me to know why.

the interplay between the various config files in retropie is complicated so if you don't follow what's being requested, it gets difficult/impossible to support you. via RGUI per-rom overrides at least removes an amount of potential user error of you manually inputting the config lines if you do it via the runcommand method.

it's also possible the runcommand override is being ignored by (or superseding) other .cfgs in the hierarchy (such as any per-rom overrides you've done via RGUI), but rather than us trying to work out exactly what's going on, it's much easier if you just follow exactly what's being asked, and then give us the full set of config files and logs when seeking support.

(i'd argue we possibly should remove the runcommand method entirely but i'll leave that for another day)

[Tango]

@dankcushions said in Are Multiple Mice Supported or Was That Feature Trashed?:

i don't see the full config file, and we need that verbose runcommand also.

Sorry for the delay - I had a nightmare with a firewall doing my DHCP and DNS to fix. (I felt better when I found out that I had done everything right - just had an unusual situation on my LAN.)

I've put the files up on PasteBin. I'm including the config for Mame-Libretro as well. If I understand the hierarchy, then that might make a difference.

/opt/retropie/configs/all/retroarch.cfg
/opt/retropie/configs/mame-libretro/retroarch.cfg
RunCommand Log (for Tempest)

So if it doesn't get the same result, in this case, it would help me to know why.

the interplay between the various config files in retropie is complicated so if you don't follow what's being requested, it gets difficult/impossible to support you. via RGUI per-rom overrides at least removes an amount of potential user error of you manually inputting the config lines if you do it via the runcommand method.

From what I've read, my understanding is that these are the retroarch files that effect a game:

• list item/opt/retropie/configs/all/retroarch-core-options.cfg - Handles main options that would apply to almost everything - but only core options.

• list item/opt/retropie/configs/all/retroarch.cfg - Main config file

• list item/opt/retropie/configs/<emulator name>/retroarch.cfg - Contains settings for a specific emulator, like mame-libretro, that apply only to that emulator. I assume any settings here override the one in all/retroarch.cfg?

• list item/opt/retropie/roms/<emulator name>/<gamename>.zip.cfg - Contains settings only for that particular ROM. I assume settings here override the settings in all/retroarch.cfg and <emulator name>/retroarch.cfg.

Am I at all close to how it works?

it's also possible the runcommand override is being ignored by (or superseding) other .cfgs in the hierarchy (such as any per-rom overrides you've done via RGUI), but rather than us trying to work out exactly what's going on, it's much easier if you just follow exactly what's being asked, and then give us the full set of config files and logs when seeking support.

Thank you. I know it takes more time for more info, but that is a HUGE help to me. (And you can imagine how it can be frustrating for me! There are times I need to go back and forth several times with someone so I can be sure I can visualize just what they're saying. That's one big reason why, when I ran my own software company, I didn't hire anyone and just worked day and night. It was just too hard to try to explain what I was picturing. I've wondered if I could have done better if I had majored in programming rather than being self-taught.)

---

At this point, my primary goal is just to get anything to respond to the spinner while the trackball is plugged in as well. Once that's working, I would think that would show what has to be done in configuration files to specify whether a game needs the trackball or spinner (if it needs either of them). Right now I'd be thrilled to just see the spinner control something without me having to unplug the trackball and to know what was done to make it happen.

[Tango]

This is the same text for a thread I started on the Libretro forums regarding the same issue:

---

GOT IT!

And it makes no sense to me at all.

Again, here's what I have:

/dev/input/mouse0: Trackball
/dev/input/mouse1: Spinner

And that's IT for /dev/input/mouseX. If X > 1, the device node just doesn't exist.

Under events:

/dev/input/event3 = Trackball
/dev/input/event6 = Spinner

When I tried cat /dev/input/eventX with event ≠ 3 or 6, I got no input at all from the trackball or spinner.

So when I was in Port 1 Binds, I'd set the Mouse Index to 0, 1, 3, & 6. I've seen documentation that says that it's the event, not the mouse node that matters. But only 0 would work with the trackball. All other numbers would NOT work.

I had, previously, when I had a mouse hooked up (and, I think, when I was using the older version of RetroPie), tried running through 0-10 for Mouse Index in RGUI and got nothing. ONLY 0 would work, and only with the trackball.

But today I tried, almost by accident, using 2 for the Mouse Index and the spinner worked!

I don't see why. I have mouse0 and mouse1. The only events that showed any input for the mouse devices were 3 & 6, and only when I tested them with cat /dev/input/eventX, and not with RetroArch at all.

I'm wondering if there could be a bug with the Mouse Index numbers in RetroArch. I would think the Mouse Index would be the same number as the mouse device node or the event node. Or that the index would not skip over a blank. (In this case, it skips 1 - go from 0 for trackball to 2 for spinner.)

So it works. If possible, I'd like to know why, but I'm just glad I got it working. There's other alterations I want to make to my config, but I didn't want them to get in the way of this issue, so I've waited to do them.

This also provides support for the answer to one of my questions: I used Port 1 for almost everything and Port 2 for the spinner, so that's proof that the virtual pad for Player 1 can use devices from ports other than 1.

[mitu]

@Tango said in Are Multiple Mice Supported or Was That Feature Trashed?:

I would think the Mouse Index would be the same number as the mouse device node or the event node.

Not really, the number assigned to the device is not necessarily the index of said device in the list of same-kind devices. For the /dev/mouseX, it might look like it is, but the /dev/input/eventZ are for all event generating devices (keyboards/gamepads/leds/mice/etc.).

Let's say you plug in 3 mice, they get /dev/input/event1, /dev/input/event2 and /dev/input/event4. The indices would still be 0, 1, 2 (or 1, 2, 3 of numbering is from 1). Now, you remove the 2nd mouse, so /dev/input/event2 disappears, but the device in /dev/input for the remaining mice are the same, while the index for the 3rd mouse would shift downwards.

[Tango]

@mitu

@mitu said in Are Multiple Mice Supported or Was That Feature Trashed?:

@Tango said in Are Multiple Mice Supported or Was That Feature Trashed?:

I would think the Mouse Index would be the same number as the mouse device node or the event node.

Not really, the number assigned to the device is not necessarily the index of said device in the list of same-kind devices. For the /dev/mouseX, it might look like it is, but the /dev/input/eventZ are for all event generating devices (keyboards/gamepads/leds/mice/etc.).

Let's say you plug in 3 mice, they get /dev/input/event1, /dev/input/event2 and /dev/input/event4. The indices would still be 0, 1, 2 (or 1, 2, 3 of numbering is from 1). Now, you remove the 2nd mouse, so /dev/input/event2 disappears, but the device in /dev/input for the remaining mice are the same, while the index for the 3rd mouse would shift downwards.

Okay, doing my rephrasing thing to see if I get it:

Since my system used /dev/input/event3 and /dev/input/event6, I probably had some other device using something between 3 and 6, so /dev/input/event3 was Index=0 and /dev/input/event6 was Index=2, with some unknown dongle being in between at /dev/input/event[4 or 5] and that got Index=1.

Is that saying the same thing?

[mitu]

@Tango said in Are Multiple Mice Supported or Was That Feature Trashed?:

Is that saying the same thing?

Yes. I'm impressed you managed to keep it under 1 page this time :).

[Tango]

@mitu said in Are Multiple Mice Supported or Was That Feature Trashed?:

@Tango said in Are Multiple Mice Supported or Was That Feature Trashed?:

Is that saying the same thing?

Yes. I'm impressed you managed to keep it under 1 page this time :).

You have no idea how much editing it takes to sort through what's in my head and make anything short!

But there are also times I would rather have too much detail than leave out something important.

[Tango]

@mitu

@mitu said in Are Multiple Mice Supported or Was That Feature Trashed?:

@Tango said in Are Multiple Mice Supported or Was That Feature Trashed?:

Is that saying the same thing?

Yes. I'm impressed you managed to keep it under 1 page this time :).

If this is true, it seems to me you can't be sure just what the index for a mouse device will be and, if there is more than one, trial and error will often be necessary.

[mitu]

If you only have 2 mice, they should always have the same index.

[Tango]

@mitu said in Are Multiple Mice Supported or Was That Feature Trashed?:

If you only have 2 mice, they should always have the same index.

True, but when you're first setting it up, you can't be sure just where they are.

I'm still puzzled, since the trackball is 0 and the spinner is 2 and, as far as I know, there are no other mouse type devices connected. My best guess is that one of the MiniPacs must have an undocumented mouse device in it that uses 1.

[mitu]

You can check by looking at the RetroArch's debug log and by running cat /proc/bus/input/devices.
Remembering your first RetroArch debug log, my guess is that RetroArch counts twice a mouse device as both /dev/input/mouseX and /dev/input/eventY. You can check this theory by adding a mouse (so you have 3 devices) and using indexes 0, 2 and 4 to see if each device is detected and working.

[Tango]

@mitu said in Are Multiple Mice Supported or Was That Feature Trashed?:

You can check by looking at the RetroArch's debug log and by running cat /proc/bus/input/devices.

Is proc/bus/input/devices a totally separate log than in /dev/shm?

Remembering your first RetroArch debug log, my guess is that RetroArch counts twice a mouse device as both /dev/input/mouseX and /dev/input/eventY. You can check this theory by adding a mouse (so you have 3 devices) and using indexes 0, 2 and 4 to see if each device is detected and working.

I get that - and on the first time! Yes, that's something I can check to see what's going on.

Thanks!

(At this point, I'm just thrilled I got it working and can move on to the other UI issues, like changing around a few key bindings/actions to make it more user friendly with the buttons and labels on my control console.)

[mitu]

@Tango said in Are Multiple Mice Supported or Was That Feature Trashed?:

Is proc/bus/input/devices a totally separate log than in /dev/shm?

Not really a log, but a listing of what input devices are detected by Linux and how are they handled (i.e. which /dev/input/eventX has assigned, what type of device is it, what driver is handling it, vendor/model info).