USB ports no longer determine player number retroarch 1.7.1

lostless

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

msheehan79

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?

mitu

@hansolo77 Comments in C/C++ are done with // at the beginning of the line or enclosing the code between /* and */. The # character does something else.

zerojay

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

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?

All you have to do is just use the two files as given in my post above.

hansolo77

I shouldn't have to do anything though.. This problem will pop right back up when another update is released.

hansolo77

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

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!

Tried doing this method just now.. all I get is a failed attempt, saying this:

Cloning into '/home/pi/RetroPie-Setup/tmp/build/retroarch'...
patching file input/input_driver.c
Hunk #1 succeeded at 406 with fuzz 2 (offset 287 lines).
Hunk #2 FAILED at 916.
1 out of 2 hunks FAILED -- saving rejects to file input/input_driver.c.rej
patching file menu/widgets/menu_entry.c
Hunk #1 succeeded at 474 (offset -69 lines).
patching file input/drivers_joypad/udev_joypad.c
Hunk #1 succeeded at 588 (offset -3 lines).

EDIT
I think I fixed it.. Had to do a couple of things first (not sure which did the trick):

Edit the diff to remove the Time Stamps indicated in the file. I thought it wasn't working because the times/dates were different from mine.
Edit the diff to find the correct line number to inject the change. Originally it was 591, I changed it to 589 because the one located in the github starts that line there.
Update the retroarch script to remove the trailing v1.7.1. @meleu discussed with me this was necessary to get the latest version that includes the cheevo fixes for FBA.
Update the Retropie-Setup script to the latest version (this was probably the only thing I needed to do but hadn't thought of it till the very end).

EDIT
Nope, still doesn't work. After rebooting the system, it still detects based on port.

zerojay

You're deciding to ignore what I'm telling you to do and then complaining it doesn't work so there's nothing more that I help you with here.

Works 100% here with the instructions given and the files as presented.

hansolo77

I get it, you don't have to be so rude about it. :( I was just trying to get FBA cheevos to work. That's what my original plan was all along. I have no doubt the files you made would work to a user needing 1.7.1. But I need 1.7.2 at the least. Thank you though!

EDIT
I fixed it. Re-copied over your original diff and script, then all I had to do was change the line that it injects the changes to. Works perfectly now. Thanks again. :)

dankcushions

this has been raised over at retroarch: https://github.com/libretro/RetroArch/issues/6707

keep an eye on that issue - hopefully some kind of option can be developed to control this behaviour

Darksavior

@hansolo77 You can always install 1.7.2 by editing the retroarch sh file in the retropie-setup folder.

zerojay

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

this has been raised over at retroarch: https://github.com/libretro/RetroArch/issues/6707

keep an eye on that issue - hopefully some kind of option can be developed to control this behaviour

I tweeted to them about wanting this as well. Hope to see this happen.

edmaul69

I guess im the only one that didnt have this issue. All controllers are still in the same order based on usb port.

mitu

@edmaul69 Are they always connected or you plug them after starting the system ?