Sony DualShock 3 - call for testers: "sixaxis" script module
-
@psyke83
Could the answer be that my RPi is near my wifi router (maybe 30cm) ?
Nevertheless those unwanted stick inputs were not there a couple of weeks ago.
Maybe a new firmware/driver/config rendering the BT controller more sensitive ? -
@sano said in Sony DualShock 3 - call for testers: "sixaxis" script module:
@psyke83
Could the answer be that my RPi is near my wifi router (maybe 30cm) ?
Nevertheless those unwanted stick inputs were not there a couple of weeks ago.
Maybe a new firmware/driver/config rendering the BT controller more sensitive ?Could be, or perhaps some interference if you have your Pi inside a metal case. Are you on jessie or the stretch testing image? The latter may have different BT/wifi firmware that can affect how Bluetooth behaves.
-
@psyke83
My Pi is in a plastic case, and I use the stretch image for a few weeks.
Still trying to find bugs with my "regular" use of retropie, but no big deal ATM. -
I have seen those
hci0: Frame reassembly failed (-84)
errors in the past in my setup, before I even tried to play with these new drivers. I never got to the bottom of it, though since it didn't seem to have any material impact on the performance I just ignored them. -
@pjft
Just FYI those errors are logged in /var/log/kern.log*.
On my setup that was several MB of logs rewritten on a daily basis (I tested and had 500kB of logs for a few minutes of DS3 use), in addition to the random inputs.
Even with a F2FS formatted root partition, I don't like having error logs writing over and over a a several MB per day on a SD card for nothing :)
Gasp, my OCD is still kicking here... -
@pjft said in Sony DualShock 3 - call for testers: "sixaxis" script module:
I have seen those
hci0: Frame reassembly failed (-84)
errors in the past in my setup, before I even tried to play with these new drivers. I never got to the bottom of it, though since it didn't seem to have any material impact on the performance I just ignored them.Yeah, those messages aren't unique to the BlueZ sixaxis plugin - they definitely occurred with sixad (ps3controller) too. I don't recall seeing complaints about ghost analog movements, though.
It's hard to debug sixad because the virtual uinput device reports a lot of accelerometer events, and doesn't support setting axis fuzz (needed to skip reporting events when there's a small deviation).
-
@sano said in Sony DualShock 3 - call for testers: "sixaxis" script module:
@pjft
Just FYI those errors are logged in /var/log/kern.log*.
On my setup that was several MB of logs rewritten on a daily basis (I tested and had 500kB of logs for a few minutes of DS3 use), in addition to the random inputs.
Even with a F2FS formatted root partition, I don't like having error logs writing over and over a a several MB per day on a SD card for nothing :)
Gasp, my OCD is still kicking here...That seems quite excessive. I would see perhaps a dozen or so messages in one day at most, not several megabytes worth. I haven't seen any warnings at all since reducing the UART speed.
Perhaps it's due to overclocking your Pi?
-
@psyke83
No overclock :)
I have a personal motto to stay as vanilla as possible.
The only changes I make on my installs are :- disabling overscan
- disabling wifi
- migrate root partition to F2FS
Here is an example of log I had for a single second before reducing speed :
Feb 24 09:51:37 retropie kernel: [552204.012012] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.012040] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.012088] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.012184] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.012274] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.012353] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.114573] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.114577] Bluetooth: hci0 ACL packet for unknown connection handle 520 Feb 24 09:51:37 retropie kernel: [552204.114642] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.114728] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.114813] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.114900] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.114966] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.181939] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.181991] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.182071] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.182165] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.182252] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.182340] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.182426] Bluetooth: hci0: Frame reassembly failed (-84) Feb 24 09:51:37 retropie kernel: [552204.182480] Bluetooth: hci0: Frame reassembly failed (-84)
-
@sano said in Sony DualShock 3 - call for testers: "sixaxis" script module:
@psyke83
No overclock :)
I have a personal motto to stay as vanilla as possible.It's good that we have a mitigation for the issue; regardless, if your warranty isn't void, perhaps you could report the issue to the firmware issues tracker. No need to go into detail about RetroPie or this scriptmodule, as you can replicate the behaviour with stock bluez and the default hid_sony driver on the current stretch kernel.
I have a suspicion that your Pi's bluetooth module may be faulty, considering that we have the same revision of Pi. I've often seen them offer to replace boards when a HW fault is diagnosed (but of course, I'm only speculating about your board).
To be clear, the problem is not that the frame reassembly errors are appearing; our revision board doesn't support HW flow control, so those messages are (unfortunately) expected. The reason I suspect a HW fault is due to the magnitude to which the error is occurring for you along with the phantom feedback. Perhaps if you can test in a "quieter" environment and rule out interference etc., it might help. I'd like to see more people test this module so we can get a wider assessment as to whether this would be a common problem.
-
Hi all,
i have a Shanwan and a Gaisa controller, i would like to try sixaxis.
I installed sixaxis and automatically it will install customhidsony.
Becasue my controllers are not sony i try to install custombluez but it give me an error because a lot of package are missingdh-systemd git-buildpackage icu-devtools libcap-ng-dev libdbus-glib-1-dev libdw-dev libical-dev libicu-dev libreadline-dev libsubunit-dev libsubunit0 libtinfo-dev libical2
Tried to install all the packages manually with the command
sudo apt-get update sudo apt-get install dh-systemd git-buildpackage icu-devtools libcap-ng-dev libdbus-glib-1-dev libdw-dev libical-dev libicu-dev libreadline-dev libsubunit-dev libsubunit0 libtinfo-dev libical2
I was able to install all the packages except libical2
E: Unable to locate package libical2.
Someone can help me ?
I'm using Retropie 4.3.12 on a Raspberry Pi 3.Thank you
-
Thanks for bringing the problem to my attention. It seems that I accidentally left in some unnecessary depends that should fulfilled by the corresponding -dev packages;
libical-dev
should be sufficient, as it selectslibical2
on stretch, but on jessie it probably selects the old package.I've updated the PR/branch to remove the excess depends, so it should work for you now.
P.S. You have the option to install custombluez from binary, but it's also possible to build from source. If building from source fails, then I may need to add more explicit dependencies to the script for jessie. I only have Raspbian stretch installed on my test card at the moment, so let me know if installing from source is broken and I'll re-flash jessie to test.
In case you're not familiar with git, this should refresh the branch for you due to the branch update being forced, assuming you chose the remote name as
psyke83
:git fetch psyke83 git reset --hard psyke83/sixaxis
Thanks.
-
@psyke83
Thank you for replying me.
As asked i try to install custombluez from source but it fail with the following errormake[2]: *** [client/bluetoothctl] Error 1 Makefile:3183: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/home/pi/RetroPie-Setup/tmp/build/custombluez/build-area/bluez-5.48' dh_auto_build: make -j1 returned exit code 2 debian/rules:35: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1376: dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed gbp:error: 'debuild -i -I -us -uc' failed: it exited with 29 /home/pi/RetroPie-Setup/tmp/build/custombluez /home/pi/RetroPie-Setup /home/pi/RetroPie-Setup Could not successfully build custombluez - Updated version of BlueZ Bluetooth stack Install alongside 'sixaxis' driver if you need to pair third-party (Gasia/Shanwan) DualShock 3 controllers. (/home/pi/RetroPie-Setup/tmp/build/custombluez/build-area/bluetooth_5.48-1~rpi1_all.deb not found).
Installing from binary seems to install without problems.
Let me know if you need the full log if you need me to do some test.thank you
-
@psyke83
The Hori controller is in fact a PS3 and PS4 compatible controller (with a switch to choose PS3/4 compatibility, but this doesn't seem to affect the driver).
Will it use the Sony hid driver even if it's seen as a regular USB controller by the OS ?Anyway, please feel free to relocate the last few posts to your thread if you think it's more relevant.
-
@sano said in Sony DualShock 3 - call for testers: "sixaxis" script module:
@psyke83
The Hori controller is in fact a PS3 and PS4 compatible controller (with a switch to choose PS3/4 compatibility, but this doesn't seem to affect the driver).
Will it use the Sony hid driver even if it's seen as a regular USB controller by the OS ?Anyway, please feel free to relocate the last few posts to your thread if you think it's more relevant.
Yes, the sony-hid driver is used for both PS3 and PS4 controllers. However, I'm not very familiar with DS4 clone compatibility.
Without this scriptmodule, the
hid-sony
kernel driver is used for DS3 pads via USB, while theps3controller
userspace driver claims the input device on the Bluetooth connection, but names the controller differently (without the manufacturer prefix). You may have noticed that on a fresh install, if you map buttons via USB, then install ps3controller and pair, you have to map them again - that's because of the name discrepancy. When using this scriptmodule, the hid-sony driver is used on USB and Bluetooth connections, and thus shares the same name for both.What happens if you pair your DS3 pad, unplug the Hori and then plug in again? Does the Hori display a player led for you to tell if it's player 1/2/3/4?
-
@psyke83
I have to say that I configured the Hori on the fresh install, then installed sixaxis, and didn't have to reconfigure the HORI.
Unfortunately too, the Hori controller doesn't have LEDs for player number... -
@sano said in Sony DualShock 3 - call for testers: "sixaxis" script module:
@psyke83
I have to say that I configured the Hori on the fresh install, then installed sixaxis, and didn't have to reconfigure the HORI.
Unfortunately too, the Hori controller doesn't have LEDs for player number...Well, that's the expected behaviour since it's a USB-only pad, right? Only the
hid-sony
driver will be used, sinceps3controller
only intercepts BT connections. I was talking about actual DS3 controllers re: the name discrepancy. -
@meleu @psyke83
I unplugged the Hori stick and plugged a Dragonrise joystick.The behaviour of the jslist executable is the same :
First jslist call with only the USB controller, second just after the DS3 connected (without unplugging the USB controller)
pi@retropie:~ $ /opt/retropie/supplementary/joystick-selection/jslist 0:DragonRise Inc. Generic USB Joystick pi@retropie:~ $ /opt/retropie/supplementary/joystick-selection/jslist 0:Sony PLAYSTATION(R)3 Controller 1:DragonRise Inc. Generic USB Joystick
So apparently the fact that the HORI is a PS3 compatible device is not relevant.
Same symptoms :
Retroarch (and the OS) considers the USB plugged joystick as the first one, but jslist identifies the DS3 with the index 0.
The joystick selection tool updates retroarch config to use the index 0 (the wanted DS3), but index 0 for retroarch is the Dragonrise (or Hori previously).I don't know if I'm clear enough, here... It's 1 am, sorry :)
-
@sano said in Sony DualShock 3 - call for testers: "sixaxis" script module:
@meleu @psyke83
I unplugged the Hori stick and plugged a Dragonrise joystick.The behaviour of the jslist executable is the same :
pi@retropie:~ $ /opt/retropie/supplementary/joystick-selection/jslist 0:DragonRise Inc. Generic USB Joystick pi@retropie:~ $ /opt/retropie/supplementary/joystick-selection/jslist 0:Sony PLAYSTATION(R)3 Controller 1:DragonRise Inc. Generic USB Joystick
So apparently the fact that the HORI is a PS3 compatible device is not relevant.
Same symptoms :
Retroarch considers the USB plugged joystick as the first one, but jslist identifies the DS3 with the index 0.
The joystick selection tool updates retroarch config to use the index 0 (the wanted DS3), but index 0 for retroarch is the Dragonrise (or Hori previously).I don't know if I'm clear enough, here... It's 1 am, sorry :)
I've had a long day too, need to sleep :). I'll pick this up tomorrow and do some testing here, as to be quite frank, I've never used the controller selection functionality, so I'll need to delve into the scripts and see what's happening. The problem is that I've only got two DS3 controllers, so I'm not sure how I'll distinguish changes. The controller LED probably corresponds to the kernel js index; if a script or retroarch etc. changes the LED manually via a sysfs node, then perhaps the node location has changed in the updated driver. I vaguely recall that the new
hid-sony
driver dropped its LED-specific code to use the generic kernel LED support. -
If you want to reproduce this :
- first install @meleu joystick selection
- plug only an USB controller (preferably not a DS3 for test purpose)
- get the controller index seen by jslist :
/opt/retropie/supplementary/joystick-selection/jslist
- it should be 0 - power on a DS3 and call jslist again - you will have the DS3 with index 0 and the USB controller with the index 1. The LED on the DS3 is player 1 (should in fact be player 2 as it's the second connected controller)
- launch a console one player game - the player one controller is the USB one
-
Morning tests :
More logs, woohoo !
Hori detected at boot (as input0):[Sat Mar 10 09:35:27 2018] input: HORI CO.,LTD. Fighting Stick mini 4 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:0F0D:0088.0001/input/input0 [Sat Mar 10 09:35:27 2018] hid-generic 0003:0F0D:0088.0001: input,hidraw0: USB HID v1.11 Gamepad [HORI CO.,LTD. Fighting Stick mini 4] on usb-3f980000.usb-1.3/input0
DS3 connecting through BT (as input1) :
[Sat Mar 10 09:37:26 2018] input: Sony PLAYSTATION(R)3 Controller as /devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11/0005:054C:0268.0002/input/input1 [Sat Mar 10 09:37:26 2018] sony 0005:054C:0268.0002: input,hidraw1: BLUETOOTH HID v80.00 Joystick [Sony PLAYSTATION(R)3 Controller] on b8:27:eb:b3:70:3c
Still jslist returns apparently false index and DS3 player 1 LED is on :
pi@retropie:~/RetroPie-Setup $ /opt/retropie/supplementary/joystick-selection/jslist 0:Sony PLAYSTATION(R)3 Controller 1:HORI CO.,LTD. Fighting Stick mini 4
Out of curiosity, I also tried to plug the DS3 through USB, aaaaaannnd :
[Sat Mar 10 09:43:32 2018] usb 1-1.5: new full-speed USB device number 5 using dwc_otg [Sat Mar 10 09:43:33 2018] usb 1-1.5: New USB device found, idVendor=054c, idProduct=0268 [Sat Mar 10 09:43:33 2018] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [Sat Mar 10 09:43:33 2018] usb 1-1.5: Product: PLAYSTATION(R)3 Controller [Sat Mar 10 09:43:33 2018] usb 1-1.5: Manufacturer: Sony [Sat Mar 10 09:43:33 2018] input: Sony PLAYSTATION(R)3 Controller as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/0003:054C:0268.0003/input/input2 [Sat Mar 10 09:43:33 2018] sony 0003:054C:0268.0003: input,hiddev0,hidraw1: USB HID v81.11 Joystick [Sony PLAYSTATION(R)3 Controller] on usb-3f980000.usb-1.5/input0
The jslist output is ok, the USB connected DS3 has index 1, and Hori has index 0...
pi@retropie:~ $ /opt/retropie/supplementary/joystick-selection/jslist 0:HORI CO.,LTD. Fighting Stick mini 4 1:Sony PLAYSTATION(R)3 Controller
Moreover, adding another DS3 (using BT this time) :
[Sat Mar 10 09:46:10 2018] input: Sony PLAYSTATION(R)3 Controller as /devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:12/0005:054C:0268.0004/input/input3 [Sat Mar 10 09:46:10 2018] sony 0005:054C:0268.0004: input,hidraw2: BLUETOOTH HID v80.00 Joystick [Sony PLAYSTATION(R)3 Controller] on b8:27:eb:b3:70:3c pi@retropie:~ $ /opt/retropie/supplementary/joystick-selection/jslist 0:Sony PLAYSTATION(R)3 Controller 1:HORI CO.,LTD. Fighting Stick mini 4 2:Sony PLAYSTATION(R)3 Controller
Here the BT connected DS3 took index 0, Hori shifted to index 1 and USB connected DS3 to index 2...
So to resume this mess :
USB connected DS3 are listed correctly by jslist (index follows the connection order)
BT connected PS3 seem to have precedence : they always take the first controller indexes according to jslist, shifting all other controllers indexes upward.
The issue is that OS and retroarch doesn't act the same and apparently rely on connection order for controller indexes.My opinion is that SDL joystick index used in jslist is somewhat different from the OS (and apparently retroarch) used index.
It's like the BT connected DS3 always get the lowest index for SDL, instead of taking the next available as it should.Hope this could help.
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.