RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login
    Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

    PS4 Controler - quick and dirty auto power off

    Scheduled Pinned Locked Moved Help and Support
    controllerbluetoothps4
    3 Posts 1 Posters 1.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      filius.martis
      last edited by filius.martis

      Greetings!

      I am using RetroPie 4.x on my Raspberry Pi3 together with a PS4 Controller paired with the onboard btbcm.

      First I had lots of troubles getting it work, because due to a new hardware revision the hid-sony drivers before kernel 4.5rc1 don't work (-> Some Sony Dualshock 4 controllers do not work in kernel 3.15+ ). Now by adapting the patch to every raspbian kernel update, it works like a charm although I still hope for an upstream kernel 4.5 or later to get rid of the module rebuilding eatch time.

      Anyways, next thing that made me sad about the PS4 Controller is that it doesn't go to sleep automatically. If you forget to put it off after usage (by pressing the Playstation button an endless time of at least 10 seconds), the thing will completely drain its battery empty and become useless until recharging.

      So here is my quick and (very) dirty workaround. Note that you will loose Bluetooth SIM Access Profile support](https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles#SIM_Access_Profile_.28SAP.2C_SIM.2C_rSAP.29) and it will also disconnect all other bluetooth devices when restarting bluetooth. As I am using no other bluetooth devices, thats no problem with my setup.

      1) edit /lib/systemd/system/bluetooth.service to disable the SAP plugin (which otherwise prevents the bluetooth service from restarting: ExecStart=/usr/lib/bluetooth/bluetoothd --noplugin=sap)

      2) whenever you want to power off your controller, issue these two commands in a row:
      systemctl restart bluetooth
      hciconfig hci0 up

      This works fine for me, but obviously I am no shell scripting hero. Maybe someone could help to improve the approach and automate it in a reliable way.

      1) Is bluetoothctl (or other tools) able to disconnect only a particular device? This would be so much better than restarting the whole bluetooth stack at once.

      2) How could a background process (thinking of a daemon) determine how long the Controller was not in use and therefore automatically trigger the disconnection procedure?

      Any help and other ideas welcome! :-)

      1 Reply Last reply Reply Quote 0
      • F
        filius.martis
        last edited by filius.martis

        Okay, one step further. There is no need to restart the whole bluetooth services, hcitool does the trick and allows to disconnect particular devices by id.

        pi@retropie:~ $ hcitool con
        Connections:
        > ACL AC:FD:93:4C:8B:EA handle 12 state 1 lm MASTER AUTH ENCRYPT
        pi@retropie:~ $ hcitool dc AC:FD:93:4C:8B:EA
        Disconnect failed: Operation not permitted
        pi@retropie:~ $ sudo hcitool dc AC:FD:93:4C:8B:EA

        Now I just need a reliable way to check how long my controller has been unused. Unfortunately the PS4 Controller is not "silent" when untouched, it generates constant events on /dev/input/eventX.

        Any ideas?

        1 Reply Last reply Reply Quote 0
        • F
          filius.martis
          last edited by filius.martis

          Another step forward! These are my controllers default calibration values:

          jscal -s 18,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,0,0,536870912,536870912,1,0,0,0,536870912,536870912,1,255,-4208,3952,21931,21931,1,255,-4208,3952,21931,21931,1,255,-4208,3952,21931,21931,1,63,-1023,1023,87367,87367,1,63,-1023,1023,87367,87367,1,63,-1023,1023,87367,87367,1,0,0,0,0,0,1,0,960,960,559240,559240,1,0,471,471,1139853,1139853,1,0,32767,32767,16384,16384 /dev/input/js0

          And this pacifies the gyroscope's axis. I don't need them and they cause endless events if not "deadzoned":

          jscal -s 18,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,0,0,536870912,536870912,1,0,0,0,536870912,536870912,1,255,0,0,0,0,1,255,0,0,0,0,1,255,0,0,0,0,1,255,0,0,0,0,1,255,-0,0,0,0,1,255,0,0,0,0,1,0,0,0,0,0,1,0,960,960,559240,559240,1,0,471,471,1139853,1139853,1,0,32767,32767,16384,16384 /dev/input/js0

          Unfortunately there is no way to calibrate /dev/iput/event0, but /dev/input/js0 (jstest /dev/input/js0) is completely silent now if the gamepad isn't in use. This should be good enough for me, as even SDL might be forced to use /dev/input/js0 (export SDL_JOYSTICK_DEVICE=/dev/input/js0).

          Next step would be to recognize for how long /dev/input/js0 showed no action. Any ideas?

          1 Reply Last reply Reply Quote 0
          • First post
            Last post

          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.