Sony DualShock 3 - call for testers: "sixaxis" script module
-
@psyke83 As far as I understand, name doesn't really matter here. I wiped retroarch-joypads when migrating drivers anyway, and I did have a .cfg generated there, the fact whether it had "Sony" prefix or not didn't really bother me.
I do wonder however why I did not have to remap the gamepad after migrating drivers. Perhaps I had some older mappings lingering, as right now (after revert, without
sixaxis
drivers) I myes_input.cfg
has mappings for bothPLAYSTATION(R)3 Controller
andSony PLAYSTATION(R)3 Controller
. I thought that was my PS3 pads presenting differently, as one of them is from Fat PS3 era, while the other was bundled with PS3 Super Slim and they are in fact a bit different - but that doesn't seem to be the case. -
Even if you never touched this PR, the
hid-sony
kernel driver is used on the USB connection, which is likely the reason why you already had a mapping (with theSony
prefix). This PR installs a patched version of this driver; if you're on jessie, the mappings will be different from the stock version, but they are identical to the default stretch version.If you're using jessie, keep in mind that we recently dropped support, so it would be a good idea to upgrade to a stretch-based image regardless of whether you intend to use this PR.
I can't say for sure why the buttons aren't being detected in emulators, but if you are on jessie, it's possible that you still have the old mappings. Manually deleting the
Sony
mappings and setting up again might fix your issue.You can try running
evtest
(from the package of the same name) to check if controller inputs are working correctly, to rule out driver issues. -
@psyke83 I am not on jessie, no - I run an up to date Stretch version. It's just that I used
ps3controller
until now.Good call about USB controllers however! That's most likely the reason.
I did remove mappings completely after initially complaining about that in this thread, reconfigured everything, ensured retroarch does indeed have a .cfg file for this joypad - still, no dice, and an inbuilt joypad selection in Configuration Menu showed controllers as "disconnected".
Since I was unable to go back to proper BT connection after uninstalling
sixaxis
and going back tops3controller
but restoring the SD image made pads work perfectly again even without having to connect them once (which means DS3's themselves were still correctly paired), I am going to give it another try soon. Maybe there is something which didn't work quite right the first time, or maybe I should have explicitly unpaired controllers fromps3controller
first. -
Hi, sorry for not fine-combing the thread before posting this. It's 04:20 at night and I can't sleep but need to try, so I thought I'd at least try to get this off my chest.
I have just installed RetroPie, I have an old PS3 controller which I got working. But I don't have a second controller. Tomorrow I thought about buying a new one, problem is PS3 controllers aren't for sale anymore where I live. Only PS4 controllers.
Does this new thing discussed in this thread make it possible to use both a PS3 controller and PS4 controller? What about a PS3 controller and Xbone controller?
Again, sorry for not fine-combing the thread but I need to try and get some sleep. Kind of asking this at the very last minute since I am getting a ride into town tomorrow from a friend to be able to buy a controller. Would suck if I get home and the PS3 controller doesn't work.
So if possible I would be really grateful if someone responded to me very soon before I buy a new expensive controller. >__<
-
@Silent Just to clarify I did start with the fresh Stretch image and did all the updates from RetroPie-Setup before applying the sixaxis PR.
So far I have tested 5 dualshock 3's at once wirelessly and they are stable!
-
@edge3000 Right, that's not how I tried indeed - I attempted to set it up on my existing RetroPie installation. I don't really have a spare SD card to try and I don't think I want to replace its contents with a new installation for testing, then restore it from backup again. Was hoping I can try it in a live environment.
-
OK, I'm giving this another go on my existing RetroPie installation (Stretch based) - removed
ps3controller
driver, rebooted and proceeded to installingsixaxis
.Why is
custombluez
installed automatically withsixaxis
, 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 asSony 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
containsSony PLAYSTATION(R)3 Controller.cfg
). Despite all that, libretro joypad assignment (inConfiguration 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:
Triedevtest
- every button and axis (including analog triggers) work fine. Which makes sense, considering controller works perfect in EmulationStation. -
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.
-
@psyke83 Thanks for looking into this, the latest changes sound good!
I have zipped
retroarch.cfg
,retroarch-core-options.cfg
, andconfig
+autoconfig
directories fromretroarch
- 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.
-
@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
, andconfig
+autoconfig
directories fromretroarch
- 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. -
@psyke83 Amazing,
all_users_control_menu
andinput_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
-
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 -
@edge3000 said in Sony DualShock 3 - call for testers: "sixaxis" script module:
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.
-
@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? -
@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 nameSony 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/5538972e5b0c21f7a3ba4f94be4911f50d64af4aIn 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! ;)
-
@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.
-
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
andcustomhidsony
.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.
-
@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
andcustomhidsony
.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-mirrorFor 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? -
@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...
-
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.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.