Most recently connected Bluetooth controller becomes player 1?

vt_fbcoach

Pi Model or other hardware: 3B+
Power Supply used: CanaKit 5V 2.5A Raspberry Pi 3 B+ Power Supply/Adapter
RetroPie Version Used: 4.6.9
Built From: Pre made SD Image on RetroPie website
USB Devices connected: 128 GB flash drive; TP-Link Bluetooth adapter
Controller used: Wii U Pro Controller (x2; originals bought in-store)
Guide used: https://retropie.org.uk/docs/Bluetooth-Controller/

Due to frequent ghost inputs with my two Wii U Pro Controllers (e.g., randomly exiting a game, starting a different ROM from the Emulation Station menu, etc) I recently purchased an external TP-Link USB Bluetooth dongle (see above). After disabling the internal Bluetooth by adding dtoverlay=pi3-disable-bt to /boot/config.txt, connecting the USB dongle, and re-pairing the two Wii U Pro Controllers, everything seems to be working fine and I haven't noticed any ghost inputs over the last few days.

I have also installed pyhammond's retropie_wiimote_lights script to correctly display the player number lights on each of the Wii U Pro Controllers (by default they will always show the P1 light). After installing this script, I have noticed some strange behavior with the player number assigned to each controller which I am not sure whether to attribute to the USB Bluetooth adapter, Emulation Station, RetroArch, or something else entirely. For example,

Connect a controller (C1) and its P1 light turns on
Connect a second controller (C2) and its P1 light turns on; C1's light changes from P1 to P2
When playing a multiplayer game, C2 does indeed control Player 1 and C1 controls Player 2 as indicated by their lights

However, jstest shows that js0 does in fact correspond to the first connected controller (C1 controlling P2) and js1 corresponds to the second connected controller (C2 controlling P1). Is this the expected behavior that the most recently connected controller takes over as Player 1 and bumps all previously connected controllers to higher player numbers? Or is this some quirk of the external USB Bluetooth dongle?

To test, I have deleted the wii-controller.service file copied by the retropie_wiimote_lights script to /etc/systemd/system/ and the above described behavior persists, so I do not think that script is the issue. I have also checked the contents of my retroarch.cfg file at /opt/retropie/configs/all and can confirm the joypad index values have not been modified from the defaults. And I have tried uncommenting the first two joypad index lines (input_player1_joypad_index = 0 and input_player2_joypad_index = 1) but even after rebooting the system the second connected controller always takes over as Player 1. Unfortunately I do not have any other controllers (wired, Bluetooth, or otherwise) with which to test this behavior.

Thank you for the help!

mitu

Can you run (with both controllers connected)

cat /proc/bus/input/devices

and post the output ?

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.