Confusion regarding LIRC configuration

Hello dear OSMC community,

can someone please help me to understand the issue I am having with my Lirc configuration after upgrade to the latest OSMC? my setup is Raspberry Pi 3, irda led on GPIO17, latest OSMC and Toshiba remote. The line I have in /boot/config.txt:


This creates /dev/lirc0 and I get a reading when I run mode2 -d /dev/lirc0. The config for my remote has been created on the older version of OSMC and for some reason I am failing to recreate it with irrecord in the latest OSMC so instead I put it into /etc/lirc/lircd.conf.

The following processes are present once the system is booted:

/usr/sbin/lircd --driver=default --device=/dev/lirc0 --uinput --output=/var/run/lirc/lircd-lirc0 --pidfile=/var/run/lirc/ /etc/lirc/lircd.conf
sudo -u osmc LIRC_SOCKET_PATH=/var/run/lirc/lircd /usr/lib/kodi/kodi.bin --standalone -fs

If I start irw /var/run/lirc/lircd-lirc0 I can see how it is intercepting remote key-presses:

root@osmc:~# irw /var/run/lirc/lircd-lirc0 
0000000002fd12ed 00 KEY_RED Toshiba_CT-90326
0000000002fd12ed 01 KEY_RED Toshiba_CT-90326
0000000002fd12ed 02 KEY_RED Toshiba_CT-90326

If I understand the design correctly eventlircd should connect to lircd, translate the events and then pass them to to /var/run/lirc/lircd socket where they should be detected by kodi.

Alas nothing seems to be happening - it looks like eventlircd does not even try to read /var/run/lirc/lircd-lirc0:

root@osmc:~# /usr/sbin/eventlircd --evmap=/etc/eventlircd.d --socket=/var/run/lirc/lircd -f -vvvvv
eventlircd[930]: the highest verbosity level is -vvv
eventlircd[930]: the highest verbosity level is -vvv
eventlircd[930]: input device /dev/input/event4: events of unsupported event type EV_MSC will be discarded
eventlircd[930]: input device /dev/input/event4: event code 0x04 of unsupported event type EV_MSC will be discarded
eventlircd[930]: input device /dev/input/event4: events of unsupported event type EV_REP will be discarded
eventlircd[930]: input device /dev/input/event4: grabbed
eventlircd[930]: input device /dev/input/event4: created output event device

A workaround is to force kodi to read directly from /var/run/lirc/lircd-lirc0 (LIRC_SOCKET_PATH) but I don’t want to go this way as it will break sooner or later.

Can you please suggest where the problem might be?

Thank you,


You usually need to stop eventlircd to record with irrecord / test with irw.

You usually need to stop eventlircd to record with irrecord / test with irw.

With eventlircd, lircd and kodi stopped I first run irrecord with no arguments. I believe it’s using devinput driver by default:

$ irrecord
Hold down an arbitrary key
Timeout (10 sec), giving  up.

Nothing get recorded/saved. When I request to use a default driver:

$ irrecord  -H default
Press RETURN now to start recording.
Got gap (108361 us)}

Please keep on pressing buttons like described above.
.Cannot find any gap, using an arbitrary 50 ms one. If you have a
regular remote for e. g., a TV or such this is probably a point
where you hit control-C. However, technical hardware like air 
condition gear often works without any gap. If you think it's
reasonable that your remote lacks gap you can proceed. 
Press RETURN to continue.

Then I go on with adding a few keys but the resulting config file is not making any sense:

  one             0     0
  zero            0     0
  gap          50000
  toggle_bit_mask 0x0
  frequency    38000

      begin codes
          KEY_RED                  0x0
          KEY_GREEN                0x0
          KEY_YELLOW               0x0
      end codes

When I take an old lirc.conf file and try to add a previously removed mapping to it:

$ irrecord -H default -u toshiba.conf
Signals are pulse encoded.
Signal length is 16
Unknown encoding

Please enter the name for the next button (press <ENTER> to finish recording)

Successfully written config file toshiba.conf

The problem is that the key always has 0x000 appended to it and when used with lircd it fails to detect such keys. As soon as I remove that part it works.

KEY_RED                  0x12ED 0x0000

I suppose it’s something kernel-related but like I wrote in the original post - I am fine with using the old config for now as long as it can be integrated with the rest of the system.

The header of the old config file goes like this:

  name  Toshiba_CT-90326
  bits           16
  eps            30
  aeps          100

  header       9122  4473
  one           626  1646
  zero          626   511
  ptrail        625
  repeat       9120  2212
  pre_data_bits   16
  pre_data       0x2FD
  gap          108113
  toggle_bit_mask 0x0
  frequency    38000

I see a few misunderstandings in your post so I’ll attempt to explain how lirc should be working in OSMC and where you’re probably going wrong.

While it may not be causing your problems, you shouldn’t be editing /boot/config.txt directly anymore, rather putting your custom lines in the included file /boot/config-user.txt otherwise a future update is likely to wipe out your custom lirc dtoverlay settings.

If you still have a copy of the original config file, why not just use it ? I don’t understand why you’re using irrecord again, unless you changed remote control or lost the file… the lircd.conf file that you generate on any OSMC system using irrecord is compatible with any version of OSMC on any platform that supports lircd - so you could record on a Pi and use on a Vero4k or vica-versa…

You shouldn’t be directly editing /etc/lirc/lircd.conf - it’s a symlink which points to the profile “selected” by MyOSMC.

for example:

osmc@vero3:/etc/lirc$ ls -al
total 1516
drwxr-xr-x   2 root root   4096 Sep 19 23:22 .
drwxr-xr-x 125 root root  12288 Oct 22 07:00 ..
-rw-r--r--   1 root root   1089 May 27 01:24 apple-silver-A1294-lircd.conf
-rw-r--r--   1 root root  26870 May 27 01:24 apple-silver-A1294-lircd.png
-rw-r--r--   1 root root   1038 May 27 01:24 apple-white-A1156-lircd.conf
-rw-r--r--   1 root root  39796 May 27 01:24 apple-white-A1156-lircd.png
-rw-r--r--   1 root root  23092 May 27 01:24 atilibusb-lircd.conf
-rw-r--r--   1 root root 169574 May 27 01:24 atilibusb-lircd.png
-rw-r--r--   1 root root   1586 May 27 01:24 dell-travel-remote-nu851.lircd.conf
-rw-r--r--   1 root root 157000 May 27 01:24 dell-travel-remote-nu851.lircd.png
-rw-r--r--   1 root root      0 May 27 01:24 dvicoo-lircd.conf
-rw-r--r--   1 root root  42554 May 27 01:24 dvicoo-lircd.png
-rw-r--r--   1 root root   4394 May 27 01:24 hauppage45-pvr350-lircd.conf
-rw-r--r--   1 root root  39180 May 27 01:24 hauppage45-pvr350-lircd.png
-rw-r--r--   1 root root   2013 May 27 01:24 kls-1.6-lircd.conf
-rw-r--r--   1 root root  54790 May 27 01:24 lircd-full.conf
lrwxrwxrwx   1 root root     38 May  4  2020 lircd.conf -> /etc/lirc/apple-white-A1156-lircd.conf
-rw-r--r--   1 root root   1175 May 27 01:24 osmc-remote-lircd.conf
-rw-r--r--   1 root root 142537 May 27 01:24 osmc-remote-lircd.png
-rw-r--r--   1 root root   2717 May 27 01:24 philips-srm-7500-lircd.conf
-rw-r--r--   1 root root  59276 May 27 01:24 philips-srm-7500-lircd.png
-rw-r--r--   1 root root  11197 May 27 01:24 rc6-mce-lircd.conf
-rw-r--r--   1 root root  29164 May 27 01:24 rc6-mce-lircd.png
-rw-r--r--   1 root root   5450 May 27 01:24 samsung-lircd.conf
-rw-r--r--   1 root root 131181 May 27 01:24 samsung-lircd.png
-rw-r--r--   1 root root  10146 May 27 01:24 ttusbir-lircd.conf
-rw-r--r--   1 root root   1470 May 27 01:24 wdtvlive-remote-lircd.conf
-rw-r--r--   1 root root 113255 May 27 01:24 wdtvlive-remote-lircd.png
-rw-r--r--   1 root root    992 May 27 01:24 xbox-lircd.conf
-rw-r--r--   1 root root 157549 May 27 01:24 xbox-lircd.png
-rw-r--r--   1 root root   1670 May 27 01:24 xbox-one-lircd.conf
-rw-r--r--   1 root root 120143 May 27 01:24 xbox-one-lircd.png
-rw-r--r--   1 root root   2698 May 27 01:24 xbox360-lircd.conf
-rw-r--r--   1 root root 109895 May 27 01:24 xbox360-lircd.png
-rw-r--r--   1 root root   1045 May 27 01:24 yausbirv2_frontswitch.conf

If you save a file directly as /etc/lirc/lircd.conf it will be overwritten and lost if you ever change remotes in MyOSMC. And if you “edit” the symlink you will actually be editing and overwriting one of the built in profiles - whichever one the symlink currently points to.

The right way to do it is to save your custom lircd.conf file in /etc/lirc under a different name then update the symlink to point at it, as is done with all the bundled profiles. This is compatible with the way MyOSMC changes remote profile. (It just updates the symlink and restarts the services)

This looks OK so far,

The lirc socket /var/run/lirc/lircd-lirc0 is only there for debug purposes as it is useful for running irw with it as you have done, however Eventlircd does not make use of it.

What actually happens is lircd is run with the --uinput option which causes it to output uinput (dev/input) events to the linux kernel.

You can see this /dev/input device created by lirc below with evtest, event device 6 on my system: (I ran this on a Vero4k so it will have some additional devices you won’t see on a Pi)

osmc@vero3:~$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      gpio_keypad
/dev/input/event1:      aml_vkeypad
/dev/input/event2:      cec_input
/dev/input/event3:      input_btrcu
/dev/input/event4: flirc
/dev/input/event5:      meson-ir
/dev/input/event6:      lircd

Eventlircd then intercepts these events from Lircd, processes them and then outputs them on its own lirc socket at /var/run/lirc/lircd which is the Lirc socket that Kodi connects to.

A udev rule (can’t remember it’s location off hand) is responsible for recognising lircd’s /dev/input device and causing eventlircd to “grab” it in exclusive mode to prevent other software like Kodi from directly recognising it as a /dev/input device, which would cause duplicate button presses and incorrect button mappings.

It’s hard to say what might be wrong on your system because your testing is based on some incorrect assumptions about how it should be working, so I would suggest the following:

If you want to use irrecord you should do this first:

sudo systemctl stop lircd_helper@lirc0.service eventlircd.service

This will stop both the lircd instance and eventlircd. Then use irrecord. When you’re finished and have symlinked your file do:

sudo systemctl restart lircd_helper@lirc0.service eventlircd.service
sudo systemctl restart mediacenter.service

It’s important for Kodi to be restarted after eventlircd is restarted, otherwise Kodi will receive /dev/input events directly from lircd which will cause problems with repeats and incorrect button mappings, (since the /dev/input mappings and lircd mappings in Kodi are completely separate)

Kodi must always start after eventlircd not before, otherwise eventlircd cannot gain exclusive access to the /dev/input device belonging to lircd.

1 Like

devinput is the wrong driver, it should be one called lirc, as far as I remember.

Normally this should work:

sudo irrecord -d /dev/lirc0

You do have to manually specify the correct lirc device with -d.

You could also try:

sudo irrecord -H default -d /dev/lirc0

@sam_nazarko - is the /dev/lirc driver for irrecord missing ?

Shouldn’t be – but I know that since 4.9 some have had issues with recording (can’t get a good recording).

Thank you @ DBMandrake this was extremely useful!

If you still have a copy of the original config file, why not just use it ? I don’t understand why you’re using irrecord again, unless you changed remote control or lost the file…

At this point I don’t need it, sure. But at the same time I want to be able to rerun the same procedure on any other devices in the future (TV gets broken, I am at my parent’s home etc). Therefore I was just testing the whole process from recording to using it in Kodi.

I made the following fixes:

  • removed /etc/lirc/lircd.conf and recreate is as a symlink to my toshiba remote config
  • restored <remote device="linux-input-layer"> in Lircmap.xml

After that I rebooted and miracle happened. Life is great again!

For the record: following your steps I was still unable to get irrecord record the buttons properly but at least there is a workaround. And I should probably add that I am not using infrared diode directly but a RemotePi Board (Support for RemotePi Board for Pi 4, RemotePi Board for Pi 3 B+, Pi 3, – MSL Digital Solutions) - not sure if it plays any role here.

Cheers, jose