USB ports no longer determine player number retroarch 1.7.1

RedBatman

Has anyone tested this with a 360 controller yet? Since that is what I mainly use a wireless 360 controller with an adapter.

mitu

@mediamogul said in USB ports no longer determine player number retroarch 1.7.1:

@lostless

You may be able to get by with setting all_users_control_menu = "true".

This is already set by the RetroPie installs script when installing RA (https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/emulators/retroarch.sh#L195).

@lostless I had the same thing happened (P1 disconnected, couldn't control with P2) before 1.7.1, so it's not something new.

mediamogul

@mitu said in USB ports no longer determine player number retroarch 1.7.1:

This is already set by the RetroPie installs script when installing RA

I might be wrong, but I don't think this would be set on an install that has been maintained for some time. Of course, I'm basing that notion on it never having been added to my own setup.

lostless

@mitu I think you may of misunderstood. Player one was the ps1 adapter because the ps3 controller was not on. All is good. Go to exit a game, can't. Hot keys not working. I had to turn on my ps3 controller which came up as player 3, but retroarch is set to have player 3 "JS2" as player 1. So the ps1 adaptor continued to be player one in game, but the hot keys only worked on the ps3 controller. Its really odd. there is no sense to the controller inputs anymore.

lostless

Update. After exhaustive testing, it seems controllers are no longer determined by the USB port, but by the order they are plugged in/turned on in retroarch 1.7.1. This applies to usb and Bluetooth controllers. You can go into the cong files and change which controller is player 1, but it can be deceiving because the retropie config files are still showing the order which they are plugged in via usb, but the real numbers are the order in which they are connected. So in my case, my ps1 adaptor is showing up as controllers 2 and 3 when I plug another controller into USB port 0. But since the pi booted with those in first, those are acutually js0 and js1. So to make the new controller player one, I have to select the ps1 adaptor, but it’s not, it’s the new controller I just plugged in. It is actually js2 and all I’m doing is telling retroarch that js2 is now player one. Bad part is if I unplug the 3rd controller, retroarch is still expecting js2 to be player one, so if i start a game, can’t do anything until a 3rd controller is plugged it making that one js2. This situation works well for Bluetooth controllers that will assign themselves based on when they turn on, but can wreck Havok on usb controllers that are always plugged in. It will assign players based on when Linux sees the controllers first. Some turn on quicker than others.

Clyde

@lostless Thanks for the update. Do you know how it is with two identical usb controllers? Are they being randomly assigned or … ?

zerojay

This is a really big problem for anyone that's using GPIO pins for a controller, ensuring that any other controllers will only ever be assigned js2/js3 and never being js0/js1 as the GPIO controllers will always be seen first.

lostless

@clyde Its not that they will be randomly assigned, it'll order them based on when they are seen. Is how quick the circuitry is in each controller.

@zerojay Ya it is a pain, You can reorder them in the configs, but you have to remember to change the configs back if you want to go back to the gpio controller.

zerojay

I'm wondering if the issue is this submit here: https://github.com/pyhammond/retropie_wiimote_lights/issues/1 -
https://github.com/libretro/RetroArch/commit/b14598657c4b813c555b6cc6c6e81ec0830621c4#diff-e24ecc035fba173802aca096d7675071

zerojay

@msheehan79 said in USB ports no longer determine player number retroarch 1.7.1:

Hi guys

I suspect this is related to the same issue I found with RA 1.7.1. My situation is a bit of an edge case but sounds like you are running into same issue.

In short, there was a commit to RetroArch between 1.6.9 and 1.7.1 that added a sort to the udev joystick numbers, so whatever device is in js0 is always player 1, js1 is player 2, etc. Since I use xboxdrv js0 is not necessarily player 1.

For me, I commented out the offending line in the source and recompiled RA from source and it works. Bit of a hack but it worked for me as I wasn't sure my situation was enough to justify a proper bug report. I'm happy to provide more detail on my workaround if needs be.

My original report is here: https://retropie.org.uk/forum/topic/16959/using-2-controllers-with-xboxdrv-p1-and-p2-controls-swap-almost-every-time-i-launch-retroarch-1-7-1/3

If you could provide more help on this, it would be appreciated, @msheehan79

Clyde

@lostless But shouldn't two identical controllers have the same speed?

However, I ordered a second sd card yesterday to test Retropie 4.4 for other reasons, so I will see how my two identical zero delay encoders will be assigned.

lostless

@clyde in theory. But with tolerances of components, we’re talking very little time differences.

msheehan79

@zerojay

Indeed the commit you referenced was the issue, at least in my case. I'd be curious to know if you find similar results as well.

For me, my quick test (and fix) was to comment out line 593 of input/drivers_joypad/udev_joypad.c, as that is the line that performs the actual sort and rearranges things. By removing this one line and rebuilding RetroArch from source, the issue was solved for me.

// Sort the udev entries by devnode name so that they are created in the proper order
qsort(sorted, sorted_count, sizeof(struct joypad_udev_entry), sort_devnodes);

If you want to test this but don't want to mess with the code, I uploaded a copy of the RetroArch binary (built on an RPI3B running Jessie), so if you have a similar OS and platform you could probably just copy this version into your /opt/retropie/emulators/retroarch/bin/ folder to give it a try and see if it solves your issue as well. This was a latest-at-the-time build of RA so it is an early build of 1.7.2.

https://mega.nz/#!0OwSGTaR!jA_35PEID2dbkBkEvW3iEBNAB7ItxEQKbSTGJxkCgD8

zerojay

Sooo... my little Pandora's Box conversion project kind of relied on this behavior working as I was hoping. This was going to allow my 8BitDo SN30 Pro controllers to be given priority as Player 1 and 2 if they were turned on just in case you feel like playing NES with a controller instead of an arcade stick. I just got done with the hardware side tonight. Everything is held down with 3M Dual Lock so nothing moves around inside at all whatsoever.

0_1524622957558_30806382_10155698782796731_6451044831141495061_o.jpg

So I decided to take a look at this problem and I was able to fix it.

Download this patch and place it into /home/pi/RetroPie-Setup/scriptmodules/emulators/retroarch/.

Download this retroarch.sh and place it into /home/pi/RetroPie-Setup/scriptmodules/emulators/, overwriting the one currently there.

So the patch just dummies out the qsort line which is the cause of all this. The updated build script for Retroarch just tells Retropie to add the patch before building... aaaaaaand...

...it works! Using the tool, I'm able to set my Bluetooth controllers to take priority just as I wanted once I've rebuilt RetroArch from source with this patch. Everything's working as it should. Hope this helps!

lostless

@zerojay using what tool? I don’t notice any change in behavior on my build.

mitu

@lostless I think @zerojay is using the Joystick selection tool created by @meleu to order the gamepads.

zerojay

Sorry, yes, I am. WIth the above stuff done, the tool works again. I'm happy.

Clyde

@lostless said in USB ports no longer determine player number retroarch 1.7.1:

@clyde in theory. But with tolerances of components, we’re talking very little time differences.

Indeed, and that's why I fear randomness. I'll report here as soon as I receive the sd card and find the time to test RP 4.4 on my setup with 2 "identical" DragonRise zero delay encoders.

I'll also test if connecting one decoder directly and the other through my powered usb hub makes any difference in the order of assignment.

zerojay

@msheehan79 said in USB ports no longer determine player number retroarch 1.7.1:

@zerojay

Indeed the commit you referenced was the issue, at least in my case. I'd be curious to know if you find similar results as well.

For me, my quick test (and fix) was to comment out line 593 of input/drivers_joypad/udev_joypad.c, as that is the line that performs the actual sort and rearranges things. By removing this one line and rebuilding RetroArch from source, the issue was solved for me.
// Sort the udev entries by devnode name so that they are created in the proper order
qsort(sorted, sorted_count, sizeof(struct joypad_udev_entry), sort_devnodes);
If you want to test this but don't want to mess with the code, I uploaded a copy of the RetroArch binary (built on an RPI3B running Jessie), so if you have a similar OS and platform you could probably just copy this version into your /opt/retropie/emulators/retroarch/bin/ folder to give it a try and see if it solves your issue as well. This was a latest-at-the-time build of RA so it is an early build of 1.7.2.

https://mega.nz/#!0OwSGTaR!jA_35PEID2dbkBkEvW3iEBNAB7ItxEQKbSTGJxkCgD8

Thanks, I hadn't seen your post when I wrote my own and figured out that the qsort was the problem. Would be nice if we could get it to be optional.

hansolo77

I've tried doing the # comment out method to remove the qsort function from the file specified, but have been unsuccessful. The only way I'm able to even edit that file is while the Retropie-Setup script it running the update from source. Any other time, the file doesn't exist (it downloads it as part of the update). So while the build is in progress, I've quickly opened up the file in nano via an ssh terminal. Added the # to the line, saved, and waited. I've got it done before the build reaches that file in it's process. It looks like it takes it and continues, but eventually the whole build crashes and says it was unable to complete.

I thought about forking the build to my own github, edit the file from there, and just rebuild by pointing the script to MY hub, but that will only work until I need another update in the future.

Is it possible to maybe update the setup scripts to include a .diff file that removes that update should a user require it?