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

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.

psyke83

@Silent

Hmm.... or maybe I'm mistaken and it is possible.
Looking at one of my controllers:

$ cat /sys/class/leds/0005:054C:0268.0007::sony1/trigger
[none] rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock timer oneshot heartbeat backlight gpio cpu cpu0 cpu1 cpu2 cpu3 default-on input panic mmc0 rfkill-any rfkill0 sony_controller_battery_e0:ae:5e:61:3e:c8-charging-or-full sony_controller_battery_e0:ae:5e:61:3e:c8-charging sony_controller_battery_e0:ae:5e:61:3e:c8-full sony_controller_battery_e0:ae:5e:61:3e:c8-charging-blink-full-solid

It looks like you can echo one of those option to the node and it might modify the behavior of the LEDs (it's set to none right now). I don't have a USB cable to test at the moment but perhaps you might want to experiment.

Silent

@psyke83 Sounds good! However, I'm not proficient enough to know what do you mean by "node" in this context - I can test it of course, but I may need specific instructions =)

EDIT:
I just realized half a second after submitting this reply... it's this very file in /leds/, right?

EDIT2:
I also assume this does not make any semi-permanent changes to the pad itself, does it?

EDIT3:
FYI my "Status" value for DS3's power supply says "Full", so there's at least three of them, not two.

psyke83

@Silent

It should be temporary...

Try this command:

sudo bash -c "echo mmc0 > /sys/class/leds/*::sony4/trigger"

This will configure your controller's fourth LED to blink on mmc0 (internal SD card) access - just like the Pi's actual dedicated disk activity LED.

Of course, this isn't what you want, but the other options (such as charging-blink-full-solid) theoretically might work.

psyke83

Good news and bad news...

The good: it's fairly easy to configure the LEDs to use the "blink on charge, solid on full". Here's the change that would do it: https://github.com/RetroPie/sixaxis/compare/master...psyke83:charge_blink

The bad: it doesn't seem to work as expected. My controllers still show a solid light even when the controller is in the Charging state. Perhaps it evaluates when to blink the leds based not on the charging state but battery level, and controller reports 100% capacity despite it not being fully charged, due to the limitation of the firmware? I don't know. I'll try discharging my controllers below 100% to see...

edge3000

@psyke83 I am running on Stretch and I believe everything was up to date (at least to the point before I started testing the PR). Only noticed this problem between your last version of the sixaxis PR and when I went back to master.

I had uninstalled sixaxis before going back to master, then updated retropie_setup script, then installed sixaxis. I did not have any controller related drivers installed at that time other than xpad when I installed sixaxis.

At that time I removed all paired controllers and paired them over again. They did their initial shutoffs where the the bluetooth restarts, but then on reboot I noticed pairing the first controller would not light the LED anymore.

Thats when I installed custombluez and the problem went away.