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

Silent

OK, I'm giving this another go on my existing RetroPie installation (Stretch based) - removed ps3controller driver, rebooted and proceeded to installing sixaxis.

Why is custombluez installed automatically with sixaxis, when the instructions say to grab it only if you have third party PS3 controllers?

I'll edit this post with progress as I go by.

EDIT:
So I retraced my steps and results are identical, sadly. EmulationStation works perfectly with the controller (presenting itself as Sony PLAYSTATION(R)3 Controller), reconfigured buttons anyway to be sure and to re-create a RetroArch configuration for it (which it did, \\RETROPIE\configs\all\retroarch-joypads contains Sony PLAYSTATION(R)3 Controller.cfg). Despite all that, libretro joypad assignment (in Configuration Editor in ES) sees the pad as "not connected" and games do not react to it.

Even weirder, starting lr emulators does show Sony PLAYSTATION(R)3 Controller configured on port #0! Bindings don't work at all, though.

Also tried removing and reinstalling retroarch from core packages, no success.

EDIT2:
Tried evtest - every button and axis (including analog triggers) work fine. Which makes sense, considering controller works perfect in EmulationStation.

psyke83

@Silent

Thanks for the information. I've identified the reason why the configuration editor doesn't show the controller as connected; this will be fixed by https://github.com/RetroPie/RetroPie-Setup/pull/2592.

The above problem should only be a cosmetic issue, and still doesn't explain why your controller isn't working in retroarch. Maybe you could zip and upload your retroarch configuration files for me to take a look?

P.S. The sixaxis PR is still in flux, but in the last revision I changed it so that the updated BlueZ stack + patched kernel driver is automatically installed, just so that people testing third-party controllers don't have to go through extra steps. The final version of the PR will only install the package that includes the udev rule and script to handle calibration and idle disconnection.

Silent

@psyke83 Thanks for looking into this, the latest changes sound good!

I have zipped retroarch.cfg, retroarch-core-options.cfg, and config + autoconfig directories from retroarch - is this enough?

https://www.dropbox.com/s/vb8ve63iimed5ax/retroarch-files.zip?dl=0

Do note these configs are from as-is state, without using your latest changes. For those I'll need to restore my SD card again before trying.

psyke83

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

@psyke83 Thanks for looking into this, the latest changes sound good!

I have zipped retroarch.cfg, retroarch-core-options.cfg, and config + autoconfig directories from retroarch - is this enough?

https://www.dropbox.com/s/vb8ve63iimed5ax/retroarch-files.zip?dl=0

Do note these configs are from as-is state, without using your latest changes. For those I'll need to restore my SD card again before trying.

That was enough - thanks.

It looks like your retroarch.cfg configuration has been improperly edited; look at the first line:

all_users_control_menuall_users_control_menu = "true"

This should be:

all_users_control_menu = "true"

I haven't had time to check everything else, but the above is not the reason for controls not working. It seems that this line is the culprit:

input_axis_threshold = "0.000000"

When I change this to 0.500000 (to match the value in my configuration before I replaced it with yours), my controller works with your configuration.

I'm also seeing retroarch complain about this line:

input_libretro_device_p1 = "5"

This was set to 1 in my configuration, but perhaps this is related to another input device you're using that you didn't mention.

Silent

@psyke83 Amazing, all_users_control_menu and input_axis_threshold indeed helped! (tested them in one batch so I'm unsure if I had to use both or just one). Kinda makes you think why did it work fine with sixad, but I don't think it's something to worry about =)

With that change it seems to work perfectly! However, when doing Moonlight streaming (no reconfiguration was needed! triggers are still analog. Since evtest can report their analog values properly, would it mean that it's just a matter of providing and updated SDL controllerdb entry?

Thanks a lot for your help! I think I will keep using this driver for a while, then just back up my saves, restore SD card from the backup and get a new one when it's updated/finalized. Alternately, I can just keep updating it here since now I know it works :D

edge3000

@psyke83

Does the sixaxis PR have any effect on button mappings or button detection? I know there were big changes recently to the numbers buttons had assigned to them, I'm just not sure if the PR matches the current standard?

(I am on my new Stretch build / rpi3b+ / all updates installed, then Sixaxis PR applied)

The issue I am having is with Advmame 3.9, and dualshock 3 buttons.
In advmame.rc I have it set to "device_joystick event" and Advmame only sees buttons 0 to 10. It won't detect L3, R3, or the d-pad buttons. (which are 11-16) Same thing with it set to auto or raw. d-pad buttons worked fine on my old Jessie/rpi3b/advmame 3.5 build I think because the buttons were assigned lower numbers back then. (I may have been missing all the L and R buttons instead - which for the games I play didn't effect me)

If I set "device_joystick sdl" all the buttons are detected, I thought this was my solution but now I notice a huge 1 minute+ loading time before a game starts, and at least a 5 second freeze every time I exit a game! With it set to event, auto or raw it loads and exits almost instantly.

If I test the controller with jstest all buttons 0 to 16 operate correctly.

Anyway I just wanted to verify if it's related to the PR or just an Advmame issue!
Thanks

psyke83

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

@psyke83

Does the sixaxis PR have any effect on button mappings or button detection? I know there were big changes recently to the numbers buttons had assigned to them, I'm just not sure if the PR matches the current standard?

Yes, the PR will use different mappings to ps3controller. Some emulators may hard-code the older mappings, so I'll take a look at advmame when I get some time.

Other applications such as Kodi will also have issues (I did submit an updated button map for Kodi, but the RPI builds of Kodi18 don't seem to recognize inputs at all for some reason).

PS. Most of the groundwork for this PR has already been merged, but the PR branch still has two important commits that introduce the actual sixaxis service, which has seen updates in the last day. You might want to return to master and then rebase against the latest PR branch to get all the updates.

edge3000

@psyke83 Sounds good, thanks again for your work on this!
I will go back to master and reapply the PR.

I already did my remaps for lr-fbalpha with the PR installed, will they stay the same in the future?
I didn't start my lr-mame2003 remaps yet because that's where I have the most games.

Is there a limit to the number of bluetooth controllers connected at once? I have 10 dualshock 3's available to test it out.

I'm worried that the Motion Sensors being detected might cause lag?
If I run "cat /proc/bus/input/devices" I see Motion Sensors for each dualshock 3.
I remember reading about the udev rule for that, just not sure if that should make them completely hidden?

psyke83

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

@psyke83 Sounds good, thanks again for your work on this!
I will go back to master and reapply the PR.

I already did my remaps for lr-fbalpha with the PR installed, will they stay the same in the future?
I didn't start my lr-mame2003 remaps yet because that's where I have the most games.

Is there a limit to the number of bluetooth controllers connected at once? I have 10 dualshock 3's available to test it out.

I'm worried that the Motion Sensors being detected might cause lag?
If I run "cat /proc/bus/input/devices" I see Motion Sensors for each dualshock 3.
I remember reading about the udev rule for that, just not sure if that should make them completely hidden?

The latest changes will make a change that may impact your mappings.

The older version of BlueZ on Raspbian stretch (5.43) creates a Bluetooth profile named PLAYSTATION(R) 3 Controller. This is a minor annoyance, as the USB connection uses the name Sony PLAYSTATION(R) 3 Controller, so you're forced to create separate mappings for the controller depending on whether you connected via USB or BT.

This is fixed by newer BlueZ versions (which you can get on RetroPie now via the custombluez package)... but to avoid the need to upgrade, I added a hack to the sixaxis service so that it will rename existing profiles to the proper name: https://github.com/RetroPie/sixaxis/commit/5538972e5b0c21f7a3ba4f94be4911f50d64af4a

In a nutshell, with the latest PR installed, your controller will start using the Sony mapping via BT instead of the version without the manufacturer prefix. If you didn't map correctly/fully when you originally plugged via USB, you may want to verify the mappings again.

I feel annoyed by the need to apply hacks like this, but the only alternative is to wait for the next Raspbian distribution version that has a more up-to-date version of BlueZ and the hid-sony driver.

I think someone already mentioned that they successfully tested 5 or 6 controllers - so please do let me know if your 10 work simultaneously! ;)

edge3000

@psyke83 Yup that was me with the dualshock3's!

I'm trying out your latest updates to the PR now,
I just tested controllers and 7 is the limit, which is the same as an actual PS3. Sounds like that is just the bluetooth limit in general :(
I really only need 6 for xmen arcade 6player, but I had dreams of 10 player Saturn Bomberman over Steam Link lol
As far as I know Steam Link has its own limit of 4 controllers anyway.

I tried connecting more dualshock3's in wired mode but it won't go past the 7 limit - may still technically count as bluetooth?
I would think the same thing would happen with PS4 controllers as well.

Do you have a recommended method to turn off the controller timeouts? I just edited one of the files last time.

Silent

Very neat updates! I think at this point I can safely restore my SD card to pre-sixaxis state and try again from a clean state, without grabbing custombluez and customhidsony.

Again - is it going to be possible to create a gamecontrollerdb entry with pressure sensitive triggers? It'd benefit Steam Link and Moonlight streaming greatly.

psyke83

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

Very neat updates! I think at this point I can safely restore my SD card to pre-sixaxis state and try again from a clean state, without grabbing custombluez and customhidsony.

Again - is it going to be possible to create a gamecontrollerdb entry with pressure sensitive triggers? It'd benefit Steam Link and Moonlight streaming greatly.

Have you tried it yourself?

I compiled controllertest from: https://github.com/RetroPie/SDL-mirror

For my official pad, the initial information presented is:

INFO: There are 1 joysticks attached
INFO: Joystick 0: Sony PLAYSTATION(R)3 Controller
INFO:        axes: 6
INFO:       balls: 0
INFO:        hats: 0
INFO:     buttons: 17
INFO: instance id: 0
INFO:        guid: 050000004c0500006802000000810000
INFO:     VID/PID: 0x054c/0x0268
INFO: Watching joystick 0: (Sony PLAYSTATION(R)3 Controller)
INFO: Joystick has 6 axes, 0 hats, 0 balls, and 17 buttons
INFO:

I proceeded to configure the controller according to the onscreen prompts. This is the result:

INFO: Mapping:

050000004c0500006802000000810000,Sony PLAYSTATION(R)3 Controller,platform:Linux,a:b0,b:b1,x:b3,y:b2,back:b8,guide:b10,start:b9,leftstick:b11,rightstick:b12,leftshoulder:b4,rightshoulder:b5,dpup:b13,dpdown:b14,dpleft:b15,dpright:b16,leftx:a0,lefty:a1,rightx:a3,righty:a4,lefttrigger:a2,righttrigger:a5,

For comparison, here's the GUID that's already compiled into our version of SDL2:

$ git grep 050000004c0500006802000000810000
src/joystick/SDL_gamecontrollerdb.h:    "050000004c0500006802000000810000,PS3 Controller,a:b0,b:b1,back:b8,dpdown:b14,dpleft:b15,dpright:b16,dpup:b13,guide:b10,leftshoulder:b4,leftstick:b11,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b12,righttrigger:a5,rightx:a3,righty:a4,start:b9,x:b3,y:b2,",

It seems that both mappings already define the trigger buttons according to axes (lefttrigger:a2 andrighttrigger:a5) instead of the digital buttons. So if I understand this correctly, the mapping should already be correct?

psyke83

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

@psyke83 Yup that was me with the dualshock3's!

I'm trying out your latest updates to the PR now,
I just tested controllers and 7 is the limit, which is the same as an actual PS3. Sounds like that is just the bluetooth limit in general :(
I really only need 6 for xmen arcade 6player, but I had dreams of 10 player Saturn Bomberman over Steam Link lol
As far as I know Steam Link has its own limit of 4 controllers anyway.

I tried connecting more dualshock3's in wired mode but it won't go past the 7 limit - may still technically count as bluetooth?
I would think the same thing would happen with PS4 controllers as well.

Do you have a recommended method to turn off the controller timeouts? I just edited one of the files last time.

The Bluetooth spec seems to impose that limit, yes... though I'm not sure why that would impact USB-connected devices.

As for the timeout, maybe just edit the script for now... sorry. I overlooked the issue that systemd doesn't import environment variables from traditional locations by default (such as /etc/environment). Perhaps in future I'll change the script to source the timeout value from a user-editable file, but it's a low priority :)

I'm curious why you turn off the timeouts? My controllers tend to drain battery quite quickly when I leave them paired. I suppose it depends on whether you tend to leave your Pi on for long periods or not...

edge3000

@psyke83

If I'm playing 4 or 5 player games with friends, it can be a pain if the controllers turn off after a short period of time. One issue we used to have with ps3controller driver was if say 3 out of 4 players were playing a game - and 1 player was just sitting out. Their controller would turn off, and if they turned it back on the player numbers would get reordered on the Pi, but the lights on the controllers wouldn't match the actual player number. With that driver you also had to be very slow when reconnecting controllers, and only do it one at a time or it would get messed up.

If we stop playing for a long time I just shut down the Pi and they all turn off at once.

psyke83

@Silent

Take a look at the discussion regarding trigger axes here: https://github.com/libretro/RetroArch/issues/6920

The hid-sony driver has an unusual axis configuration for triggers, where the resting value is -32767, intermediate press is 0 and full press is 32767. So essentially the trigger spans the negative to positive of the axis, whereas most software expects a trigger to rest at zero and span along one pole only.

Explicitly setting the axes to the positive pole in your gamecontrollerdb.txt may partially work around this problem (i.e. allowing pressure sensitivity between intermediate and full pressure), but I haven't tested. It seems that libretro has a hack in place to solve this (see this discussion above), and we've also applied a similar patch to EmulationStation's master branch so that controller mapping doesn't report both axes.

Not sure what's the best course of action here. Perhaps we could try patching the driver rather than relying on individual hacks.

Silent

@psyke83 FYI I have only verified it with pre-changes sixaxis driver, that is with custombluez and customhidsony. While this is not (and will never be, I think) an issue in libretro emulators, in Moonlight Game Streaming it's really obvious - any racing game displaying inputs indeed shows that throttle is either 0 or 100.

I'll try messing with gamecontrollerdb.txt there, just need to figure out where it is in the first place.

edge3000

@Silent How do you find Moonlight other than this control issue? I use the physical Steam Link at the moment but some games like Pinball FX3 have too much input lag to play through it. I actually finished Dragon Quest 11 through it (wired) and it ran well except every once in awhile you might get a freeze of a couple seconds and then it returns to normal.

I heard Moonlight might be better so I plan to give it a try. I have a GTX-1060 6GB

Silent

@edge3000 Do try! For the most part it's really great, possibly better than Steam Link. Plus, thanks to this not-yet merged scriptmodule it integrates with EmulationStation as an "emulator":

https://retropie.org.uk/forum/topic/19872/moonlight-request-for-comments-and-testing/

psyke83

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

@psyke83 FYI I have only verified it with pre-changes sixaxis driver, that is with custombluez and customhidsony. While this is not (and will never be, I think) an issue in libretro emulators, in Moonlight Game Streaming it's really obvious - any racing game displaying inputs indeed shows that throttle is either 0 or 100.

I'll try messing with gamecontrollerdb.txt there, just need to figure out where it is in the first place.

Unfortunately I don't own a NVIDIA GPU, but I may have some racing games in my Steam library. Can you confirm that the same issues happens with triggers in the steamlink app? I'm also not certain which racing games I own would definitely show this (as I've never really played any in my backlog).

Silent

@psyke83 So I tested both Moonlight and Steam Link:

Moonlight: Triggers register as 100% press upon the slightest press.
Steam Link: Behaviour was same, but in Steam Link app I ran Setup Controller again and reconfigured the controller. After that, it works as expected!

Do you know where Moonlight and Steam Link keep their mappings? I want to try to sync them to see if I can get triggers to work in Moonlight too.

For both my test case was DiRT Rally - a XInput game, in which you can see % press of an axis in Controls screen, so it's a reliable method of checking.