Unable to get IR to work on bullseye

Help and Support
1

Yesterday I did a fresh install of the new OSMC bullseye release form 2022-09-18 on my raspberry pi3. Since I have many other services active I might have done some untypical things, but final everything is working fine with one exception: I’m unable to recover IR remote control with the same settings used within buster:

I do run irexec to capture IR commands not to be used by kodi. Working fine within bullseye, i.e. my IR sensor attached directly to my raspberry is working . Within kodi I’ve selected the mc6 keyboard, rc6 protocol is active. With those settings IR signals arrived at kodi within buster without problem, within bullseye no IR events reach kodi.

I’ve checked ir-keytable, looks fine

Found /sys/class/rc/rc0/ with:
Name: gpio_ir_recv
Driver: gpio_ir_recv
Default keymap: rc-empty
Input device: /dev/input/event0
LIRC device: /dev/lirc0
Attached BPF protocols:
Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon
Enabled kernel protocols: lirc
bus: 25, vendor/product: 0001:0001, version: 0x0100
Repeat delay = 500 ms, repeat period = 125 ms

Testing IR keypresses with ir-keytable -t didn’t show keypresses.
Thus I’ve tried to load a ir-keytable by

ir-keytable -p lirc -p rc-6 -p mce_kbd

Now I can see keypresses, but they still don’t arrive within kodi.
lircd, eventlircd, irexecd are all running without error message.

To workaround a bug within buster I had to create the symbolic link

cd /usr/var/run/lircd
ln -s /var/run/lirc/lircd

Of course I do the same for bullseye.

Any ideas?

Regards, Michael

2

You could check with evtest or irrecord.

3

irrecord didn’t help. But nevertheless it pointed me into the correct direction -
using ir-keytable -t I see all my ir events as expected, e.g.

Testing events. Please, press CTRL-C to abort.
84715.350095: lirc protocol(rc6_mce): scancode = 0x800f041e
84715.450169: lirc protocol(rc6_mce): scancode = 0x800f041e
84715.550171: lirc protocol(rc6_mce): scancode = 0x800f041e
84716.750207: lirc protocol(rc6_mce): scancode = 0x800f041f toggle=1
84716.860140: lirc protocol(rc6_mce): scancode = 0x800f041f toggle=1
84716.960201: lirc protocol(rc6_mce): scancode = 0x800f041f toggle=1
84718.360147: lirc protocol(rc6_mce): scancode = 0x800f041e
84718.460152: lirc protocol(rc6_mce): scancode = 0x800f041e
84718.570118: lirc protocol(rc6_mce): scancode = 0x800f041e

But those events don’t show up within kodi. If I remember correctly, no further configuration within kodi was necessary for buster besides selecting the intended remote - I did select rc-6-mce-lircd and I did untick “RC6 deactivate”. And I verified those settings within /etc/lircd:

lrwxrwxrwx 1 root root 28 19. Sep 10:34 lircd.conf → /etc/lirc/rc6-mce-lircd.conf

There is only one spurious message regarding lirc within dmesg (the rest looks fine):

[ 9.037582] rc_core: IR keymap rc-lirc not found
[ 9.038060] rc rc0: lirc_dev: driver gpio_ir_recv registered at minor = 0, raw IR receiver, no transmitter
[ 10.346475] input: eventlircd as /devices/virtual/input/input1
[ 10.452848] input: lircd as /devices/virtual/input/input2

BTW, I now have exactly the same problem as end of 2021 - see Can't get IR working using harmony mce keyboard - #13 by olwaldi
I.e. keysms are missing. But finally it worked within buster without any tweaking.

Regards, Michael

4

I’m starting to discover the root cause of my problem: lircd - eventlircd - irexec do disturb each other. That was my first check of course - I stopped irexec, but IR didn’t work. But one has to do more: I’ve stopped mediacenter, lircd, eventlircd, and irexec. When I then start eventlircd, lircd is started automatically. Then I start mediacenter, and the IR remote works as expected! Then I’ve started irexec, and even irexec is working, but lircd dies. Nevertheless currently everything is working.

Now I have to discover howto get irexec to work together with lircd/eventlircd.

Thanks for your patience, Michael

5

You need to decide how you want your remote to work: either kernel based decoding (ir-keytable) or LIRC

6

Sadly I can’t really decide:

I want to control kodi by IR, AND I want to run irexec to do some other tasks (e.g. start/stop kodi by IR). That worked fine within buster and fails now within bullseye.

I’ve digged a little bit within bullseye’s filesystem. To my surprise there exists already the file /lib/systemd/system/irexec.service. But that one can’t work since it tries to start the not existing /usr/sbin/irexec - I guess that it is originally provided from the lirc developers. I have created my own /etc/systemd/system/irexec.service as suggested by the internet community:

[Unit]
Description=IR Remote irexec
After=eventlircd.service
Wants=eventlircd.service

[Service]
ExecStartPre=/bin/sh -c “cd /usr/var/run/lirc; rm -f lircd; ln -s /var/run/lirc/lircd”
ExecStart=/usr/bin/irexec --daemon /etc/lirc/lircrc
Type=forking

[Install]
WantedBy=multi-user.target

It automatically fixes a known bug within irexec relying on the /usr… path towards the lircd socket (still present within bullseye, I did validate that).

I see some spurious errors from lircd (but probabely not directly related to my issue):

● lircd.service - Flexible IR remote input/output application support
Loaded: loaded (/lib/systemd/system/lircd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2022-09-22 08:43:32 CEST; 46s ago
Docs: man:lircd(8)
LIRC - Linux Infrared Remote Control
Main PID: 12800 (lircd)
Tasks: 1 (limit: 975)
CPU: 84ms
CGroup: /system.slice/lircd.service
└─12800 /usr/sbin/lircd --nodaemon

Sep 22 08:43:32 imurr9 lircd[12800]: lircd-0.9.4c[12800]: Notice: /usr/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-32: Multiple values for same code: BTN_TOOL_PEN
Sep 22 08:43:32 imurr9 lircd-0.9.4c[12800]: Notice: /usr/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-32: Multiple values for same code: BTN_TOOL_PEN
Sep 22 08:43:32 imurr9 lircd[12800]: lircd-0.9.4c[12800]: Notice: /usr/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-32: Multiple values for same code: BTN_TRIGGER
Sep 22 08:43:32 imurr9 lircd-0.9.4c[12800]: Notice: /usr/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-32: Multiple values for same code: BTN_TRIGGER
Sep 22 08:43:32 imurr9 lircd[12800]: lircd-0.9.4c[12800]: Notice: /usr/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-32: Multiple values for same code: BTN_TRIGGER_HAPPY1
Sep 22 08:43:32 imurr9 lircd-0.9.4c[12800]: Notice: /usr/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-32: Multiple values for same code: BTN_TRIGGER_HAPPY1
Sep 22 08:43:32 imurr9 lircd[12800]: lircd-0.9.4c[12800]: Notice: /usr/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-32: Multiple values for same code: BTN_WHEEL
Sep 22 08:43:32 imurr9 lircd-0.9.4c[12800]: Notice: /usr/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-32: Multiple values for same code: BTN_WHEEL
Sep 22 08:43:32 imurr9 lircd[12800]: lircd-0.9.4c[12800]: Notice: lircd(devinput) ready, using /var/run/lirc/lircd
Sep 22 08:43:32 imurr9 lircd-0.9.4c[12800]: Notice: lircd(devinput) ready, using /var/run/lirc/lircd

The messages from lircd CHANGE when I fire up mediacenter. Thus I assume that as part of starting kodi the lircd/eventlircd are reconfigured being disturbed by the running irexec. Since all IR tools rely on sharing the lircd communication socket spurious errors might occur if that socket is changed unexpectedly.

Regarding your question: I’d like to run my remote kernel based and avoid ir-keytable. That should work out-of-the-box, AND it should not prevent irexec from working.

Final question: Is my observation true that kodi somehow restarts lircd? And if yes it is somehow possible to respect running irexec?

Regards, Michael

7

Sadly I’m not able to reproduce my success in using my remote to control kodi from yesterday. For testing purpose I did deactivate irexec, rebooted to clear everything, and couldn’t control kodi with my remote. Thus irexec seems NOT to be the cause of my trouble!?

Maybe that yesterday (when I could control kodi by my remote) some remnants from ir-keytable did survive? Can’t tell. But as far as I understand kodi should work out-of-the box with rc-6/mce based remotes without ir-keytable (at least for buster that was true), correct?

BTW when the remote was working yesterday, the lircd was marked dead - also very mysterious.

Regards, Michael

8

It’s me again:-) Now I wonder, why two lircd programms are running in parallel with different options. The first one is automatically started by /lib/systemd/system/lircd.service, the second one is started by the helper shell script /var/run/lirc/lircd-lirc0.sh probebly from OSMC.

From ps -guax|grep lirc I get

root 220 0.0 0.0 1888 76 ? Ss 09:42 0:00 /usr/sbin/eventlircd --evmap=/etc/eventlircd.d --socket=/var/run/lirc/lircd -f
root 321 0.0 0.2 4312 1976 ? Ss 09:42 0:00 /usr/sbin/lircd --nodaemon
root 390 0.0 0.1 4188 1048 ? Ss 09:42 0:00 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --uinput --output=/var/run/lirc/lircd-lirc0 --pidfile=/var/run/lirc/lircd-lirc0.pid /etc/lirc/lircd.conf

Is that the intended behaviour? Of course I only want to get ONE IR remote to run.

Regards, Michael

9

HEUREKA! My problem is solved!!

The reason for my problem IS the duplicate start of two lircd daemons, as guessed withim my previous post.

To resolve this problem I did disable lircd:

systemctl disable lircd

And no I can do both: controling kodi AND sending execute commands by irexec.

My suggestion to the OSMC maintanier: Inspect both system folder /etc/systemd/system and /lib/systemd/system on duplicates or old entries. I guess that for OSMC you should at least rm /lib/systemd/system/{lircd.service,irexec,service}. Bur of course, I do not know what is the “correct” location for a service.

Happy regards, Michael

10

Looks like you manually enabled the lircd service which is not the right approach.

11

Not intentionally. I’ve installed my changes w. r. t. irexec, and to activate it, I did stop lircd, started & enabled irexec.service, and started lircd. Maybe that did the wrong thing? But I never enabled lircd.service.

Nevertheless - my problem is solved, and I’m really happy with the bullseye release because it fixes my sync issue for 50fps video streams on pi3.

Regards, Michael