This post is largely to remind myself of the details next time I hit something similar; I found bits of relevant information all over the place, but not in one single location.
I love Kodi. These days the Debian packages give me a nice out of the box experience that is easy to use. The problem comes in dealing with remote controls and making best use of the available buttons. In particular I want to upgrade the VDR setup my parents have to a more modern machine that’s capable of running Kodi. In this instance an AMD E350 nettop, which isn’t recent but does have sufficient hardware acceleration of video decoding to do the job. Plus it has a built in fintek CIR setup.
First step was finding a decent remote. The fintek is a proper IR receiver supported by the in-kernel decoding options, so I had a lot of flexibility. As it happened I ended up with a surplus to requirements Virgin V Box HD remote (URC174000-04R01). This has the advantage of looking exactly like a STB remote, because it is one.
Pointed it at the box, saw that the
fintek_cir module was already installed and fired up
irrecord. Failed to get it to actually record properly. Googled lots. Found
ir-keytable. Fired up
ir-keytable -t and managed to get sensible output with the RC-5 decoder. Used
irrecord -l to get a list of valid button names and proceed to construct a vboxhd file which I dropped in
/etc/rc_keymaps/. I then added a
fintek-cir * vboxhd
/etc/rc_maps.cfg to force my new keymap to be loaded on boot.
That got my remote working, but then came the issue of dealing with the fact that some keys worked fine in Kodi and others didn’t. This seems to be an issue with scancodes above 0xff. I could have remapped the remote not to use any of these, but instead I went down the
inputlirc approach (which is already in use on the existing VDR box).
For this I needed a stable device file to point it at; the
/dev/input/eventN file wasn’t stable and as a platform device it didn’t end up with a useful entry in
/dev/input/by-id. A ‘quick’
udevadm info -a -p $(udevadm info -q path -n /dev/input/eventN)
provided me with the PNP id (FIT0002) allowing me to create
/etc/defaults/inputlirc ended up containing:
EVENTS="/dev/input/remote" OPTIONS="-g -m 0"
The options tell it to grab the device for its own exclusive use, and to take all scancodes rather than letting the keyboard ones through to the normal keyboard layer. I didn’t want anything other than things specifically configured to use the remote to get the key presses.
At this point Kodi refused to actually do anything with the key presses. Looking at
~kodi/.kodi/temp/kodi.log I could see them getting seen, but not understood. Further searching led me to construct an Lircmap.xml - in particular the piece I needed was the
<remote device="/dev/input/remote"> bit. The existing
/usr/share/kodi/system/Lircmap.xml provided a good starting point for what I wanted and I dropped my generated file in
(Sadly it turns out I got lucky with the remote; it seems to be using the RC-5x variant which was broken in 3.17; works fine with the 3.16 kernel in Debian 8 (jessie) but nothing later. I’ve narrowed down the offending commit and raised #117221.)
Helpful pages included: