Retroarch: Multiple Mice Support [$60]

[twinaphex]

Many games featuring multiple light guns, steering wheels, spinners, etc. are well emulated by libretro cores but cannot be enjoyed in RetroArch.

From my understanding, this limitation exists within the RetroArch input system. It would open up a lot of functionality if there was a way for multiple mouse devices to be used to support more than one player in these games.

---

There is a $60 open bounty on this issue. Add to the bounty at Bountysource.

[twinaphex]

This is the same issue as

https://github.com/libretro/RetroArch/issues/3443

We have to create a separate issue in order for this to work with Bountysource (For unknown reasons).

[markwkidd]

@dankcushions - just tagging you in case you didn't notice yet that this issue now has a bounty 💃

[ghost]

@twinaphex Can you post the name(s) of some game(s) and/or core(s) that support multiple mouse devices?

[markwkidd]

@casdevel Area 51 in MAME 2003 should support multiple mice. MAME 0.78 has multiple mice support and I think that in general MAME has long supported multiple mice devices.

[ghost]

I'm going to need some help with setting this up. I downloaded zip and chd files but loading content fails with message:
3h NOT FOUND
3p NOT FOUND
3m NOT FOUND
3k NOT FOUND
area51.chd UNSUPPORTED CHD VERSION

Now, I see that some files are missing but instead of me googling for solution, I think it will be faster if I ask here. Also last line reports different issue than missing files.

EDIT: Had to edit/remove a few links for obvious reasons (Twinaphex).

[markwkidd]

@casdevel I just sent you an email at your github-registered email address (it's a gmail account).

[ghost]

It's working now, so I'll take a look if I can help (no promises).

[ghost]

@twinaphex I just noticed that you removed link from one of my previous post. Is there some page where I can familiarize my self with rules about links?

[twinaphex]

Rom links is an obvious no-no on Github. I removed it for the safety of us both on here. Best to send people e-mails or PMs instead when having to do that.

[ghost]

@twinaphex OK, although technically we were on the safe side since that link pointed to the page, not the file itself.

[ghost]

@fr500 If I understood correctly first two parameters of the retro_input_state_t function, then libretro implementation can query state of all devices (including mouse) that input driver is aware of. If this is true than this is just a question whether input driver supports multiple mouse devices.

[ghost]

As I understood this is "RetroArch only" issue, libretro API don't have this limitation.
Regarding "it would be a hack" part, RetroArch already has raw input driver (Windows only) that uses API that should support this.

[ghost]

I didn't checked whether RetroArch doing something with input data before it reaches core, but if core obtains unmodified data from input driver then it looks that this is possible.

We are talking about mouse devices here, not gamepads, right?

[ghost]

After last night experiments I can say that this is possible with input driver(s) change only. With modified winraw driver and core that I wrote for testing purposes everything works fine, so no need for libretro/RetroArch changes.
I'll finish/cleanup driver code and than test this with MAME 2003 core, so we'll see...

[ghost]

I noticed that @bparker06 added guards for winraw driver and Windows versions earlier than XP.
Is this means that RetroArch supports Windows 2000, Windows NT 4.0?

[bparker06]

@casdevel We support Windows 98/2000 and up when compiled with VC2005. 95 and NT are on my todo list.

[ghost]

OK, I'll keep that in mind although I don't see any benefits to that (just more work).

[ghost]

Also, I think that VS2008 supports Windows 2000.

[bparker06]

@casdevel Officially it is not supported, but I think some people may have found hacks around it, although we can't rely on those.

[dankcushions]

FYI, as far as I know (@markwkidd please confirm!) the original use-case for this was via a rapsberry pi, which would use the UDEV linux input driver, not winraw

[ghost]

@dankcushions Every platform will need at least one input driver to be modified/created (if possible) to support this. This is Windows only solution, but we have to start somewhere.

[markwkidd]

@dankcushions and @casdevel -- dankcushions is correct in that when I created the original github issue I had been told that the key change was an update to the libretro API. Therefore the update would inherently be cross-platform.

If that turns out not to be the case and it's a matter of updating at least one input driver per supported operating system as @casdevel is saying, then I am willing to adjust my expectations. If it's about updating input drivers, I would be glad to accept a single-platform implementation as long as @twinaphex feels that the implementation is correct and would therefore be useful as a model to adding multi-mouse support to other input drivers.

Does that make sense?

[ghost]

@markwkidd I don't see any reason why this wouldn't be supported on multiple platforms, so you probably don't need to lower your expectations.
Regarding implementation model, implementations are almost always very different.

[markwkidd]

Speaking only for myself, I'm fine with this being for Windows only.

I'll also pledge a few bucks to start a bounty focused on Linux & Lakka support after this one is completed by @casdevel assuming that implementation is not trivial.

[ghost]

Sources and x64 Windows binaries: https://github.com/casdevel/RetroArch/releases/tag/v1.5.0-winraw
Tested with modified MAME 2003 core (included) and Area 51 game. Original MAME 2003 core has multiple mice support disabled, so use this one (I changed core name to avoid confusion).

Note: this is just a proof of concept, no guaranties!

[twinaphex]

Hi there guys,

I backported the patches by @casdevel over to the latest RetroArch, and MAME 2003 cores. They should be in nightlies shortly.

If you want to test this, if I understand things correctly, you will need to use the rawinput input driver, other drivers won't have multiple mice support implemented yet.

[twinaphex]

hey @markwkidd and @dankcushions ,

can you guys test this with the raw input driver? Test it with the latest nightly of RetroArch, and the latest MAME 2003 core.

[ghost]

I was experimenting with udev input driver under Linux and I'll probably finish modifications in the next few days. I uploaded changes to https://github.com/casdevel/RetroArch/tree/udev if someone wishes to test it.

@twinaphex Don't use this code, it's a mess.

[markwkidd]

I'm traveling and I don't have access to my RetroArch rig. I'm trying to get an installation up and running on my work laptop but I haven't been able to check out the dual mice support yet.

[markwkidd]

OK, I think I have got Retroarch setup correctly on this Windows laptop but I'm having trouble getting dual mice working with MAME 2003. What I'm trying:

• With both @casdevel 's RetroArch build and the most recent buildbot win x64 build I have set "input_driver" to "raw" in retroarch.cfg
• The laptop's built-in touchpad shows up as mouse hardware. The discrete mouse device also shows up as mouse hardware in Windows. Both 'mice' control the Windows system pointer.

Under these circumstances, both of the mice seem to be controlling one crosshair in Area 51. What am I overlooking?

[ghost]

Regarding OS mouse pointer, this is normal (there can be only one). Multiple mouse pointers can be available only in MAME 2003 (tested with Area 51 game only).

Can you look at log to make sure that RetroArch is using winraw input driver?
Also you can try to delete or remove retroarch.cfg just in case. And, after that, don't forget to set input driver from menu.

Currently I don't have access to laptop with Windows installed so I can't test combination touch-pad and mouse, all of my tests was done on desktop machine with USB mice.

[ghost]

Just to comment that multiple mice support is now available on Linux too.

[ghost]

@markwkidd I just tested this on laptop and I got the same result, so it's a winraw driver issue. Two mice don't help either. I'll see what's going on.

[ghost]

It turned up that this is not winraw driver issue after all. Touchpad is recognized and data is picked-up correctly by winraw driver but Windows raw input API reports three mouse devices instead of two and when that third device is at index 0 or 1 we "lose" either mouse or touchpad. I also reproduced this issue on desktop machine with empty PS/2 mouse port and two USB mice.

If it's possible to select player's mouse device in MAME 2003 core options (I couldn't find it) or somewhere else, then no changes are necessary, so if someone knows whether this is possible or not it would be nice to let me know so I don't start introducing (unnecessary) code. If this isn't possible I think that changing MAME 2003 core is better solution than changing winraw driver (I'm open to suggestions).

[markwkidd]

I don't know of any existing MAME 2003 core options for mouse selection, but that does seem like a logical solution when the underlying input API arbitrarily assigns indexes to the hardware. Note: I don't know much about the input system.

By the way thank you very much for all of your effort on this project.

[dankcushions]

i don't like adding options to mame2003 to assign each mouse id to each player, but it's something that could be added i guess. it would be a problem in any core that uses multiple mice so i think it ideally should be handled by Retroarch/the driver.

Touchpad is recognized and data is picked-up correctly by winraw driver but Windows raw input API reports three mouse devices instead of two and when that third device is at index 0 or 1 we "lose" either mouse or touchpad. I also reproduced this issue on desktop machine with empty PS/2 mouse port and two USB mice.

so what is at the different IDs in windows/linux? PS/2 mouse always at device 0?

[ghost]

@dankcushions Probably PS/2 mouse port (Windows raw API don't provide this info). I didn't investigate further since there is no benefit in knowing that (from core/RetroArch/driver point of view). Important thing is that this index can change when USB mice is plugged in/out. This is observed on Windows, I didn't checked Linux side.

Bottom line is that we need device selection and must be by index. Only question is where to put this option, core or RetroArch/driver, and this, I think, should be decided by users.

[dankcushions]

Bottom line is that we need device selection and must be by index. Only question is where to put this option, core or RetroArch/driver, and this, I think, should be decided by users.

i think it would make sense to handle it in the same way as Retroarch does for player joypad device ids. i.e.:
https://github.com/libretro/RetroArch/blob/cc1954b4acf77bdb0b5bdd0c4eb0fb0a13401b9a/menu/menu_setting.c#L1640

basically, the device index for each player's joypad is configurable. i think we should add some INPUT_PLAYERX_MOUSE_INDEX settings and menu entries. Hopefully a copy & paste job for the most part :)

[ghost]

Sounds good to me.

I'll be busy for the rest of the day, but tomorrow I can familiarize myself with with source code that will need changes and start working on a solution.

[kivutar]

Since the drop of libxkbd support, keyboard typing in search fields and password fields is broken in DRM/KMS.

I think that we were using libxkbd to handle things like modifiers: shift, alt gr, fn.

Can you add this functionnality back please? It is needed in Lakka where we don't have X11 running.

[ghost]

@Kivutar If changes at https://github.com/casdevel/RetroArch/tree/udev-drm solve this issue let me know and I'll create PR then.

[kivutar]

@casdevel Tested, it fixes the problem. Thank you.

[ghost]

@markwkidd and @dankcushions I added player mouse index settings.
Changes are at https://github.com/casdevel/RetroArch/tree/mice.

Under "Settings/Input/Input User N Binds" is new option "User N Mouse Index" where N is user number.
Changes are implemented in both udev and winraw input drivers.

Let's give it a test run before I create pull request.

[markwkidd]

@casdevel I'm still out traveling. I do have this Windows PC which I can use to test, but I don't have it set up for compilation. (And I've never compiled RA for Windows) Is there any chance you could post another compiled Windows binary with your latest enhancements?

[ghost]

You can use latest nightly, code is merged.

[markwkidd]

Major advancement! I now see independent mouse inputs in Area 51 for a trackpad and a USB mouse plugged into this Windows 10 laptop.

One question at this point @casdevel. The first mouse device, assigned to player 1, maps the mouse buttons to the fire controls for that player. The second mouse device, assigned to player 2, controls the Area 51 crosshair for that player but the mouse buttons are not mapped for firing.

Is this an issue that needs to be addressed within the input driver changes, or is it something that needs to be addressed as a default mapping issue on the core side?

Note to anyone else recreating my settings: The correct "input_driver" value in retroarch.cfg for multiple mice in Windows 10 is raw.

[ghost]

Mouse buttons have to be set in Area 51 settings. P1 button 1 and P2 button 1 for fire control.

[markwkidd]

Confirmed. This seems perfect. Thank you!

@casdevel did I read somewhere that you are also looking at a way to standardize the issue of absolute vs. relative mouse/pointer coordinates? I was thinking I would write up an issue about that but I wouldn't if there is already some work going on.

[ghost]

Conversion of absolute and relative positions is RetroArch and input driver responsibility, so if you noticed some problems related to this then it's a issue. Note that core also can be source of the problem, so before opening a issue you should confirm that problem exist with more than one core.

[markwkidd]

Great, thanks for that answer which is very clarifying.

[ghost]

@twinaphex Shouldn't this be closed?

[ghost]

@casdevel, would it be possible to have standard control for each mice, having to remap shit takes time for every game. Mame handles this very good in it's official build, by using a unified controller for games if set to proper lightgun setting.

Also would it be possible running the raw input with multiple mices as a support driver for the other inputs instead of having to switch.

[ghost]

@Scr00m Standard button mapping for mice can't be implemented in input driver code. This should be possible by changing/adding code to other parts of RetroArch. Since this is not about multiple mice support, I think that you could open a new issue with this request.

Also would it be possible running the raw input with multiple mices as a support driver for the other inputs instead of having to switch.

No, RetroArch can work with only one input driver at a time.

[ghost]

@casdevel This should be closed then :)

[twinaphex]

I am fine with closing it at least.

[mediamoshpit]

I see this has been closed and I'm a little unsure of the etiquette involved in further discussion, but I've been testing this on a Raspberry Pi 3 model B, Linux version 4.9.24-v7+ with RetroArch version 1.6.0 -- e2c3f42 and I'm unable to have more than one mouse register with the software at the same time.

I've made sure that udev is selected as the input driver, but it seems as though RetroArch will only register a mouse here if it's designated as 'mouse0' by the system. I've been testing with two Logitech mice and both work separately when designated as 'mouse0' and set to the RetroArch mouse index of '0' for any player, but neither will work when designated as 'mouse1' and set to mouse index of '1' in RetroArch.

[thatman84]

Before I accept can i get some clarification please (im technicaly challanged)

Will this implementation make its way into other patforms? Specifically Android

Has this only been tested on one game for one core? Or is that a little irelevant

Should I accept based on whats been achieved?

[ghost]

@mediamoshpit I think that udev related log will tell as what's going on.

@thatman84

Will this implementation make its way into other patforms? Specifically Android

If you are talking about udev input driver then, if android offers dev/input/event interface it's already there, otherwise no.

Has this only been tested on one game for one core? Or is that a little irelevant

Most likely (in my case it's sure). I'm not aware of any other core(s) that support multiple mice, but if there are such core(s) multiple mice should be available when using udev or winraw input driver.

Should I accept based on whats been achieved?

Maybe additional question may help you decide:
Does RetroArch support multiple mice?

[markwkidd]

Hi @casdevel , do you have any time to look at @mediamoshpit 's situation? https://github.com/libretro/RetroArch/issues/4775#issuecomment-310163074

Would it be better for them to start a new issue rather than using this one?

[ghost]

@markwkidd I commented on that in my previous post. We should start from udev related log.

@mediamoshpit Start and exit RetroArch and post log (udev messages should be sufficient). If you open a new issue mention me there so I get notified.

[mediamoshpit]

My log file is below.
https://pastebin.com/nvFZ2xNA

[markwkidd]

hey @mediamoshpit you and I are both testing mouse support at the same time today I think! I hope you won't mind me opening a new issue to track this as it relates to the udev input driver -- I'll tag you in the OP.

[mediamoshpit]

Sounds good, thanks.