Linux: Multiple mice problem

[stefanomasini]

Hi,

I have a problem to properly configure my setup to use multiple "mice".

Hardware input devices

• 1 real USB mouse
• 1 Ultimarc SpinTrack spinner connected via USB (using Ultimarc's USB adapter)
• another SpinTrack connected via USB using Ultimarc's I-PAC 2.

In total 3 "mouse"

System
Fujitsu desktop PC.
Debian 10 buster
Running Xorg, with minimalistic Openbox window manager.
MAME 0228, compiled "by hand".

Build defines 1:    SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1
Build defines 1:    LSB_FIRST=1 PTR64=1
SDL/OpenGL defines: SDL_COMPILEDVERSION=2009 USE_OPENGL=1
Compiler defines A: __GNUC__=8 __GNUC_MINOR__=3 __GNUC_PATCHLEVEL__=0 __VERSION__="8.3.0"
Compiler defines B: __amd64__=1 __x86_64__=1 __unix__=1
Compiler defines C: __USE_FORTIFY_LEVEL=0

I figured out udev. I was able to set the 0666 umask to all relevant devices, and I was able to create symlinks to the different spinners (though I don't think they're used anywhere).

I think I figured out Xorg and libinput, and I am able to attach and detach the different devices to the "Virtual core pointer" master device, so when I twist the spinners I can see the mouse move, or I can choose to not do so. I am also able to create new distinct master devices and attach the spinners to those instead of the main Virtual core pointer. When I do so, new mouse pointers appear on the screen, but then, strangely, they don't behave correctly, i.e. they don't move when I rotate the spinner, but only jump to 2 or 3 fixed positions on the screen. That I don't quite understand, but I like to think it's unrelated (?). I am also able to swap the X and Y coordinates of the spinners (with the command xinput set-prop <dev_id> "Coordinate Transformation Matrix" 0 1 0 1 0 0 0 0 1), so I can map one of them to the X-axis and the other to the Y-axis, so even when both spinners are attached to the main Virtual core pointer master device, I can theoretically distinguish between them by axis. But, unfortunately, it looks like this configuration is disregarded by mame.

The problem is that inside MAME I always only see one "Mouse 1" device, no matter what I do. I don't quite understand the chain of libraries/technologies/components used by MAME to interact with the physical devices in my setup, so I'm a bit in the dark. It looks like it's somehow related to Xorg, because if I leave the spinner devices "floating" (i.e. not attached to the main Virtual core pointer master device) their movement is not detected in MAME. Indeed, here's what I see in the logs:

Input: Adding mouse #0: System mouse (device id: System mouse)
Mouse: Registered System mouse
Mouse: End initialization

I see no other seemingly mouse-related log lines.

So, if MAME (or, rather, SDL?) is able to figure out the main Virtual core pointer master device, why is it not able to detect other master devices if I create them?

Then I though, oh well, if I can't get multiple mice to be detected, I will merge them all inside the same main system pointer, but will swap the second spinner to operate on the Y axis, so I can see them as Mouse 1 X and Mouse 1 Y. But, unfortunately, I still see them both as Mouse 1 X.

Maybe I'm compiling mame against the wrong library versions? Or maybe I'm missing a library entirely?
How can I even debug this thing?

Any advice would be greatly appreciated. I'm stuck at the moment, not able to use 2 spinners at the same time.
Thanks!

[rb6502]

Hi,

SDL2 does not support multiple keyboards or mice. That was on their original feature list for 2.0 and was even partially implemented early on, but they ultimately cut it because the Steam games that pay their bills don't need it. There has been some discussion of implementing it for 2.1, but there is no time frame on that.

MAME does have a raw X11 driver for multiple lightguns that probably could be adapted to support arbitrary mouse-like devices if you compile with USE_XINPUT=1 but that would definitely be a project rather than a plug-and-play scenario. Plus X11 is deprecated now with Wayland being the new hotness, but I imagine it'll be several more years before that's a consideration.

[stefanomasini]

Hey, thanks!

I was afraid of that, I did read about SDL's lack of support for multiple mice, but I wasn't sure which version did MAME come with.

But so, does that mean I have no alternative? When you say that USE_XINPUT=1 would be a "project" rather than a plug-and-play scenario, you mean that it's not as easy as turning a configuration option on, but I would actually need to do some coding? Can you elaborate please? If it's not too complicated, I'm not scared about tweaking some code here and there.

I find it strange though that I'm the only one in this situation. I'm actually setting up a dedicated machine for an arcade cabinet, so I can change any part of this setup, including the OS, if needed, in order to achieve my goal. What would be the easiest, most well-tested way to support multiple mice? Should I switch to Windows instead of Linux? Is that the OS most people use MAME on?

[cuavas]

MAME’s SDL input modules do not present multiple keyboard/mouse devices as separate devices in MAME due to lack of support from SDL.

It’s theoretically possible to write input modules using something like Xinput that does present multiple keyboard/mouse devices individually, but no-one has done that yet. Using Xinput would probably require refactoring to play nice with the existing Xinput lightgun module.

USE_XINPUT=1 is set by default when building on Linux, so the Xinput lightgun module is included. You need to explicitly set it to zero if you don’t want MAME to be linked against Xinput.

On Windows, the RawInput keyboard and mouse modules do present multiple keyboard/mouse devices as separate devices in MAME (the DirectInput and Win32 keyboard and mouse modules, on the other hand, do not).

Right now, if you want to use emulated systems that effectively require more than two analog relative axes (e.g. dual trackball games) or multiple keyboards (e.g. multi-player mahjong games), you need to run MAME on Windows or write your own input modules. MAME is working as expected.

[rb6502]

Vas is correct that it would require code to make this scenario work on Linux. The vast majority of cabinets only have joysticks and buttons, usually in either the Capcom 6-button or SNK 4-button layout. So this is a surprisingly rare case. And most cabinets use Windows - it has (currently) the best support for this sort of thing.