Are Multiple Mice Supported or Was That Feature Trashed?

dankcushions · 17 Mar 2020, 14:05

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 · 18 Mar 2020, 01:58

@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 · 21 Mar 2020, 19:30

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 · 21 Mar 2020, 19:41

@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 · 21 Mar 2020, 20:18

@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 · 21 Mar 2020, 20:49

@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 · 21 Mar 2020, 21:30

@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 · 21 Mar 2020, 21:32

@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 · 21 Mar 2020, 22:04

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

Tango · 22 Mar 2020, 00:07

@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 · 22 Mar 2020, 05:11

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 · 22 Mar 2020, 06:08

@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 · 22 Mar 2020, 06:45

@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 · 22 Mar 2020, 16:20

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