WiiU Pro controller order reversed compared with LED lights with RetroArch cores

[sonicsheppard]

I've noticed an issue where the controller order seems to be reversed when using RetroArch cores.

For example if I connect 4 controllers WiiU Pro controllers, controller 1 will have 1 LED, 2 will have 2 LEDs etc, but if I launch a RetroArch core, Player 1 will be the controller with 4 LEDS, Player 2 will have 3 LEDs etc.

This issue is not present with non-RetroArch cores.

Pi Model or other hardware: Raspberry Pi 3 Power Supply used: 5V 3A USB mains power supply. RetroPie Version Used: 4.3 updated to latest retropie_script 4.3.5 Built From: Made from 4.3 image, fully updated. USB Devices connected: USB Logitech Bluetooth dongle, HyperX 256GB USB flash drive. Controller used: Wii U Pro Bluetooth controllers (2x official Nintendo, 2x 3rd party) Guide used: https://github.com/RetroPie/RetroPie-Setup/wiki/Wii-U-Pro-Controller https://github.com/pyhammond/retropie_wiimote_lights Emulator: All RetroArch cores tried so far.

How to replicate the problem: 1.Install 4.3 image and fully update all scripts and cores using Binary. 2.Install the retropie_wiimote_lights script using the guide - https://github.com/pyhammond/retropie_wiimote_lights 3.Connect 4 WiiU Pro Bluetooth controllers so the LEDs light up as per retropie_wiimote_lights script 4.Launch a RetroArch core with a 4 player game (e.g. Mega Bomberman on lr-genesis-gx-plus) 5.Note the order of the players compared to the LED lights - they are in a reversed order.

[pyhammond]

Would you mind posting the output of this command when logged into your retropie as the "pi" user?

grep joypad_index /opt/retropie/configs/all/retroarch.cfg

I suspect that the ordering of your controllers is possibly reversed in your retroarch.cfg file. If you straighten them out, then the lights should work correctly.

Please let me know if this guess is wrong.

[sonicsheppard]

The output from grep joypad_index /opt/retropie/configs/all/retroarch.cfg is as follows:

input_player1_joypad_index = "0"

input_player2_joypad_index = "1"

input_player3_joypad_index = "2"

input_player4_joypad_index = "3"

input_player5_joypad_index = 4

input_player6_joypad_index = 5

input_player7_joypad_index = 6

input_player8_joypad_index = 7

Is there anything you would suggest changing them to?

Thanks very much. Please let me know if there's anything else I can get for you.

[sonicsheppard]

If I swap the numbers around for the joypad_index (e.g. input_player1_jypad_index = "3"), then the controller with 1 LED is player 1.

[pyhammond]

Your problem seems to be something in your retroarch configuration. I have 4 joysticks setup as well on my retropie v4.3 and I don't have the reverse ordering issue you are seeing in the libretro games. I do know that retroarch does allow you to re-order your controllers and it can happen at one of several points in different config files.

I'd take a read through the retroarch config instructions at the wiki here. Specifically, read through both of these sections:

1. RetroArch Configuration: Hardcoded Configurations
2. RetroArch Configuration: Core Input Remapping

The retropie_wiimote_lights scripts don't care if you are using retroarch or anything else on top of it. All that the scripts do is map the lights on the controller to which # of joystick device it is registered to.

Perhaps you can verify that this is correct by testing the controllers with the following commands as the 'pi' user:

jstest /dev/input/js0
jstest /dev/input/js1
jstest /dev/input/js2
jstest /dev/input/js3

js0 maps to controller 1, js1 to controller 2, etc. When you run one of those commands, you should be able to push buttons and move the joypad on the controller and see things change.

If the lights match the number of the mapped input device on the pi, then the issue lies somewhere inside one of your retroarch config files. If not, please let me know and I'll work on trying to duplicate what you are seeing on my end. So far, however, I can't seem to duplicate it on my end.

I suspect it's somewhere in your retroarch config, however, since you only see it happening in retroarch core emulators. My lights scripts don't run that deep. They just match up the lights with which # they match up to under /dev/input/js?.

If you figure it out, please let me know. I'm really curious about what the issue is, to be honest.

[pyhammond]

I suspect it could be that you've re-configured your Core Input Remapping for whatever emulator you are using (i.e. lr-genesis-gx-plus) to use the controllers in a different order.

If you know how to hold down select and type the X button as player 1 (that's how it's configured by default, anyway) to go into the retroarch config, do that and read through the instructions here to possibly re-map the joysticks back to normal and then save them for the core that way. Or for all of retroarch.

[sonicsheppard]

Hello, firstly just wanted to say thank you very much for your assistance on this. I think you're correct in that it must be a RetroArch config issue that I've done somewhere along the way, rather than anything with your scripts.

I read through the documentation and I ran through the jstest and everything matched up, jstest js0 was the controller with 1 LED etc.

I did have a few core remaps set up, for things like 4 player games, I have deleted every remap file I could find but I'm still experiencing the issue.

I have removed them from /opt/retropie/configs/all/retroarch/config.

I checked the retroarch.cfg from /opt/retropie/emulators/retroarch and /opt/retropie/emulators/retroarch/etc and also the one in /opt/retropie/configs/all. Everything looks in order and looks to be default.

I'm at a bit of a loss!

To confirm this issue I'm seeing is also present when just using 2 controllers, it's not dependant on being 4.

Any other suggestions before I go down the route of wiping and starting again would be hugely appreciated. Thank you so much for your time.

If you wish to close this Issue and use the RetroPie forum post I entered instead then please do - https://retropie.org.uk/forum/topic/14701/wiiu-pro-controller-order-reversed-compared-with-led-lights-with-retroarch-cores-with-retropie_wiimote_lights-script/3

[pyhammond]

Just curious about something. What does the output of this command say ?

grep input_joypad_driver /opt/retropie/configs/all/retroarch.cfg

Mine is "udev". It looks like this:

input_joypad_driver = "udev"

[sonicsheppard]

Hello, apologies for the late reply, I was attempting this from a completely fresh install - however I'm still seeing the same problem.

To confirm my input_joypad_driver is "udev" in the retroarch.cfg.

I have done the following:

1) Wipe SD card and install latest RetroPie 4.3 RaspberryPi3 .img from retropie.org.uk 2) Perform a full Raspberry Pi update using sudo-apt-get update and sudo apt-get upgrade 3) Update RetroPie-Script to 4.3.7 (current latest) 4) Update all cores and systems using latest Binarys (RetroArch is at 1.6.9) 5) Add 4 Nintendo WiiU Pro Bluetooth controllers (2 official, 2 3rd party) 6) Install retropie_wiimote_lights script - confirm working with WiiU Pro lights (successful) 7) Launch a RetroArch core and game - e.g. Super Bomberman 3 with lr-Snes9x 8) Test order of controllers, including which controller has access to RetroArch menu with Hotkey+X (should be player 1, but it's only the "last" controller (e.g with 4 lights) that can access the RetroArch menu.

A couple of points that I thought may be of value

I'm using a USB flash drive for ROMs I'm using an external Logitech Bluetooth dongle and have internal Bluetooth disabled with dtoverlay=pi3-disable-by I find the internal Bluetooth to be inconsistent and interferes with WiFi, so use a Bluetooth dongle instead.

[sonicsheppard]

I've tracked down the problem! It's the external Bluetooth dongle.

Steps to repro:

1. Wipe SD card and install latest RetroPie 4.3 RaspberryPi3 .img from retropie.org.uk
2. Add 4 Nintendo WiiU Pro Bluetooth controllers (2 official, 2 3rd party)
3. Install retropie_wiimote_lights script - confirm working with WiiU Pro lights. Controller with 1 LED confirmed to be player 1 (has access to RetroArch menu etc).
4. Disable onboard Bluetooth with dtoverlay=pi3-disable-bt and insert external USB Bluetooth dongle.
5. Re-connect WiiU Pro Bluetooth controllers
6. Test order of controllers again - Now the order is reversed!

Please let me know if there's anything else I can do for you.

Thanks.

[pyhammond]

Wow, that is interesting. It's definitely something related to the internals of RetroArch it seems.

I'd recommend perhaps creating an issue with the RetroArch group here.

Also, while poking around Github, I noticed this interesting project that may help with your problem. I haven't tried it, to be honest. It just looks like a possible work-around maybe.

Thanks for reporting back what you found. I'm going to close this ticket, since it really isn't my light toggle script that is the issue. It's something related to retroarch in combination with a 3rd party BT dongle.

Best of luck !

[pyhammond]

So guess what ? I was actually able to duplicate your issue. I was building a mame box for a friend and he was using an external usb bluetooth dongle, and we ran smack into your bug.

I just figured out where the bug was in the RetroArch project and created a patch for it that I plan to submit to them.

Meanwhile, here's my patch and some instructions on applying it to your local setup. First, you need to quit EmulationStation and get to a command prompt on your pi. Then run these commands:

cd ~/RetroPie-Setup
wget https://github.com/pyhammond/retropie_wiimote_lights/files/1546562/pyh_retropie_setup_patch.diff.gz
gunzip -c pyh_retropie_setup_patch.diff.gz | patch -p1
sudo ./retropie_setup.sh

Now in the RetroPie-Setup menus, pick through and rebuild RetroArch from source like this:

• P - Manage packages
• core - Manage core packages
• 139 retroarch (Installed)
• S Update from source

Now let it compile and rebuild retroarch. Then reboot your pi and WALA - it works now.

Best of luck !!!

Here's my patch file if you want to download it and keep it around..

[pyhammond]

Wow, that was fast. They accepted my change into the RetroArch code just now. It's been accepted into RetroArch through this patch here.

It may take a while to get that patch applied to the downstream code used by RetroPie-Setup. I see that they are using a specific release version (v1.6.9) of the RetroArch code in RetroPie-Setup.

Meanwhile, you'll need to apply the patch I created (as shown above) until that fix hits the downstream RetroPie-Setup code.

Have a good one ! Happy Christmas / Hanukkah / Holiday !

[sonicsheppard]

Thank you so much for this!

Very sorry for the late reply (been ill recently - cold/flu season!), but I'll try an update to RetroArch from Source on Raspberry Pi as soon as possible top confirm.

Glad you were able to spot it, hope it wasn't too much hassle for you to patch.

Thanks again!

[koboltzz]

@pyhammond Thank you, I can confirm that your patch fix the problem for retroarch therefore for every libretro 'lr-xxxxx' emulator. My question is, do you know a solution for mupen64 too? The problem is the same, the last connected wii u pro controller will be Player 1. If you play with 3 Player, the controller with three lights on will be Player 1 ingame...

[pyhammond]

So, are you using a Raspberry Pi 3 ? With an external Bluetooth dongle ? Give me some specifics on your setup and I'll take a look in the next few days and see what I can do.

Also, are you adding the controllers before launching the game in mupen64 or in-game ? Is this mupen64plus you are talking about ?

[koboltzz]

Everything the same like @sonicsheppard wrote. But 4 instead of 2 official Nintendo Wii U Pro Controllers, a Logilink Bluetooth dongle instead of Logitech and a 5,25V 3A power supply. But I don't think this will make a difference at all in this case ;)

Yes, I add all 1,2,3 or 4 controllers (depending on available players) always before launchuing a N64 game. Always the last connected controller will be Player 1. I am taking about mupen64plus-auto sometimes with gles2rice, gles2rice-highres or GLideN64, GLideN64-highres. Everything leads to the same result.

This sounds great and I am very happy to get your help, thank you :)

[koboltzz]

Just in case you didn't already notice, seems like every emulator other than libretro (after your patch) is affected from this problem (hatari and vice tested). I don't know if this information will help you or instead means a lot of work or means it is unfixable. If it means a lot of work/unfixable, then maybe a mupen64plus only patch like you did for retroarch would be reeeeally great, since I use libretro and mupen64plus only 99% of the time :) Thanks again for your support

[pyhammond]

So interesting. Weird but interesting.

Just so you know how the lights scripts work, they number the lights on each controller according to how they are numbered under /dev/input on your linux system. So, for example:

/dev/input/js0 = controller #1 /dev/input/js1 = controller #2 /dev/input/js2 = controller #3 /dev/input/js3 = controller #4.

Emulation Station uses them in this order. When you launch an emulator from inside of Emulation Station, the emulator is then in charge of figuring out which controller is which, etc.

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.

I don't typically contribute to retroarch or any other emulators. But, I did dive in and build a patch for retroarch that fixes this issue for retroarch cores. My patch that I made for retroarch (which they accepted into the retroarch core) alleviates this by looping through the udev_enumerate_get_list_entry() system call and then sorting the inputs in order of their /dev/input/js# number before assigning the controllers to the emulator. I'm still a bit confused why they come back from that udev_enumerate_get_list_entry() call in the wrong order.

The strange thing is that they don't have that problem when you are using the internal pi bluetooth controller. It only occurs when you are using an external bluetooth dongle.

If I can figure out how to get the lights to mimic the behavior of the emulators, maybe I'll look into doing that. My initial assumption was that doing it in order of their appearance under /dev/input/ would be the correct assumption, since it worked great for me when I was using the internal pi bluetooth controller.

I'm going to investigate this further. It's not necessarily a trivial thing, but I'll look into it.

[pyhammond]

OK. I did a little research. This is so strange, because if you use an external bluetooth dongle, the results you get back from iterating through bluetooth devices using the udev_enumerate_get_list_entry() after calling udev_enumerate_scan_devices() in C are exactly opposite then when you are using the internal bluetooth controller on the Pi3.

If any of you want to replicate what I've done, Here's how. I am attaching a small C program that I used to test this. You first have to compile the C code with this command-line:

gcc -Wall -ludev -o udev_test udev_test.c

Then, connect up your BT controllers and run the udev_test program after you've compiled it on your pi.

If I'm using an external dongle, it comes across in the EXACT OPPOSITE order from when I'm not. SO FRUSTRATING !!!

So, perhaps what I'll do is this: I'll make two versions of the Wii_Lights script - one for internal BT dongle, one for external (that does the exact opposite). Then I'll ask you in the install script which one you want to install and you can choose yourself. Does that work ?

Here's the attached C program I used to test this: udev_test.zip

BTW, here are my results with just 2 controllers attached (both w/ external dongle and w/o)

## Using External Bluetooth Dongle:

Printing out udev devices I get back from
udev_list_entry_get_next() in the order I get them:

Device: (null)
Device: /dev/input/event3
Device: /dev/input/js1
Device: (null)
Device: /dev/input/event2
Device: /dev/input/js0

## Using Internet Pi3 Bluetooth:

Printing out udev devices I get back from
udev_list_entry_get_next() in the order I get them:

Device: (null)
Device: /dev/input/event2
Device: /dev/input/js0
Device: (null)
Device: /dev/input/event3
Device: /dev/input/js1

[koboltzz]

You are right, it will be always the opposite order when using a dongle.

So the 'easyest' way would be a new 'wiimote light mod for bluetooth dongle'? Just start with one light for the first controller, after connecting the second controller give him also one light and change first connected controller to two lights and so on....

Then I need also a 'undo' for your retroarch patch, need I?

[pyhammond]

Done. I just did that. Get into a command-prompt shell on your pi through the terminal or ssh into it and run these commands:

1. cd ~/retropie_wiimote_lights
2. git pull
3. ./install.sh

It should now ask you if you want to use "internal" or "external" bluetooth and apply the correct script for each case.

Important Note: If you tell it "external", it will reverse the order, so if you've patched your RetroArch stuff with my patch from above, it will be reversed for RetroArch-based emulators. So, time to update your retroarch stuff from binary or un-apply my patch from above using patch -R. The -R flag to patch reverses the patch and effectively un-installs it.

Please let me know if you run into issues !

-Peter

[pyhammond]

So, just to clarify, here are the steps to UNINSTALL my patch for RetroArch:

cd ~/RetroPie-Setup
wget https://github.com/pyhammond/retropie_wiimote_lights/files/1546562/pyh_retropie_setup_patch.diff.gz
gunzip -c pyh_retropie_setup_patch.diff.gz | patch -p1 -R
sudo ./retropie_setup.sh

[pyhammond]

I just committed another change tonight that gives you 4 different options when you install. Read the README.md file for more info on how this works now.

-Peter

[koboltzz]

Hello @pyhammond many thanks for your fast and very well done work :) Everything works as expected after following your instructions, but... the 'hotkey', which you can configure in emulationstation and which I set to 'HOME' button (since the beginning) don't work anymore as hotkey. Then I thought, 'okay, I just need to set up hotkey again in emulationstation' but after that still no emulator recognizes the 'HOME' button -> hotkey is now hardcoded to 'SELECT' button for any reason... I am not able to change it back in any emulator (libretro, vice, mupen64plus etc.) Also: In mupen64plus is the button to confim a selection is now 'A' instead of 'B' which it was before appying your patch. So, all the button configuration seems to be vanished and uses what it want instead what I want.

[pyhammond]

Thanks for the feedback @koboltzz

I just made some other changes to my installer script based upon your feedback. If you do another git pull in the retropie_wiimote_lights directory now, it will update it from github.

The install shell script up until just now used to overwrite some config files with my custom versions. I forgot it was doing that until you mentioned this just now.

As of now, I just made the install.sh file much smarter and kinder. It now asks you before it overwrites any config files. It has always backed up the original config files in any case.

I also just created a new script called _restore_oldconfigs.sh that will put back your backups it made before overwriting them when you installed the script. Try running that and you should get back your original setup.

The installer script first backs-up, then tweaks / overwrites these config files on your system:

/opt/retropie/configs/all/retroarch/autoconfig/Nintendo\ Wii\ Remote\ Pro\ Controller.cfg
/opt/retropie/configs/daphne/dapinput.ini
/opt/retropie/configs/n64/InputAutoCfg.ini
/opt/retropie/configs/n64/mupen64plus.cfg

Running that new _restore_oldconfigs.sh script should restore the configs to their original state. If not, you may just need to edit those files to put your hotkey back to what it was.

-Peter

[koboltzz]

Okay done :) But don't you agree, configuring the input in emulationstation should always apply, even after your custom versions were copied? Your penultimate script version did not only copy custom configs, it prevented emulationstation to take control over the input configs forever. May I ask why there are custom input configs intregrated? Luckily restore_old_configs.sh saved my work :D Anyway I am very happy thanks to you work and pleasant behaviour :)

[pyhammond]

Yes, I do agree that emulationstation should always override the config. I have found, sadly, that that is not always the case.

You may be right about not including custom configs. The truth is that I originally built this for myself and including my own painfully hand-tweaked configs just made sense since I was maintaining this on several retropie setups with the same controllers. It just made it convenient for me.

The configs that get installed sit under the configs directory if you want to look at them. I spent many hours hand-tweaking those to make everything work perfectly for me. I guess that's why I included them.

Thanks for the feedback. I hope it still keeps working. I'm going to continue to investigate the udev layer to see if there is some easy udev tweak to make the external bluetooth stuff always report itself in the same order as the internal one. Seems like there should be able to instruct the udev layer to do that. Still looking for the magic key for that.

-Peter

[koboltzz]

Without a doubt your controller configs are painfully hand-tweaked :) Personally I think using 'home' button as global hotkey makes more sense (than 'select') since this button won't even be recognized in many emulators as a real controller button (for example dosbox). Just my opinion and starting a friendly discussion. Also I like to have the physical arrangement of the buttons like on original used controllers (since I am not looking at button naming while playing a game). Take a look at N64 and you will see that 'brake' in 'Mario Kart 64' is set on 'B' on the outer left therefore it should be 'Y' on Wii U Pro Controller. I think you last script version is already the right solution but don't let me stop you in investigating udev. Maybe you would like to add an other query in your script which will ask the user if he wants to overwrite his current controller config with your version?

[pyhammond]

Thanks, @koboltzz I appreciate your feedback. I may make some changes to my configs - especially the n64 one - based upon your feedback.

I did change my installer to ask before installing those config files already. I think I committed that at the same time I committed the uninstall script that you already used.

Best of luck ! Thanks for your feedback. It's always welcome !

[cns-panikk]

Just a heads up I personally am using an ASUS BT400 on my Raspberry Pi 3 running whatever is current as of today and I had lights in reverse order when initially installed even though I selected External (option 2). Running the script again but selecting Internal (despite disabling it) fixed it and lights are now in proper order. Not sure if that's due to the script looking for the first or primary bluetooth and somehow that is now my asus bluetooth adapter, but I thought I'd put that out there for anyone else who has that issue. Excellent script! Love it!

[pyhammond]

Interesting. Just out of curiosity, are you running the newest RetroPie 4.4 image that was released on April 14th ? Is this a fresh install of the image ?

If you wouldn't mind, would you post the output of this command from logging into your retropie box ? cat /etc/os-release

The reason I had to make the script do it both forward and backward is because there was a bug in the udev layer that would make discover the controllers in reverse order ONLY with external bluetooth dongles. I'm wondering if that bug has been fixed in the latest release of Debian 9 (stretch). Under Debian 8, it still existed, and therefore I had to make it work both forward and backward.

The latest RetroPie 4.4 images are now running on top of Debian 9 (stretch) rather than Debian 8 (Jessie). So, I'm just curious if that is what is making the difference here.

[vtfbcoach]

I don't typically contribute to retroarch or any other emulators. But, I did dive in and build a patch for retroarch that fixes this issue for retroarch cores. My patch that I made for retroarch (which they accepted into the retroarch core) alleviates this by looping through the udev_enumerate_get_list_entry() system call and then sorting the inputs in order of their /dev/input/js# number before assigning the controllers to the emulator. I'm still a bit confused why they come back from that udev_enumerate_get_list_entry() call in the wrong order.

So as of July 2019, it seems like your fix was removed from retroarch by this pull request: https://github.com/libretro/RetroArch/pull/9074

which is frustrating, because it seems that once again the controllers are now being assigned in the opposite order of their /dev/input/js* indices when using an external Bluetooth adapter (ie second connected controller is Player 1, first connected controller is Player 2). Am I interpreting that correctly?

[pyhammond]

At some point in the install.sh script, it asks if you are using an "external" or "internal" bluetooth controller. Try choosing the opposite of what you chose last time when you run that install script. Does it solve the issue ?

[vtfbcoach]

Yes, when I use the "external" option with the install script then the lights are correctly identifying the controller number.

However, my problem is that when I run the udev_test C program you had shared in this issue a few years ago, it confirms that when using an external Bluetooth adapter the controllers are being returned in the reverse order in which they were connected. Unfortunately, the fix you had previously applied to RetroArch to address this issue (https://github.com/libretro/RetroArch/commit/b14598657c4b813c555b6cc6c6e81ec0830621c4) has since been removed (it sounds like it caused problems for users who wanted to use wired / USB controllers).

For reference, I created a topic on the official RetroPie forums where I described this problem before eventually realizing it was one you had previously solved: https://retropie.org.uk/forum/topic/28243/most-recently-connected-bluetooth-controller-becomes-player-1/

[pyhammond]

@vtfbcoach Yes, that is unfortunate that they would remove that patch instead of attempting to make it work correctly for all users. It sets the Bluetooth controller users back just a bit.

If I understood better the issue that caused it’s removal, perhaps I could create a better “fix” that would make everyone happy going forward. You’d think this would be a priority for the RetroPie devs.

[vtfbcoach]

@pyhammond perhaps making your previous fix optional via a flag in the retroarch.cfg file would satisfy those who do not want to use it, while still helping those of us who rely on an external Bluetooth adapter?

After looking through the commit histories more closely, it appears the fix was first disabled in RetroPie in May 2018 (https://github.com/RetroPie/RetroPie-Setup/pull/2400) based on user feedback in the RetroPie forums and a RetroArch issue:

• https://retropie.org.uk/forum/topic/17276/usb-ports-no-longer-determine-player-number-retroarch-1-7-1
• https://github.com/libretro/RetroArch/issues/6707

Then later in July 2019, a change was made in RetroArch to handle more than 10 controllers which fully removed your qsort implementation:

• https://github.com/libretro/RetroArch/issues/9071
• https://github.com/libretro/RetroArch/pull/9074

[clebercasali]

This is related: https://github.com/libsdl-org/SDL/issues/4430

[clebercasali]

SDL fixed a similar issue with this commit: https://github.com/libsdl-org/SDL/commit/ba8bc143c1691a837a9265d1911ea737d7bb8002