Are Multiple Mice Supported or Was That Feature Trashed?

[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).

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

Okay. I can see that now, with access to the computer again. (Remember, it's in a different place than my desktop, that I use for posting.) Thanks!

Now I have the primary Mini PAC set in Keyboard Mode and I see that it recognizes the Mini PACs as devices, but also recognizes the devices on them separately. It looks like keyboard in the Mini PAC gets an event node. Interestingly, the Ultimarc SpinTrak (the spinner) gets Event 5, not 6. When I test with cat /dev/input/event6 I get input from the spinner and I don't with event5.

But this shows me that some of the devices are broken down into multiple devices and explains why something else is "in between" the trackball and the spinner.

As a side note, even though this is a built in function for RetroArch, I've now done what the manufacturer claims can't be done. Xtensions claims that, in D Input Mode, you can only have one mouse device, so you can have the trackball (somehow that always ends up as the one to take priority) but not the spinner in that mode. I'll be writing them about that!

When I have all my questions worked out, I'm going to either write up a few blog pages or make a few videos for others with the same issues. I'm hoping that they will use the so their other customers can get this working, too.