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

[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.

[psyke83]

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

-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.

You're running on stretch, right? I encountered this issue when I was first testing the hid-sony driver, but I think the issue was isolated to the older BlueZ version in Raspbian jessie. Unfortunately, I can't seem to reproduce the issue on my installation now; I've tried several times to reboot the Pi, and the first pairing doesn't trigger the issue.

Did you install any software to manipulate LEDs for other devices? The hid-sony is different to ps3controller in that it exposes userspace-controllable LEDs to /sys/class/leds. If for any reason you have background processes manipulating these, it would affect the controller.

If the issue is simply that you're running jessie, I highly recommend that you upgrade to stretch. Aside from the LED issue, the timeout functionality won't work (jessie is missing the tool needed to configure the axis deadzones; without calibration, the OS will think that there's constant movement on the analog sticks).

[Silent]

Speaking of LEDs, I just noticed something while playing on Pi and when my controller discharged. I was able to resume my gameplay seamlessly by plugging the pad to Pi's USB port. However, seems that unlike on PS3, there is no visual indicator that the pad is charging/has finished charging.

Is making LEDs blink slowly while charging (iirc that's what happens on PS3) an option?

[psyke83]

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

Speaking of LEDs, I just noticed something while playing on Pi and when my controller discharged. I was able to resume my gameplay seamlessly by plugging the pad to Pi's USB port. However, seems that unlike on PS3, there is no visual indicator that the pad is charging/has finished charging.

Is making LEDs blink slowly while charging (iirc that's what happens on PS3) an option?

Short answer is no.

Long answer is... theoretically, you could do it.

When you connect a controller (either via USB or BT), userspace exposes some useful information:

• /sys/class/power_supply/sony_controller_battery_(your_mac_here)/ exposes the battery capacity (0-100%, but can only show a rough level rounded to the nearest 25% increment) and status (Charging or Discharging).
  */sys/class/leds/(bus address)::sony{1-4} allows you to check and manipulate each LED (on or off) individually.

If you really wanted, you could write a userspace tool to manage the LEDs; but I think you could only turn the LEDs on or off, so you'd need to have a process running that constantly manipulates the LEDs in order to emulate the charging pattern. It doesn't seem like it would be a practical solution IMO.