IR remote and longpress

  • In most cases LibreELEC uses eventlircd as a shim to pass IR button presses from kernel to Kodi. This approach is stable and reliable, but has one rather major drawback: it’s impossible to use longpress events, which in fact halves the amount of actions you can bind to your IR remote buttons.


    Alternative approach is to disable eventlircd altogether and use IR remote as a Linux keyboard device, so this is a way I went.


    LibreELEC documentation says “Kodi ... doesn't cope well with Linux input events”, I’d say this is the understatement of the century, to put it mildly. Kodi keyboard handling system is archaic, weaving layer upon layer of abstractions, throwing away more and more of your keypresses, the deeper it goes.


    To my understanding, the way IR keypress travels towards Kodi in is:

    1) Linux kernel decodes IR signal and translates keypress to evdev scancode, based on IR remote .toml definition, loaded by ir-keytable.

    2) Xkbcommon library assumes we got a standard pc105 keyboard and translates evdev code to something resembling xfree86 keycode, according to /usr/share/X11/xkb/keycodes/evdev

    3) Xkbcommon library futher translates xfree86 keycode to xkb key name, mapping non-printable keys according to /usr/share/X11/xkb/symbols/inet

    4) Kodi accepts a very limited subset of xkb key names, filtering them and mapping to Kodi internal keysyms, according to code in xbmc/platform/linux/input/LibInputKeyboard.cpp

    5) Kodi goes through another layer of translations, from Kodi internal keysyms to Kodi internal vkeys and Kodi keynames, relevant code in xbmc/input/XBMC_keytable.cpp

    6) Kodi once again translates, keynames are mapped to actions, based on default rules in /usr/share/kodi/system/keymaps/keyboard.xml and user customizations in ~/.kodi/userdata/keymaps/keyboard.xml


    Every layer of this onion has some random historical subset or superset of non-printable keycodes hardcoded in, throwing away everything else, sometimes in completely illogical way. There is no way for user to bind directly to kernel evdev scancode, is all buried and hidden away. I’m afraid to look at the Windows or Android keyboard abstractions, probably not much saner.


    But in the end I managed to dig through this spaghetti and made a .toml keymap for my IR remote, scraping together some 50 evdev keys Kodi actually lets through the cracks. Longpress events work for me now, yey. Hope my keymap can help someone with the same problem.


  • First of all, hello! :) I've come across your thread because I'm using one of those very cheap remotes:



    to control my RPi Zero. It has indeed a very few keys (only 17) and I've barely managed to add just back and mute apart from the navigation keys, the enter one and finally the numeric ones which are relevant to me as I use LE as a TV among other things.

    I was then wondering about a SHIFT function like it happens on some remotes to almost double the available keys but I don't know if LIRC handles such a scenario (I don't think so nor I've found anything about it) then I've found your thread.

    Honestly speaking, looking at the toml I haven't understood well what you've done. Let's consider CHANNELUP: according to your comments, you've mapped it to both KEY_PAGEUP and KEY_PAGEDOWN by the long press workaround but at the beginning of the line I see two different keycodes which means we're talking about two different keys, not the same one. I don't know...

    Another doubt has arisen inside me: your toml file uses the old syntax

    Code
    keycode = "action"

    while now LE uses the syntax

    Code
    keycode "action"

    and, even more, no longer accepts the let's say 'header'

    Code
    [[protocols]]
    name = "myoldremote"
    protocol = "nec"
    variant = "necx"
    [protocols.scancodes]

    indeed, if you include it, it throws an error and doesn't use the so defined toml file. The one I've defined is indeed quite different than yours, not only because it doesn't handle longpresses and obviously is perfectly working (I'm under LE 9.2.6) like yours does too for sure. Probably, we're under different LE versions or, given that in the preface you say you've gone over eventlircd, maybe doing this reverts back to the old syntax, I don't know.

    Have a nice day! :)