I’ve been setting up a RetroPie box on an Orange Pi Lite (handily, it also does double duty, hosting my 3d print server) and I ran into an issue where the ps4 dualshock stays on until it’s manually shutoff, otherwise the battery drains. Why am I using computers if I need to remember to do stuff? Unfortunately, I’d not done any calibration of the input device thusfar, so even if I wanted to somehow detect that it’d gone idle for X minutes, I couldn’t since it was constantly generating input values inside the axes deadzones. You can check this sort of thing using jstest:
gthomson@RetrOrangePi:~$ jstest /dev/input/js1 Driver version is 2.1.0. Joystick (Wireless Controller) has 8 axes (X, Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y) and 14 buttons (BtnX, BtnY, BtnZ, BtnTL, BtnTR, BtnTL2, BtnTR2, BtnSelect, BtnStart, BtnMode, BtnThumbL, BtnThumbR, ?, ?). Testing ... (interrupt to exit) Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off
So before I could detect that the dualshock had gone idle for X minutes, I needed a way to squelch the spurious activity in the deadzones. There also exists a utility called jscal, which can take a list of numbers to set deadzones and min/max values for the various axes on your input device. However, I wasn’t really up for sorting out what the format of the arguments were and what values I needed exactly. Fortunately, a little digging led me to discover that there’s a dpkg called jstest-gtk that let’s you run a fairly simple wizard-like calibration. You can then spit out the calibrated vlaues using jscal -p, and stick them in some udev rules to apply them every time the dualshock is turned on and connects.
Alright, now I just want to run this jstest-gtk, so I have to move my keyboard and mouse over to my orange pi to run it locally on X11 there right? Not so fast. Now that Windows hosts a remarkably native-like Linux subsystem, we should be able to install an X11 server on windows, and forward X11 events to our Windows X11 server via ssh. One such X11 server for windows is the Xming X Server for Windows. After installing, in your Windows bash prompt, enter:
gthomson@megamaid:~$ export DISPLAY=127.0.0.1:0
(You can stick this in your ~/.bashrc so it’s always set.) Your ssh command should use the -X flag to enable X11 forwarding:
gthomson@megamaid:~$ ssh -v -X 192.168.x.y
By the way, X11 forwarding needs to be enabled on your host, by having X11Forwarding yes set in /etc/ssh/sshd_config. It was by default for me, YMMV depending on what distro/platform you’re on.
Then, after logging into my Orange Pi box and ensuring that the DISPLAY env variable was set (sshd sets the environment value if you connect with X11 forwarding enabled), I ran jstest-gtk
Behold, a gtk app running on Ubuntu on Windows via ssh off Armbian on an Orange Pi Lite.
If you try this with an application running as root (eg using sudo), you’ll probably get X11 authentication errors. You can fix this with:
$ sudo su $ xauth merge /home/user/.Xauthority
Admittedly there isn’t anything different when using openssh or putty, but this is all kinds of handy that will cut down on the amount of times I need a keyboard connected to my Orange Pi, and I very much like not having to install anything more than Xming on Windows to do it. At the end of the day, I think I’m leaning towards shutting off the controller by adding some script hooks to EmulationStation‘s screensaver functionality rather than using controller idle-time, which may be the subject of my next post.