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:
dtoverlay=gpio-ir,gpio_pin=17
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:
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?
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)
KEY_RED
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
flags SPACE_ENC|CONST_LENGTH
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.tv 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:
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.
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!