Sony DualShock 3 - call for testers: "sixaxis" script module
-
@psyke83
Using an OEM PS3 controller:
I tried it and it works fine, except I get the following displayed in the terminal when launching anything from ES:INFO: the key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list <https://discourse.libsdl.org/> EVDEV KeyCode 313
It displays a bunch of different key codes depending on which inputs on the controller I had pressed prior to launching the games.
Here is the list of keycodes for the PS3 controller which I grabbed from EVTEST:Event code 304 (BTN_SOUTH) Event code 305 (BTN_EAST) Event code 307 (BTN_NORTH) Event code 308 (BTN_WEST) Event code 310 (BTN_TL) Event code 311 (BTN_TR) Event code 312 (BTN_TL2) Event code 313 (BTN_TR2) Event code 314 (BTN_SELECT) Event code 315 (BTN_START) Event code 316 (BTN_MODE) Event code 317 (BTN_THUMBL) Event code 318 (BTN_THUMBR) Event code 544 (BTN_DPAD_UP) Event code 545 (BTN_DPAD_DOWN) Event code 546 (BTN_DPAD_LEFT) Event code 547 (BTN_DPAD_RIGHT)
I am not sure where I can find the log file of these messages (I checked dmesg and the /var/log/ folder but I couldn't find any logs that contain the messages)
I would be glad to find out if it affects all the buttons (i assume it does) but as I mentioned, I do not know the location of the logs for it.The controller is 100% functional in ES and in-game so I am not entirely sure why SDL is complaining.
I was even able to get a Bluetooth Xbox One controller paired and working along side it :) -
Thanks for testing. The messages you're receiving also happened with the older PS3 controller driver, but reverting this commit was supposed to solve it.
Can you report your current version of SDL2 that's installed?
dpkg -l | grep sdl2
The messages you're seeing in the terminal are probably emanating from EmulationStation itself. Perhaps you could try checking
~/.emulationstation/es_log.txt
and let me know? Or if they don't appear there, if you manually quit EmulationStation and then launch it from an SSH session, you can monitor output directly from the SSH session.The error isn't fatal, but it's strange... I can't seem to reproduce the problem.
-
@psyke83
SDL2 info:ii libsdl2-2.0-0:armhf 2.0.7+2rpi armhf Simple DirectMedia Layer hi libsdl2-dev:armhf 2.0.7+2rpi armhf Simple DirectMedia Layer development files ii libsdl2-image-2.0-0:armhf 2.0.0+dfsg-3+b1 armhf Image loading library for Simple DirectMedia Layer 2, libraries ii libsdl2-image-dev:armhf 2.0.0+dfsg-3+b1 armhf Image loading library for Simple DirectMedia Layer 2, development files ii libsdl2-mixer-2.0-0:armhf 2.0.0+dfsg1-5 armhf Mixer library for Simple DirectMedia Layer 2, libraries ii libsdl2-mixer-dev:armhf 2.0.0+dfsg1-5 armhf Mixer library for Simple DirectMedia Layer 2, development files ii libsdl2-ttf-2.0-0:armhf 2.0.12+dfsg1-2 armhf TrueType Font library for Simple DirectMedia Layer 2, libraries ii libsdl2-ttf-dev:armhf 2.0.12+dfsg1-2 armhf TrueType Font library for Simple DirectMedia Layer 2, development files
I was able to use the SSH method you mentioned above and I was able to verify that all of the controls produce the message (except events 304, 305, 307, & 308 but I wasn't able to find a way to activate them)
I guess I should have mentioned that I am using RetroPie 4.3.9 on a Pi3.
So I did some testing...
This issue does NOT occur when using the binary install from the retropie script.
This issue DOES appear when using the source install from the retropie script.I am using a stable (NOT MASTER) branch of ES I compiled myself (in which I just changed some fonts/icons).
How much older is the binary of ES compared to the stable branch source? It seems like the stable branch doesn't get updated very much from the last time I looked at it in github.I'm curious on what is causing this and how to resolve it.
-
I think that the difference here has nothing to do with changes in EmulationStation, and everything to do with the SDL2 library/headers installed on your system that are used to build the program. You'd see those errors when using an unpatched SDL2 library... but it seems that the version on your system (2.0.7+2rpi) is up to date.
I can't reproduce this by building EmulationStation from source, but I'm currently testing on stretch. I don't recall seeing this when I was testing on a standard jessie image, however. Perhaps try to rebuild/reinstall the SDL2 packages and then EmulationStation:
sudo ./retropie_packages.sh sdl2 sudo ./retropie_packages.sh emulationstation
-
@psyke83
So I did the commands you suggested above, and the issue was not resolved I then ran the following:sudo apt-get remove --purge libsdl2-dev sudo apt-get -f install && sudo apt-get autoremove && sudo apt-get -y autoclean && sudo apt-get -y clean
after running those I tried to reinstall SDL/ES again and the error messages still occurs.
Does it matter that I have this version of SDL still installed?:
hi libsdl1.2-dev 1.2.15-12rpi armhf Simple DirectMedia Layer development files ii libsdl1.2debian:armhf 1.2.15-12rpi armhf Simple DirectMedia Layer
I have been using and updating this image of RetroPie for a little over a year now (i'm not sure which version I started with). Perhaps that has something to do with this?
-
I tried doing the opposite; I rebuilt SDL with the patch that I mentioned earlier re-applied to the source, and couldn't reproduce the SDL log spam, even after rebuilding EmulationStation. I'm quite perplexed at the situation, as my controller produces the same keycode values as yours, but I've never seen these messages on jessie or stretch.
If you happen to have a spare SD card, perhaps you could try re-installing the latest image and testing the PR on a fresh installation? That's asking a lot, however, so don't feel obliged. The next release is going to be based on stretch, so perhaps it's better to wait a little while for that.
Apart from the spam, have you encountered any issues? It's been reported to me that ps3controller (sixad) causes dropped inputs when multiple controllers are used; I'm curious if the PR improves that situation or not.
Your version of SDL1 is also up-to-date, but as far as I can tell it doesn't have the same problem, and EmulationStation uses SDL2 exclusively.
-
I can try it on a fresh image of RP this weekend, when you mean multiple controllers do you mean multiple PS3 controllers? or a combination of different controllers?
Any idea when the next RP version based on Stretch is going to be released? Maybe I could just wait for it to come out and copy all my custom settings/files from my current image to a fresh image (although that would be a major task in and of itself, I have added an ungodly amount of customization to my image).
Also I might be able to compress my image and host it on Dropbox or something if you really want to take a look at it. -
@psyke83 Good news, I was able to compile ES from a fresh copy of RetroPie and then copy that executable over to my original image and the message no longer appears :)
-
@madmodder123 said in Sony DualShock 3 - call for testers: "sixaxis" script module:
@psyke83 Good news, I was able to compile ES from a fresh copy of RetroPie and then copy that executable over to my original image and the message no longer appears :)
Good news - so let's assume it's a quirk from your installation that won't impact most users. If you really want to figure out why it's happening, some thoughts below.
I posted the wrong link before; this is the commit that should have fixed your problem.
Perhaps you could try to do a grep of the libraries on your system:
grep -r "key you just pressed" /usr/lib
Mine results in a match in libSDL2, but it's only the message from the X11 video driver which doesn't get used on RetroPie (and yours was also the EVDEV one that the commit above would silence):
$ strings /usr/lib/arm-linux-gnueabihf/libSDL2-2.0.so.0.7.0 | grep "key you just pressed" The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list <https://discourse.libsdl.org/> X11 KeyCode %d (%d), X11 KeySym 0x%lX (%s).
Perhaps you could also try rebuilding EmulationStation and grepping the resulting binary for the string... although I don't see why that'd happen unless you modified the source to statically link SDL2 into the executable.
-
Thanks @psyke83 , this works great on my end as well with the original PS3 controllers and Shanwan as well.
Does anyone have gasia controllers they could test? Tagging @meleu @mediamogul @cyperghost in hopes one of them would have these? :)
-
@pjft No ...2 idroid:con paddels here ;)
-
Sorry, none here either.
-
@mediamogul @cyperghost thanks, sorry for tagging you. It was worth a shot? :)
-
@pjft said in Sony DualShock 3 - call for testers: "sixaxis" script module:
sorry for tagging you. It was worth a shot? :)
Not a problem. Never hurts to ask.
-
@pjft No problem bro
Always here for help :) -
@psyke83 I have been busy but I will do this when I have time!
-
Just for information, I tested this with the Etch image with official PS3 controllers.
Pairing works fine (wasn't working at all with the native image).I got a lot of unwanted button press, even in the controller configuration phase, which is pretty annoying.
Dmesg is full withBluetooth: hci0: Frame reassembly failed (-84)
andBluetooth: hci0 SCO packet for unknown connection handle 5125
errors, but I doubt this has to do with your script module (already had those errors with jessie and native bluetooth).
I'll have to find a bluetooth adapter to see if this helps, as I've seen around the web. -
Thanks for testing! Some questions, if you don't mind...
Did you install the PR more than 5 days ago? In the latest refresh of the PR, I patched the hid-sony kernel driver to make it use the original button mappings from the kernel 4.9 driver, but I also made a change that would cause errant button presses related to L2/R2.
The unmodified hid-sony driver's behaviour with the L2/R2 triggers is to emit both digital button and analog axis events, which gets interpreted as two separate presses in userspace. In the latest refresh of the PR that reverts to the old mappings, I also patched the driver to disable the analog trigger axes, leaving just the digital buttons presses.
If you're testing an older PR, I recommend that you update and see if the situation improves. If not, any further information you could provide (such as specific buttons causing problems) would be appreciated.
You can use a program such as
evtest
to monitor button presses on your controller. -
I installed it just today, so it's up to date I think.
I got a lot of random button press without touching anything :Exemple in 25s :
Testing ... (interrupt to exit) Event: time 1518638433.914937, type 3 (EV_ABS), code 0 (ABS_X), value 133 Event: time 1518638433.914937, type 3 (EV_ABS), code 1 (ABS_Y), value 0 Event: time 1518638433.914937, type 3 (EV_ABS), code 2 (ABS_Z), value 124 Event: time 1518638433.914937, type 3 (EV_ABS), code 5 (ABS_RZ), value 0 Event: time 1518638433.914937, -------------- SYN_REPORT ------------ Event: time 1518638433.921678, type 3 (EV_ABS), code 0 (ABS_X), value 126 Event: time 1518638433.921678, type 3 (EV_ABS), code 1 (ABS_Y), value 127 Event: time 1518638433.921678, type 3 (EV_ABS), code 2 (ABS_Z), value 133 Event: time 1518638433.921678, type 3 (EV_ABS), code 5 (ABS_RZ), value 125 Event: time 1518638433.921678, -------------- SYN_REPORT ------------ Event: time 1518638433.954201, type 3 (EV_ABS), code 5 (ABS_RZ), value 124 Event: time 1518638433.954201, -------------- SYN_REPORT ------------ Event: time 1518638450.121688, type 3 (EV_ABS), code 1 (ABS_Y), value 0 Event: time 1518638450.121688, -------------- SYN_REPORT ------------ Event: time 1518638450.155507, type 3 (EV_ABS), code 1 (ABS_Y), value 127 Event: time 1518638450.155507, -------------- SYN_REPORT ------------ Event: time 1518638450.793715, type 3 (EV_ABS), code 0 (ABS_X), value 125 Event: time 1518638450.793715, type 3 (EV_ABS), code 1 (ABS_Y), value 0 Event: time 1518638450.793715, type 3 (EV_ABS), code 2 (ABS_Z), value 0 Event: time 1518638450.793715, type 3 (EV_ABS), code 5 (ABS_RZ), value 0 Event: time 1518638450.793715, -------------- SYN_REPORT ------------ Event: time 1518638450.797955, type 3 (EV_ABS), code 1 (ABS_Y), value 128 Event: time 1518638450.797955, type 3 (EV_ABS), code 2 (ABS_Z), value 134 Event: time 1518638450.797955, type 3 (EV_ABS), code 5 (ABS_RZ), value 125 Event: time 1518638450.797955, -------------- SYN_REPORT ------------ Event: time 1518638450.830513, type 3 (EV_ABS), code 1 (ABS_Y), value 127 Event: time 1518638450.830513, -------------- SYN_REPORT ------------ Event: time 1518638450.997973, type 3 (EV_ABS), code 2 (ABS_Z), value 133 Event: time 1518638450.997973, type 3 (EV_ABS), code 5 (ABS_RZ), value 124 Event: time 1518638450.997973, -------------- SYN_REPORT ------------ Event: time 1518638451.873738, type 3 (EV_ABS), code 0 (ABS_X), value 124 Event: time 1518638451.873738, type 3 (EV_ABS), code 1 (ABS_Y), value 0 Event: time 1518638451.873738, type 3 (EV_ABS), code 2 (ABS_Z), value 0 Event: time 1518638451.873738, type 3 (EV_ABS), code 5 (ABS_RZ), value 0 Event: time 1518638451.873738, -------------- SYN_REPORT ------------ Event: time 1518638451.876727, type 3 (EV_ABS), code 1 (ABS_Y), value 127 Event: time 1518638451.876727, type 3 (EV_ABS), code 2 (ABS_Z), value 134 Event: time 1518638451.876727, type 3 (EV_ABS), code 5 (ABS_RZ), value 125 Event: time 1518638451.876727, -------------- SYN_REPORT ------------ Event: time 1518638451.909286, type 3 (EV_ABS), code 2 (ABS_Z), value 133 Event: time 1518638451.909286, -------------- SYN_REPORT ------------ Event: time 1518638451.953730, type 3 (EV_ABS), code 0 (ABS_X), value 134 Event: time 1518638451.953730, type 3 (EV_ABS), code 1 (ABS_Y), value 0 Event: time 1518638451.953730, type 3 (EV_ABS), code 2 (ABS_Z), value 125 Event: time 1518638451.953730, type 3 (EV_ABS), code 5 (ABS_RZ), value 0 Event: time 1518638451.953730, -------------- SYN_REPORT ------------ Event: time 1518638451.986736, type 3 (EV_ABS), code 0 (ABS_X), value 126 Event: time 1518638451.986736, type 3 (EV_ABS), code 1 (ABS_Y), value 127 Event: time 1518638451.986736, type 3 (EV_ABS), code 2 (ABS_Z), value 134 Event: time 1518638451.986736, type 3 (EV_ABS), code 5 (ABS_RZ), value 125 Event: time 1518638451.986736, -------------- SYN_REPORT ------------ Event: time 1518638452.053726, type 3 (EV_ABS), code 0 (ABS_X), value 134 Event: time 1518638452.053726, type 3 (EV_ABS), code 1 (ABS_Y), value 0 Event: time 1518638452.053726, type 3 (EV_ABS), code 2 (ABS_Z), value 125 Event: time 1518638452.053726, type 3 (EV_ABS), code 5 (ABS_RZ), value 0 Event: time 1518638452.053726, -------------- SYN_REPORT ------------ Event: time 1518638452.056753, type 3 (EV_ABS), code 0 (ABS_X), value 126 Event: time 1518638452.056753, type 3 (EV_ABS), code 1 (ABS_Y), value 128 Event: time 1518638452.056753, type 3 (EV_ABS), code 2 (ABS_Z), value 134 Event: time 1518638452.056753, type 3 (EV_ABS), code 5 (ABS_RZ), value 125 Event: time 1518638452.056753, -------------- SYN_REPORT ------------ Event: time 1518638452.089285, type 3 (EV_ABS), code 1 (ABS_Y), value 127 Event: time 1518638452.089285, -------------- SYN_REPORT ------------ Event: time 1518638452.123734, type 3 (EV_ABS), code 0 (ABS_X), value 134 Event: time 1518638452.123734, type 3 (EV_ABS), code 1 (ABS_Y), value 0 Event: time 1518638452.123734, type 3 (EV_ABS), code 2 (ABS_Z), value 125 Event: time 1518638452.123734, type 3 (EV_ABS), code 5 (ABS_RZ), value 0 Event: time 1518638452.123734, -------------- SYN_REPORT ------------ Event: time 1518638452.259251, type 3 (EV_ABS), code 0 (ABS_X), value 126 Event: time 1518638452.259251, type 3 (EV_ABS), code 1 (ABS_Y), value 127 Event: time 1518638452.259251, type 3 (EV_ABS), code 2 (ABS_Z), value 133 Event: time 1518638452.259251, type 3 (EV_ABS), code 5 (ABS_RZ), value 124 Event: time 1518638452.259251, -------------- SYN_REPORT ------------ ^C real 0m25.281s user 0m0.010s sys 0m0.000s
But as I said, I have a lot of errors in dmesg about hci0.
I read that people only get rid of this by using a BT key and not the native Pi3 BT chipset...
It also seems that 4.14 is around the corner according to rpi-update github, but I didn't see anything about BT... -
X/Y is the left analog stick and Z/RZ is the right. Does the evtest output always report this activity, or does it happen sporadically?
I have two official controllers (with different revision components inside), and neither has this issue.
Can you post the output from the beginning of evtest that shows the supported events and values? I've set a fuzz of 3 to match the older driver, as the analog sticks fluctuate between +/- a value of 1 for the resting position. Your output is very odd, however.
Can you also check your evtest output when connected via USB to see if the same happens? Make sure to disconnect from Bluetooth before plugging, as it may remain connected via BT when plugging the cable while already paired.
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.