Emulator Issues #11917
open[Linux] evdev devices with the same name do not have consistent ordering
0%
Description
Hi,
I'm running dolphin 5.0-c1818c3 under ubuntu 18.04 and I'm very happy with it. However I'm facing troubles to setup my controllers (I own two Logitech Cordless Rumble Pad 2). The gamepads themselves are well detected and I am able to bind buttons and sticks, it works well in games. Concerning my setup I would like to add that I connect : the two gamepads to a usb hub BEFORE, then the usb hub to my computer AFTER. For udev, this is the same as booting the system with the controllers and the usb hub already connected.
I found that the gamepads "Device" name path are randomly chosen between "evdev/0/Logitech Logitech Cordless RumblePad 2" and "evdev/1/Logitech Logitech Cordless RumblePad 2", even though they are always connected to the same usb ports (and both simultaneously through the usb hub). It seems that sometimes my first controller will be "player 1" and sometimes it will be "player 2", which is quite annoying. I think that this issue should be very easy to fix, as udev is self-consistent and always assign the same device order regarding which usb port the gamepads are connected to.
For example, in the case of a PC that is dedicated to emulation-gaming : the actual behavior makes it impossible to know which controller will be the first one a priori, and thus force the user to go into the dolphin settings each time.
Could it be possible to fix this, maybe by using the udev "devnum" attribute or the /dev/input/js* numbers as sorting key, which give always the same order ?
Alternatively, is it possible to force the device path into the configuration (like /dev/input/js0, /dev/input/js1 ...) ?
Many thanks for you help,
François
Updated by batzkass about 5 years ago
EDIT:
Digging a little bit more gave these information:
- as soon as the gamepads are all plugged into the usb hub first, evdev always create the same inputN order (which is directly related to the usb physical order) -> this issue really seems to come from dolphin
- I don't get the issue if I plug my gamepads before launching dolphin (always all gamepads to the hub first, then to the computer). In this case, the order is the one given by evdev, itself given by the usb physical connection.
- So the issue seems to come from the hotplug function: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/InputCommon/ControllerInterface/evdev/evdev.cpp#L152 . Definitely, in this situation, the peripheral order given by dolphin are random instead of respecting evdev order. As a consequence, if you have multiple identical gamepads dolphin will enumerate them in a random order, which leads to the issue.
Hope this can help, even though I found a workaround: connect my gamepads before launching dolphin, thus disabling the need of the hotplug fonction.
Updated by Billiard26 about 5 years ago
- Subject changed from [Linux] Random uvdev gamepad order sequence ? to [Linux] evdev devices with the same name do not have consistent ordering
- Status changed from New to Accepted
- Assignee set to Billiard26
This is especially annoying with 4-port Mayflash adapters. One would expect ports 1-4 to be in the same order as Dolphin's device list but this is rarely the case even without hotplugging, at least on my system.
Thanks for the info. I'll look into the "devnum" attribute.
Updated by Billiard26 about 5 years ago
- Operating system Linux added
- Operating system deleted (
N/A)
Updated by batzkass about 5 years ago
Its great that you can look at that. I'm not sure that evdev is able to give the dev "devnum" attribute, but another solution is to get the number after the "event" in /dev/input/event*. As far as I could test it, this number is always well sorted according to the usb physical connection.
Updated by Billiard26 almost 5 years ago
- Status changed from Accepted to Fix pending
https://github.com/dolphin-emu/dolphin/pull/8569
It's worth noting that SDL exhibits similar problems even after this PR.
Updated by landeel over 3 years ago
Hello!
This is related: https://github.com/libsdl-org/SDL/issues/4430
Updated by landeel over 3 years ago
Looks like SDL fixed the issue with this commit: https://github.com/libsdl-org/SDL/commit/ba8bc143c1691a837a9265d1911ea737d7bb8002