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

psyke83

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

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

Also, it looks like an identical mapping is already present in the database

The mapping in the database for your same GUID is not the same as the one you provided. from SteamLink. The differences are clearly stating the triggers being regarded as analog instead of buttons:
 guide:b10
 leftshoulder:b4
 leftstick:b11
-lefttrigger:b6
+lefttrigger:a2
 leftx:a0
 lefty:a1
 platform:Linux
 PS3 Controller
 rightshoulder:b5
 rightstick:b12
-righttrigger:b7
+righttrigger:a5
 rightx:a3
 righty:a4
 start:b9

That's right... and my post was intended to encourage others to check their own GUID. I've checked @Silent's, and the version of the db that's compiled into the current version of SDL2 built by RetroPie does use the digital buttons for this controller, unfortunately. In fact, at a quick glance, there are at least 16 PS3 variations that use the digital button mappings:

$ git grep "lefttrigger:b6" | grep "righttrigger:b7" | grep "PS3" -c
16

It might be a good idea to submit a patch to upstream SDL2 for your own GUID so that future releases work out of the box. I'm a bit hesitant to send a patch for all 16+ en masse, considering that I can't tell which GUIDs are clones that may possibly have malfunctioning analog triggers, etc.

Silent

@psyke83 Sure, I intend to do that, and also check with both my pads in case they have different GUIDs (which they may, considering both are legit but one is considerably newer than the other). I am not yet sure how to send patches to SDL yet though, so will need to look that up.

Also, this potentially important info seems to have gotten lost between the mappings talk:

However, when playtesting I encountered a problem - I was streaming via Moonlight and around 10 minute mark my controller disconnected! Was it a coincidence or a bug in idle timeout script? I was using triggers, left analog stick and face buttons - so the possibility of idle script only reacting to eg. face buttons is out of question.

steeeb

I've been trying to get this working on Odroid XU4 (ubuntu with 3.10 kernel).

But not having any luck with both official or Shanwan controllers. I upgraded bluez manually to 5.48 but that didn't help either.

Anyone know if it's ever likely to work on a kernel so old before I continue trying?

jmbooth2000

Would it be possible to dynamically change the configuration per game. For example you might want to configure pacman limited to 4 way movement or allow for analog triggers for acceleration and braking in racing games but digital in most.

This can, sort of, be done by using the xboxdrv and tearing down and restarting it on a per emulator / per game basis. This doesn't really scale.

What I'm thinking would be much better is if the driver could be load once but accept configuration changes.

Thoughts?

psyke83

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

Would it be possible to dynamically change the configuration per game. For example you might want to configure pacman limited to 4 way movement or allow for analog triggers for acceleration and braking in racing games but digital in most.

This can, sort of, be done by using the xboxdrv and tearing down and restarting it on a per emulator / per game basis. This doesn't really scale.

What I'm thinking would be much better is if the driver could be load once but accept configuration changes.

Thoughts?

You can specify a controller configuration via a hint in SDL2: https://wiki.libsdl.org/SDL_HINT_GAMECONTROLLERCONFIG

IIRC, hints can also be specified as an environment variable if you omit the _HINT part, so this could be a way to do it. I'm not sure if this can only append new entries or if it'll actually override an existing GUID entry.

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

@psyke83 Sure, I intend to do that, and also check with both my pads in case they have different GUIDs (which they may, considering both are legit but one is considerably newer than the other). I am not yet sure how to send patches to SDL yet though, so will need to look that up.

Also, this potentially important info seems to have gotten lost between the mappings talk:

However, when playtesting I encountered a problem - I was streaming via Moonlight and around 10 minute mark my controller disconnected! Was it a coincidence or a bug in idle timeout script? I was using triggers, left analog stick and face buttons - so the possibility of idle script only reacting to eg. face buttons is out of question.

I'll look into that soon.

jmbooth2000

@psyke83 That would be awesome!

Silent

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.

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 ;)