Sony DualShock 3 - call for testers: "sixaxis" script module

edge3000

@Silent For me with official dual shock 3's it just says Searching.... and I paired 5 controllers in a row without the screen changing... eventually it times out and I see that they are all in fact paired. I believe I had to plug in the cable, unplug the cable, plug it back in and press the playstation button for it to light up a controller number LED... as soon as it does that you're good.

I didn't worry too much about it because I only had to do it once, but it would be nice if that searching screen had a way to cancel - if you hit CTRL-C it jumps back to emulationstation, but if you go back in to bluetooth it will still be searching (usually times out after that).

psyke83

@edge3000 said in Sony DualShock 3 - call for testers: "sixaxis" script module:

@Silent For me with official dual shock 3's it just says Searching.... and I paired 5 controllers in a row without the screen changing... eventually it times out and I see that they are all in fact paired. I believe I had to plug in the cable, unplug the cable, plug it back in and press the playstation button for it to light up a controller number LED... as soon as it does that you're good.

I didn't worry too much about it because I only had to do it once, but it would be nice if that searching screen had a way to cancel - if you hit CTRL-C it jumps back to emulationstation, but if you go back in to bluetooth it will still be searching (usually times out after that).

There's some variance in the behaviour of the controller (and version of Bluez). In the older version of Bluez, if an unpaired controller in scanning mode (flashing LEDs) is connected via USB, it won't bind to the connection unless you press the PS button.

A commit has been applied to clarify the message and ensure that the "Searching..." part no longer has the possibility of hanging infinitely. Make sure to update your script so it includes this commit: https://github.com/RetroPie/RetroPie-Setup/commit/6ce74e997efa2a6109b5db8884ce8f7e2032f5f0

Another issue that's not entirely clear for end-users is that once you've successfully initiated the registration via USB cable connect, it's not necessary to choose a security mode on the next page (as the controller is already registered, and choosing any option will only cause an error). I'd like to clean that up, but I first need to ensure that the existing changes to the script haven't caused regressions for other BT peripherals.

psyke83

@Silent said in Sony DualShock 3 - call for testers: "sixaxis" script module:

I am not convinced I understand the flow of pairing DS3's via Bluetooth. Here now it went for me now, after I restored pre-sixaxis image from a backup, updated emulationstation and retropie-setup and then applied an updated sixaxis branch:

Installation went without any issues

For the first gamepad, during "Register Bluetooth Devices" process there was no mention of DualShock 3 (just "Searching..."), and I had to manually pick a pairing mode after DS3 was detected. I don't recall having to do that before I rolled back - is it because back then custombluez was being installed?

For the second gamepad, I am seeing the notice about DS3 (plug/unplug/replug), but I don't know how long am I expected to wait and sit idle on this screen. Feels like eternity, but it eventually did switch screens.

Also, I noticed bluez showed for update - a version newer than 5.48 was included officially into Stretch now maybe?
EDIT:
bluetoothd -v actually shows 5.43... not sure what did it show before the update.

See my reply to @edge3000, but to clarify some more:

You're correct that previously it wasn't necessary to choose a security mode. We had to revert that functionality due to a regression with other BT peripherals. I may re-introduce a better fix for this, but only after we've confirmed that no other regressions are outstanding. For now, you can just cancel out of that menu (as none of those options apply, and your device will already be registered).
The "DualShock" text is displayed only if the hid-sony kernel driver is loaded. So if you didn't plug a controller in via USB before running the script, you won't see the text (but the script will still successfuly set up registration via USB cable connect regardless of whether the text was shown).
I just checked, and there have been no recent updates to the system BlueZ packages. Official controllers and the RetroPie scripts should work fine with the existing version, so don't install the new packages via custombluez unnecessarily.

edge3000

@psyke83 Thanks that should make pairing easier!

Are your previous fixes/changes from the sixaxis PR added to the main branch yet? I'm looking forward to the day I can move back to main. My next steps are to redo all my remaps then I should be able to complete my current build.

Silent

OK, so bear in mind that I successfully managed to pair everything as is, so it's not a complaint per se. I'm just trying to assess the user friendliness of this process to avoid less savvy people go all like "wtf this is garbage, ps3controller was so easy to set up in comparison!!".

I pulled all the latest changes (rebased sixaxis on top of latest master so my Setup script is essentially up to date), I updated sixaxis from source and I cleared all BT pairings and rebooted the Pi, to ensure a clean state for a new test.

After the reboot, I went straight to Bluetooth (without plugging in the pad earlier) and started to pair. DualShock 3 text didn't show up (as expected) and pairing didn't take an eternity - good. However, after unplugging the pad again I was unable to use it anyway, it didn't connect to the Pi. What I had to do is reboot and try again - then it worked.

For second pad, same steps applied - just with DualShock 3 text now showing up. After trying to pair two times, it worked flawlessly.

Any idea why I had to repeat the process twice? In both cases Bluetooth menu detected the pads proprly and they worked fine when wired, but wouldn't want to connect when replugged.

EDIT:
On a positive note, I feel like this driver really has somewhat lower input lag. When playing GB/SNES games I felt like I got rusty at those over the years, but now I think it may be better. Great!

I'll also doublecheck with PSX titles later, as I identified that vibration would cause PCSX to slow down to a crawl, so I disabled it. I thought it's the emulator's fault but now with newer drivers I'm inclined to give it a go again.

EDIT2:
I played quite a bit of ToCA 2 with vibrations (and controller vibrates pretty much most of the time there) and noticed no slowdowns - so that might have been sixad again :D

psyke83

@Silent

Your controller disconnect issue was caused by moonlight issuing an ioctl to grab exclusive access to the device, which blocks input events being received by anything else (including my sixaxis-timeout program). Other applications can potentially have the same problem (such as Kodi 18) so I added a check to my program so that it doesn't erroneously disconnect the controller in such situations.

It'll be fixed once this PR is merged: https://github.com/RetroPie/sixaxis/pull/2

hhromic

@psyke83 said in Sony DualShock 3 - call for testers: "sixaxis" script module:

@Silent

Your controller disconnect issue was caused by moonlight issuing an ioctl to grab exclusive access to the device, which blocks input events being received by anything else (including my sixaxis-timeout program). Other applications can potentially have the same problem (such as Kodi 18) so I added a check to my program so that it doesn't erroneously disconnect the controller in such situations.

It'll be fixed once this PR is merged: https://github.com/RetroPie/sixaxis/pull/2

Interesting. This means that such applications are incompatible with the timeout helper then? I will investigate Moonlight and see if we can lift this requirement for grabbing the device exclusively. It seems to be in place for capturing CTRL+C for keyboards, but def there are better ways to do this than grabbing the device.

Thanks for the discovery.

psyke83

@hhromic said in Sony DualShock 3 - call for testers: "sixaxis" script module:

@psyke83 said in Sony DualShock 3 - call for testers: "sixaxis" script module:

@Silent

Your controller disconnect issue was caused by moonlight issuing an ioctl to grab exclusive access to the device, which blocks input events being received by anything else (including my sixaxis-timeout program). Other applications can potentially have the same problem (such as Kodi 18) so I added a check to my program so that it doesn't erroneously disconnect the controller in such situations.

It'll be fixed once this PR is merged: https://github.com/RetroPie/sixaxis/pull/2

Interesting. This means that such applications are incompatible with the timeout helper then? I will investigate Moonlight and see if we can lift this requirement for grabbing the device exclusively. It seems to be in place for capturing CTRL+C for keyboards, but def there are better ways to do this than grabbing the device.

Thanks for the discovery.

Yes -- but to be clear, I'm talking about "moonlight-embedded" provided via the limelight scriptmodule. I have no first-hand experience with the software due to not owning a NVIDIA card, but you can see the ioctl being called here :https://github.com/irtimmer/moonlight-embedded/search?q=EVIOCGRAB&unscoped_q=EVIOCGRAB

Presumably other software could exhibit this issue. Kodi 18 is causing problems too, but it's partly due to the OS erroneously flagging the controller as a keyboard type device. I'm investigating, but for the moment I've got a bug filed here: https://github.com/xbmc/xbmc/issues/15588

hhromic

@psyke83 thanks for your reply.

@psyke83 said in Sony DualShock 3 - call for testers: "sixaxis" script module:

Yes -- but to be clear, I'm talking about "moonlight-embedded" provided via the limelight scriptmodule.

Yes I know you were refering to Moonlight Embedded. However I'm not sure how the ancient limelightprovides it? That scriptmodule uses an outdated Java version that used to be on irtimmer's repo. The current version is C-based.

@psyke83 said in Sony DualShock 3 - call for testers: "sixaxis" script module:

I have no first-hand experience with the software due to not owning a NVIDIA card, but you can see the ioctl being called here :https://github.com/irtimmer/moonlight-embedded/search?q=EVIOCGRAB&unscoped_q=EVIOCGRAB

I do have experience as I am developing a replacement scriptmodule for modern moolight-embedded here. I do have an NVIDIA card and test all these things. I also found these ioctl calls in the current repository.

@psyke83 said in Sony DualShock 3 - call for testers: "sixaxis" script module:

but it's partly due to the OS erroneously flagging the controller as a keyboard type device

That's a very good observation. I was thinking the same indeed, i.e. maybe only keyboard-type devices should be grabbed (for full key access) and not gamepads. I can PR this for moonlight. Do you think it's a reasonable solution?

psyke83

@hhromic said in Sony DualShock 3 - call for testers: "sixaxis" script module:

@psyke83 thanks for your reply.

@psyke83 said in Sony DualShock 3 - call for testers: "sixaxis" script module:

Yes -- but to be clear, I'm talking about "moonlight-embedded" provided via the limelight scriptmodule.

Yes I know you were refering to Moonlight Embedded. However I'm not sure how the ancient limelightprovides it? That scriptmodule uses an outdated Java version that used to be on irtimmer's repo. The current version is C-based.

Whoops. I was assuming that scriptmodule was based on moonlight-embedded based purely on the GPL3 license for the module linking to that repo. So it's your WIP scriptmodule, yes.

@psyke83 said in Sony DualShock 3 - call for testers: "sixaxis" script module:

I have no first-hand experience with the software due to not owning a NVIDIA card, but you can see the ioctl being called here :https://github.com/irtimmer/moonlight-embedded/search?q=EVIOCGRAB&unscoped_q=EVIOCGRAB

I do have experience as I am developing a replacement scriptmodule for modern moolight-embedded here. I do have an NVIDIA card and test all these things. I also found these ioctl calls in the current repository.

@psyke83 said in Sony DualShock 3 - call for testers: "sixaxis" script module:

but it's partly due to the OS erroneously flagging the controller as a keyboard type device

That's a very good observation. I was thinking the same indeed, i.e. maybe only keyboard-type devices should be grabbed (for full key access) and not gamepads. I can PR this for moonlight. Do you think it's a reasonable solution?

To be clear, the the controller timeout will still work before and after moonlight exits, and it's likely that you'd want your controller to stay connected during streaming, so it's not a major issue.

Regardless, it might be a good idea for moonlight-embedded to grab only keyboard-type devices. The solution might be as simple as to set grabbingDevices to false here (perhaps with a change so that mice also aren't grabbed unnecessarily). Feel free to test and send a PR if you feel it's helpful. A handy way to monitor for a grabbed device is to monitor the controller via evtest concurrently to whatever software you want to test; it will complain about the device being grabbed if the ioctl has been issued to the device.

On a related topic, the issue with Kodi 18 has been figured out. Since we can't be sure if systemd will see a version bump in Raspbian stretch, I added a workaround for the issue to the udev rules of my sixaxis package.

hhromic

@psyke83 said in Sony DualShock 3 - call for testers: "sixaxis" script module:

To be clear, the the controller timeout will still work before and after moonlight exits, and it's likely that you'd want your controller to stay connected during streaming, so it's not a major issue.

Current Moonlight is able to hotplug controllers (thru udev/evdev) so it's not an issue to disconnect/re-connect controllers. I think it's fundamental to prioritise controller battery management and I do consider a bug that it grabs any input device blindly.

Regardless, it might be a good idea for moonlight-embedded to grab only keyboard-type devices. The solution might be as simple as to set grabbingDevices to false here (perhaps with a change so that mice also aren't grabbed unnecessarily). Feel free to test and send a PR if you feel it's helpful. A handy way to monitor for a grabbed device is to monitor the controller via evtest concurrently to whatever software you want to test; it will complain about the device being grabbed if the ioctl has been issued to the device.

Yes I also figured out that indeed is a very simple fix in the current code. As you point out, there is already an is_keyboard bool that can be used to condition grabbing only for actual keyboards. However there is another place that needs this conditioning too, i.e. evdev_start().

I'm already working on a PR to enhance this in Moonlight as I believe it is beneficial in general. I've submitted other PRs before and the author is keen on accepting these enhancements. Thanks for the pointer for testing, very handy indeed.

On a related topic, the issue with Kodi 18 has been figured out. Since we can't be sure if systemd will see a version bump in Raspbian stretch, I added a workaround for the issue to the udev rules of my sixaxis package.

Looks good! In the case of Moonlight, the keyboard detection is done using evdev capabilities so wil work no matter what udev flags :)

Again, thanks for bringing the issue to light, is always welcome to enhance software properly.

hhromic

@psyke83 I submitted a PR upstream now. Hopefully addresses this issue and makes Moonlight compatible with the upcoming sixaxis timeout helper.

I myself use it and is very useful. Thanks for all your work on that btw.

hhromic

@psyke83 @Silent my PR was accepted upstream now (that was fast). So it should work fine alongside the sixaxis timeout helper ;)

psyke83

I've made some important changes to increase the reliability of pairing, added some configuration menu options so that it's easier to enable support for third-party controllers and added support for a user-configurable timeout.

The timeout can be edited from the scriptmodule configuration menu, but if you prefer, you can just edit the /opt/retropie/configs/all/sixaxis_timeout.cfg file directly (or over the samba share).

I'm still not happy with the reliability of first-time pairing of controllers, so that's the last issue that needs to be fixed before merging, I think.

@hhromic said in Sony DualShock 3 - call for testers: "sixaxis" script module:

@psyke83 @Silent my PR was accepted upstream now (that was fast). So it should work fine alongside the sixaxis timeout helper ;)

Great to hear! Thanks for helping to improve things for everyone.

Silent

@psyke83 Sounds good! I take it there is no need to re-pair again to make use of those? I may still want to do that to gauge whether it's more user friendly now, though.

psyke83

@Silent said in Sony DualShock 3 - call for testers: "sixaxis" script module:

@psyke83 Sounds good! I take it there is no need to re-pair again to make use of those? I may still want to do that to gauge whether it's more user friendly now, though.

The changes were related to improving the pairing experience, so it would make sense to go out of your way and remove / pair the device again to help test the changes.

Some further fixes have been merged into master and the PR has been updated again. I'm fairly comfortable to now recommend this to be merged, but some feedback would be appreciated.

edge3000

@psyke83 I just updated to your latest sixaxis PR to do some pairing tests!

Pairing tests:

wired (player 1 LED on): Register, Searching.., unplug, PSbutton, wait for player 1 LED, plug in, choose bluetooth device "PLAYSTATION(R)3" = SUCCESS
unplug, controller turns off, PSbutton, player 1 LED then controller shuts off again, PSbutton, player 1 LED stays on.
Device now shows as Sony PLAYSTATION(R)3 and is paired OK

wired (4 LEDs flashing): all actions same as previous = SUCCESS

controller off (no LEDS): Register, Searching.., PLUG IN, PSbutton, wait for player 1 LED, then repeat the normal steps = SUCCESS

controller off (no LEDS): Register, Searching.., PLUG IN, then repeat the normal steps = SUCCESS

My Observations:

The new popup Searching.. message is much more clear and now only takes a few seconds to finish. It assumes that the wire is already connected before you start.

When you first connect the controller it is considered wired and is named PLAYSTATION(R)3. After you first pair it and get the SUCCESS message - you disconnect the wire and press PS button, then the controller immediately shuts off and changes its name to Sony PLAYSTATION(R)3 and will now work wirelessly next time you turn it on.

If I have a controller connected wirelessly as player 1 and try to pair a 2nd controller, it will turn off the first controller at the moment where I plug the cable back in to controller 2. At this point I get a Unable to Authenticate message for controller 2. When I unplug controller 2 it stays on wirelessly, with old style wired button mappings (down on the dpad becomes A or B). If I turn it off and back on it does not reconnect wirelessly. All the while controller 2 stays registered as "PLAYSTATION(R)3".

I removed the device from the list and tried pairing again and it worked. Basically the only way to pair multiple controllers in a row is to go through the entire process up to the point it stays on wirelessly, then hold PS button to shut it off before even starting to pair another controller.

psyke83

The PR has finally been merged. For those of you that were testing, it's sufficient to return to the latest master branch and re-install the sixaxis scriptmodule to avail of the latest changes. Thank you all for the assistance -- and of course, if new issues arise, report them here.

@edge3000

Your feedback was very helpful; the issue you experienced when pairing multiple controllers is now fixed. Of note, you seemed to be inferring an extra step in the on-screen instructions (i.e. waiting for the LED player slot to be assigned after pressing the PS button). Doing that will definitely lead you to trouble in the current version of the Bluetooth script; simply replug the cable immediately after pressing the PS button.

You will still see the paired controller (and any other connected Bluetooth devices) turn itself off after first pairing; this is happening because it's necessary to stop and restart the Bluetooth stack when renaming the profile. This is a transient hack that will not be needed in future distro versions (or even today, if you have the newer BlueZ version installed via custombluez).

edge3000

@psyke83 Awesome news, thanks for all your work on this!

Yeah I wasn't sure if waiting for the LED player slot light was necessary so I just tried as many variations as I could and tried to break things.

I'm happy to go back to master, now I will start the fun of remapping all my buttons that I've been putting off for so long lol

After that my next step is trying out the new Kodi, Steam Link and Moonlight streaming.

edge3000

@psyke83 I went back to master, updated the RetroPie-Setup script to 4.4.8, installed sixaxis. Removed my old pairings from Bluetooth setup. Paired 7 dualshock 3 controllers - all worked fine and the pairing process was better again thanks to your changes.

However there is 1 minor issue I am having - the first time I boot up and turn on a controller - it lights up player1 LED on the controller then immediately turns off the LED - but the controller is still on and working as player1! Further controllers paired get their proper LEDs of player2, player3 etc

As a test I installed custombluez and rebooted, and now the LEDs work fine again! Not sure what is different in custombluez that would fix it other than the newer bluez version? All my tests are on official controllers so I didn't think I would need it.