Retropie-setup: Disable DS3/DS4 motion controls by default

[rsn8887]

DS3/DS4 motion controls are detected as separate controller and interfere with some emulators such as AdvanceMame.

There's a discussion about this in the RetroPie forum, and I found a simple solution via a udev rule as detailed here on the forum: https://retropie.org.uk/forum/post/152584

The solution is:

• ssh into your RetroPie

• enter

sudo nano /etc/udev/rules.d/51-disable-DS3-and-DS4-motion-controls.rules

• paste the following into the editor

#disable DS3/DS4 motion controls
SUBSYSTEM=="input", ATTRS{name}=="*Motion Sensors", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""

• Hit CTRL-x and y to save

• reboot and verify that motion controls are disabled. For example Emulationstation should only detect 1 controller per DS4 etc.

Can this solution be incorporated into the next RetroPie release?

[psyke83]

I've already patched customhidsony to disable the motion sensor node via the driver, but I haven't tried this approach. Does it solve the issue of the motion sensor node occupying a controller slot in userspace? To illustrate, if I connect two DS3 controllers with the unpatched hid-sony driver, the kernel assigns the first pad to player 1 and the second to player 3 (with player 2/4 presumably assigned to the motion sensor nodes).

[rsn8887]

I didn't test the player assignment. Can you tell me a shell command I can use to test this?

[psyke83]

I'm uncertain if there's a userspace tool to check definitively, but you can observe it happening by the actual controller LEDs (first pad lights LED 1, second lights LED 3), and the second pad doesn't function as player 2 in retroarch.

I'll check this out when I have some free time, but in the meantime, this is the patch to disable sensors that's applied via customhidsony: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/supplementary/customhidsony/0001-hidsony-nomotionsensors.diff

I isolated this change to sixaxis controllers, as I don't have the DS4 controllers and thus wasn't sure if it had the same issue.

[rsn8887]

Is customhidsony the default Linux driver for both DS3 and DS4 in RetroPie? Or is it an optional install?

I like the idea of patching the driver directly, if it works. But it should be done for both DS3 and DS4, since DS4 controllers have the same issue. And I think it should be done with the default Linux driver so it is always up-to-date.

DS4's don't have the player LEDs. I am not sure if it means anything, and I have to do more testing, but with my udev rule, my single DS4 controller is registered in AdvanceMame as "js2." This sounds like the player numbers are still messed up, since it should show up as "js1" shouldn't it?

[psyke83]

It's an optional install, which provides a very minor update to the hid-sony driver (backported from kernel 4.15) mainly to fix an infinite rumble via USB issue with Shanwan controllers.

I'll take a look again to see if we can achieve the same goal via something similar to your method or another sysfs userspace method. If not, I'll adjust the patch so that it also disables the sensor node on DS4 controllers too.

I've already got another PR pending that aims to help work around hid-sony driver quirks, including an additional patch to disable the digital trigger buttons in the driver: https://github.com/RetroPie/RetroPie-Setup/pull/2263

The overall aim is to replace the ps3controller userspace wrapper in favour of using the native BlueZ plugin, but the changes here can most likely also benefit DS4 pads. I might need to add some udev entries so that DS4 pads can also avail of the idle timeout function, though.

[rsn8887]

Never mind forget what I said.

I just tested my udev rule approach again properly and this time I paid attention to the player assignments.

I must have remembered it wrong when I wrote my last post.

My udev rule actually seems to work perfectly, including player assignments. I have player 1 and 2 they register correctly as player 1 and 2, also in AdvanceMAME it works as it should (remapping shows j and j2 correctly.) In Retroarch I have control of player 1 and 2 as expected. On my DS4’s one LED is blue and one LED is red indicating first and second player.

So compared to your patches to the optional driver install, I think this udev rule is a much simpler and future proof fix to properly disable motion sensors.

Please feel free to test the udev rule yourself with your DS3’s. All my tests were done using DS4 controlllers only.

[rsn8887]

Can this be implemented? My udev rule has been tested and works perfectly.

I don’t see a reason to keep Retropie in the current broken state any longer, where DS4 controllers are completely unusable.

Of course I appreciate the other effort of patching a separate driver. But that can be a separate effort independent of this fix for the system driver.

Personally I don’t see the reason of an optional driver install if the default system driver works fine. Also, both solutions can happily co-exist.

With just this simple added udev rule to mute the motion controls in the default driver, it should work fine for most users. There should be no need to install another driver and re-pair controllers etc. Unless maybe the user has a knock-off controller.

In addition, this approach will keep Retropie future proof since I expect the system driver to have attention from the greater community.

I understand I should make a PR. But although my udev fix works, I don’t know where udev rules should be added during the boot process...

[psyke83]

The hid-sony driver in kernel 4.14 (Raspbian stretch) is broken for third-party controllers: Shanwan have an eternal USB rumble bug, and Gasia won't pair via BT (which isn't fixed in any upstream kernel release yet).

I had forgotten about your udev rule; while it may at least allow the motion control patch to be removed, we still need to patch the driver for the aforementioned reasons. I'll take a look soon and update my PR with your udev rule if it works OK (i.e. doesn't mess up the LED assignments on DS3 controllers).

[rsn8887]

I think support for official controllers should have a higher priority than this Shanwan/Gasia knock-off stuff.

I wouldn’t call the system driver broken if it works fine with official controllers. I don’t think it is the job of that driver to support all the possible obscure Chinese knock-off controllers which are not 100% compatible.

Since most users have first party controllers, I don’t think they should wait until your patched driver is ready. After all, the system driver will be fine for them, and requires zero additional work apart from this udev rule. I think udev rules are the “system friendly” way to deal with this stuff, compared to patching drivers.

If this udev rule is implemented at least users of genuine Sony controllers will have a working build of Retropie.

It is great that you are patching another driver to add support for these obscure third party controllers. But I think most users won’t need it.

Maybe two udev rules can be added, one for your new patched driver and one for the default driver?

This way people who use first party controllers don’t need to do anything, and people who have third party controllers can install your patched driver and maybe benefit form a udev rule and less patching of the source code there, too.

Having a choice between multiple drivers (system default / your patched one) that work would be great anyways, because there might be other differences. For example analog shoulder buttons might be treated differently, lag might be different, etc.

[psyke83]

No, the patched driver is not only for third-party controller support. I'm not certain what the situation is with DS4 controllers, but the default hid-sony driver on its own is not a viable replacement for the ps3controller (sixad) driver on a DS3. Reasons include:

• the default axis configuration has jitter (i.e., the resting position of the analog sticks produces a constant stream of evdev events).
• the sixaxis plugin of BlueZ doesn't support the system Bluetooth IdleTimeout setting. This means that once the controller is paired, it will stay paired until the user forcibly disconnects the pad (holding the PS button for 10 seconds), the system turns off or when the battery runs flat. This is totally unacceptable for a lot of people that keep their Pi on 24/7.
• the L2 & R2 buttons map to a digital button as well as virtual axes (to report button pressure). This has the effect of confusing any applications that require joystick button mapping. Kodi has a special feature to workaround this, but EmulationStation will not be able to map these buttons correctly (as it will interpret two separate button events for a single press of those buttons).

My PR is going to add an optional driver module that's installed instead of ps3controller, with the aim of addressing all of these issues. The patched driver will therefore be optional, so I don't see the point in complaining about something that's not going to be foisted on everyone.

I've added your udev rule to my sixaxis scriptmodule as it's definitely useful to mitigate one of the issues with the driver, but that package will also install the patched driver alongside it. The RetroPie image only includes a few generic udev rules to relax permissions, IIRC, so I'm not sure if adding such a controller-specific workaround by default is wise, especially when the driver already suffers from plenty of other issues by default.

[rsn8887]

Understood. I wasn’t aware of the other issues with the default driver. I apologize, I didn’t mean to complain about your driver, rather about why the system driver was considered broken. But it came across much more confrontative than I intended.

Thanks for clearing this up.

[psyke83]

The sixaxis scriptmodule is now merged into master; this will install the udev rule to hide motion controls and make sure that applications don't erroneously identify the controller as a keyboard (which is a bug that's already fixed in later upstream versions of systemd).

Unlike the testing version of the scriptmodule you may have tested, installation of customhidsony and custombluez is not performed unless you manually enable third-party controller support in the configuration menu for the scriptmodule.

[rsn8887]

I am glad to see the issue fixed. Thanks for the great work!

[joolswills]

Thanks @psyke83 :-)

[ryanw4130]

Thanks for the script instructions! I also modified it to disable the touchpad.
I am running 2 dual shock 4 controllers on Retropie v4.4, with on-board Bluetooth disabled. I have them paired to a Bluetooth 4.0 USB adapter, and I noticed that if you press the touchpad in megadrive games, the pi would freeze. This got real annoying. So I copied your script and added another line to disable to DS4 touchpads. This did the trick, or at least I tested it on some megadrive games, and it no longer freezes. Going to configure the controllers in reicast, and the touchpad no longer shows up as a input.

Maybe someone else can find this useful. Here is the what i used.

disable DS3/DS4 motion controls

SUBSYSTEM=="input", ATTRS{name}=="Motion Sensors", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""
SUBSYSTEM=="input", ATTRS{name}=="Touchpad", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""