RetroArch
RetroArch copied to clipboard
Request: Mouse Device Indices Sorting
Description
As it is now (and has been for a while), RetroArch's mouse indices are pretty unreliable with regards to providing a sane and consistent ordering of devices.
Actual behavior
I realize that this is an issue across both Windows and Linux, but at least on the latter, what I think is happening is that udev
's ordering scheme seems to be based on the file path--at least in /sys/devices/...
. So this seems to be sorted in order of:
- USB Hub (internal or external)
- USB Type(?)
- USB Port(??)
- Device VID/PID pair
One quirk of this though, is that sorting isn't natural; i.e., 10
goes after 1
, but before 2
. Regardless, this isn't intuitive and can't be relied upon for consistent ordering of devices... at least, not without mucking about with putting what devices in what ports, which can't always be an option.
Expected behavior
What should be happening (again, mostly focusing on Linux here), is that for mice, it should be indexed based on:
- Mouse Type (REL or ABS)
- Vendor ID (lowest to highest)
- Product ID (lowest to highest)
So ideally, a relative mouse should be on Index 0, and two absolute positioned mice (in my case, lightguns) should then take the next two ports, based on Vendor and Product ID order. This would be preferred, as it's not likely a user will have two regular relative mice (unless it's like a laptop with its internal touchpad and an external mice being detected) but would be likely to hotplug lightguns.
It seems as if this is all handled in input/drivers/udev_input.c
, as shown:
https://github.com/libretro/RetroArch/blob/a3f13b226874121422c8f967d69950809b8670ff/input/drivers/udev_input.c#L4156-L4181
So perhaps, if a little ugly, the list could be temporarily copied, and sorted through based on the above (preferred) criteria back into the main udev device node until all available devices have been indexed through? At least for having mouse detection still be 'automated' without an explicit white/blacklist reservation system like MAME does, this would certainly do better than what feels like complete randomness that isn't as much in the user's control.
I would have made a PR for this, but I'm not exactly confident in working with this specific source without me potentially breaking something else in the process, as lower level Linux (and certainly Windows) is beyond my level of understanding.
Environment information
- OS: Arch Linux/X11+
udev