Triggerhappy Not Firing Events for Volume/Mute

jmferris

I have been working on getting my setup working, incrementally. Until I build my control panel, I am using a keyboard and gamepad to tweak my system to just the way that I want it.

As to specifics, nothing fancy. I have a Pi 3 with a fully updated version of Jessie and RetroPie, after having started with the image. I have an IQaudIO Pi-DAC+ for a HAT, a generic USB keyboard, and a Logitech Gamepad. Functionally, everything works. There are no video issues, audio issues, or control issues.

What I am having an issue with, however, is getting Triggerhappy to register keypresses. I have written three simple shell scripts - one each to turn the volume up (and play an indicator sound), turn the volume down (and play an indicator sound), and toggle the mute state. If I hit F4 and drop out to the command line, they all execute as expected. Same if I am SSH'd in to the Pi - I'll invoke the script from my session, and I will hear the change being made by the script. I would assume that Triggerhappy should also be firing when I hit those keys from the command line on the physical device (although I am not sure), and confirm that it does not fire off those same scripts.

My first step in getting Triggerhappy working was follow the steps from Zigurana, in this post:
https://retropie.org.uk/forum/topic/2377/control-volume-through-retroarch-with-keyboard/3

Where it gets confusing, is that it actually was working just fine. It worked for a couple of day, and it has simply stopped working without me having (knowingly) changed anything. I have done some diagnosis, but am at a loss for where to look to next. I was hoping that someone might be able to assist me further?

First, I ran thd --dump /dev/input/event*. Then, I hit the three keys that I was interested in, being volume up, volume down, and mute. As expected, I saw them associated with event1, and mapped to KEY_VOLUMEUP, KEY_VOLUMEDOWN, KEY_MIN_INTERESTING. This matches what I saw before, when I had gotten this working.

I then confirmed that Triggerhappy was, indeed, running, through service --status-all. It was showing, with the expected "+" indicator. So, I've rechecked my configuration.

The content of my audio.conf that I added to /etc/triggerhappy/triggers.d/

KEY_VOLUMEUP 1 bash /home/pi/bin/volume_up.sh
KEY_VOLUMEUP 2 bash /home/pi/bin/volume_up.sh
KEY_VOLUMEDOWN 1 bash /home/pi/bin/volume_down.sh
KEY_VOLUMEDOWN 2 bash /home/pi/bin/volume_down.sh
KEY_MIN_INTERESTING 1 bash /home/pi/bin/volume_mute.sh
KEY_MIN_INTERESTING 2 base /home/pi/bin/volume_mute.sh

A dump of my input devices, via cat /proc/bus/input/devices:

I: Bus=0003 Vendor=1a2c Product=2d23 Version=0110
N: Name="USB USB Keyboard"
P: Phys=usb-3f980000.usb-1.3/input0
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:1A2C:2D23.0001/input/input0
U: Uniq=
H: Handlers=sysrq kbd leds event0
B: PROP=0
B: EV=120013
B: KEY=10000 7 ff800000 7ff febeffdf f3cfffff ffffffff fffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=1a2c Product=2d23 Version=0110
N: Name="USB USB Keyboard"
P: Phys=usb-3f980000.usb-1.3/input1
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1/0003:1A2C:2D23.0002/input/input1
U: Uniq=
H: Handlers=kbd event1
B: PROP=0
B: EV=1f
B: KEY=3007f 0 0 0 0 483ffff 17aff32d bf544446 0 0 1 130c13 b17c000 267bfa d941dfed 9e1680 4400 0 10000002
B: REL=40
B: ABS=1 0
B: MSC=10

I: Bus=0003 Vendor=046d Product=c21d Version=4014
N: Name="Logitech Gamepad F310"
P: Phys=usb-3f980000.usb-1.2/input0
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/input/input2
U: Uniq=
H: Handlers=event2 js0
B: PROP=0
B: EV=20000b
B: KEY=7fdb0000 0 0 0 0 0 0 0 0 0
B: ABS=3001b
B: FF=1 7030000 0 0

Finally, I confirmed that the daemon settings matched what I had originally set them to, and it does. From /etc/init.d/triggerhappy:

DAEMON_ARGS="--daemon --triggers /etc/triggerhappy/triggers.d/ --socket /var/run/thd.socket --pidfile $PIDFILE --user pi /dev/input/event*"

Worth mentioning that I have tried this with an additional keyboard (a wired Microsoft one), and I am met with the same results. If I view the dump from thd, it is capturing the events. However, outside of that, there is no response. I've also changed my audio.conf to use a more traditional command to directly adjust the mixer volume (bypassing the mute check and indicator sounds). Again, no response from the host machine when I press any of those keys.

Any help would be most appreciated. More than happy to try anything, at this point, as well as provide whatever other information might help.

Thank you in advance!

jmferris

I do have additional information. Seeing as I have not done much, I started again from the base offical RetroPie image and applied my changes again.

It does work from the command line. While I had originally thought that it was not working from the command line, and that I followed my build notes to the letter again, I can only assume that it was working from the command line, and I must have had my amplifier turned down to the point I could not hear it.

Where it is not working, however, is from EmulationStation, itself. It is almost like EmulationStation is eating the keypresses. I am hoping that this additional information might be able to have someone point me at something that I may have missed along the way.

As before, any insight would be most appreciated.

Thank you!

jmferris

As much as I wish that I had an answer for this, I do not. However, I do have resolution. I started over from the bare image again, and rewrote my scripts from scratch to favor ALSA over PulseAudio - and did not install PulseAudio this time around. Considering the other issues that PulseAudio was giving me, in terms of system stability (or the lack of system stability), I can only imagine that my original issues were also related to that.

On the plus side, I've managed to knock together a decent script that gives me what I was after - volume up/down followed by an indicator tone, volume up/down to exit mute state, and a functional mute toggle through tracking the volume and mute states. More complex than what I was trying originally, which was using pactl to control it all, considering that I am on of the "lucky" ones who cannot get ALSA to unmute.