Most recently connected Bluetooth controller becomes player 1?

vt_fbcoach

Yes, here is the output:

pi@retropie:~ $ cat /proc/bus/input/devices 
I: Bus=0005 Vendor=057e Product=0330 Version=0001
N: Name="Nintendo Wii Remote Pro Controller"
P: Phys=
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:74/0005:057E:0330.0001/input/input0
U: Uniq=
H: Handlers=js0 event0 
B: PROP=0
B: EV=20000b
B: KEY=f 0 0 0 0 0 0 0 7fdb0000 0 0 0 0 0 0 0 0 0
B: ABS=1b
B: FF=1 7030000 0 0

I: Bus=0005 Vendor=057e Product=0330 Version=0001
N: Name="Nintendo Wii Remote Pro Controller"
P: Phys=
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:69/0005:057E:0330.0002/input/input1
U: Uniq=
H: Handlers=js1 event1 
B: PROP=0
B: EV=20000b
B: KEY=f 0 0 0 0 0 0 0 7fdb0000 0 0 0 0 0 0 0 0 0
B: ABS=1b
B: FF=1 7030000 0 0

mitu

You issue sounds a bit similar to this issue on the wiimote_lights repository, except that in the reported case, the lights were switched differently. What's in common with that issue is the external BT dongle and I think the script has an option to switch the numbering if you choose the external install/configure options.

What's different is that - in your case - the /dev/input/eventX numbering is the same as /dev/input/jsX, so the RetroArch should choose js0 as P1 even if it sorts by/dev/input/eventX files.

If you're absolutely sure there's no input remapping taking place in RetroArch, try to get a verbose log when running a 2P game and post it on pastebin.com.

vt_fbcoach

Thank you for the help - here is the link to the verbose log from a 2P game (Super Mario Kart using lr-snes9x2010):

https://pastebin.com/MbNEjccy

These appear to be the lines of note where the controller input numbers are being assigned (lines 83-91 of the pastebin):

[WARN] [udev]: Couldn't open any keyboard, mouse or touchpad. Are permissions set correctly for /dev/input/event*?
[INFO] [udev]: Plugged pad: Nintendo Wii Remote Pro Controller (1406:816) on port #0.
[INFO] [udev]: Pad #0 (/dev/input/event1) supports force feedback.
[INFO] [udev]: Pad #0 (/dev/input/event1) supports 16 force feedback effects.
[INFO] [udev]: Plugged pad: Nintendo Wii Remote Pro Controller (1406:816) on port #1.
[INFO] [udev]: Pad #1 (/dev/input/event0) supports force feedback.
[INFO] [udev]: Pad #1 (/dev/input/event0) supports 16 force feedback effects.
[INFO] [Joypad]: Found joypad driver: "udev".
[WARN] [udev]: Full-screen pointer won't be available.

It appears to be using the event* handlers rather than the js* handlers, correct? But as you noted, event0/js0 and event1/js1 are assigned to the controllers in the order in which they were connected via Bluetooth. It is the Pad #* which does not appear to be correct.

For completeness, here is a copy of my retroarch.cfg file from /opt/retropie/configs/all:

https://pastebin.com/hQ4U2c4S

Clyde

The user @meleu made a script to change the player-controller assignment based on either name or joystick index. Maybe that could help?

https://retropie.org.uk/forum/topic/1167/here-is-a-way-to-select-joystick-for-players-1-4-global-or-emu-specific

vt_fbcoach

Thank you for the suggestion, but I'm not sure how effective that script will be given the last sentence of the readme file says:

If you are using joysticks with equal names, then, yes, the connection order matters.

and I am using controllers with equal names but the connection order is not being interpreted correctly.

Interestingly, if I connect the second controller midway through an already active game (for example, an arcade game such as the 2-player version of TMNT: Turtles in Time), the lights will still change as before when a new controller is connected (ie, C1 light changes from P1 to P2, C2 light shows P1). But the first connected controller will still be Player 1 and the second connected controller will be Player 2. If I exit to Emulation Station and re-enter the same game (or any others), the second connected controller will now be Player 1 and the first connected controller will be Player 2 (the original problem described in this thread).

vt_fbcoach

Ok, so it looks like the fix proposed and implemented by pyhammond for external Bluetooth adapters in 2017 is no longer present in the udev_joypad.c file of RetroArch as of this pull request in July 2019.

Reading through the pull request comments, it doesn't sound like anyone besides the author of the change actually tested this modification...

EDIT: Actually, it looks like this fix for external Bluetooth adapters was removed because of its impact on wired USB controllers: https://retropie.org.uk/forum/topic/17276/usb-ports-no-longer-determine-player-number-retroarch-1-7-1/59

So I guess it would be nice to have the option to re-enable the old qsort behavior? Or maybe I just need to modify the source code locally and re-compile?

mitu

Can you also take a look in /opt/retropie/configs/snes/retroarch.cfg to see if any joypad re-ordering hasn't been set ?

The patch mentioned in issue is now no longer part of RetroArch, it's been superseded by this one, which should produce identical results for your configuration (i.e. it uses the ordered /dev/input/eventX nodes).

vt_fbcoach

Here are the contents of my /opt/retropie/configs/snes/retroarch.cfg file:

# Settings made here will only override settings in the global retroarch.cfg if placed above the #include line

input_remapping_directory = "/opt/retropie/configs/snes/"

savefile_directory = "/home/pi/RetroPie/roms/snes/saves"
savestate_directory = "/home/pi/RetroPie/roms/snes/saves"

#include "/opt/retropie/configs/all/retroarch.cfg"

According to this post by pyhammond:

https://github.com/pyhammond/retropie_wiimote_lights/issues/1#issuecomment-362658937

"The problem with the emulators seems to be that internally, they loop through and do a specific system-call [ udev_enumerate_get_list_entry() ] in order to get the controller from the system. When you are using an external dongle, for some reason the controllers don't come back from the system call in the order that they appear under /dev/input. That's where the discrepancy lies."

So the fix implemented by pyhammond corrected this issue for Bluetooth controllers with an external adapter, but that presented problems for users with controllers wired to specific USB ports:

And was ultimately reverted in these two commits to RetroArch:

https://github.com/RetroPie/RetroPie-Setup/pull/2400 (May2018)
https://github.com/libretro/RetroArch/pull/9074 (July 2019)

But it doesn't seem like either of these two more recent changes took into account the reversed ordering of Bluetooth controllers with an external adapter returned by udev. So I can appreciate why this fix was removed, but it would be nice to have the option to use it again when only Bluetooth controllers are being used with an external adapter.

mitu

@vt_fbcoach said in Most recently connected Bluetooth controller becomes player 1?:

Here are the contents of my /opt/retropie/configs/snes/retroarch.cfg file:

That doesn't look like it has any impact on controller ordering.

So I can appreciate why this fix was removed, but it would be nice to have the option to use it again when only Bluetooth controllers are being used with an external adapter.

I wouldn't be so sure that the patch would yield the desired effect and would worth the trouble.

For your immediate purposes, something inspired by

vt_fbcoach

For your immediate purposes, something inspired by

@mitu Sorry, it looks like your message may have been prematurely cut off?

I've seen some posts online that this external Bluetooth adapter ordering issue is unique to udev, so I'll try changing input drivers to something else like sdl2 and report back.

mitu

@vt_fbcoach said in Most recently connected Bluetooth controller becomes player 1?:

@mitu Sorry, it looks like your message may have been prematurely cut off?

Yes, somehow I pressed enter before actually giving an answer, sorry.
You could leverage the onstart/onend scripts for runcommand to switch dynamically the joypad indexes when 2 gamepads are detected. Something similar to https://github.com/meleu/RetroPie-joystick-selection.