7.95.1 - lirc not working correct on rpi

**inusasha** · February 1, 2017 at 4:47 PM

Hello,

on the RPi2, the ir-reciever is not working correct.
The Key KEY_RIGHT and KEY_LEFT is not working after first try.
Under "irw /run/lirc/lircd-lirc0" all key strokes seen, but "irw /run/lirc/lircd" only the first one.
Seems a problem with eventlircd.

~~After revert of "lirc: add lircd-uinput service" (lirc: add lircd-uinput service · LibreELEC/LibreELEC.tv@2ce4f68 · GitHub) all keys are working, again~~
Edit: the working/not working keys was changed, only

Branch: libreelec-8.0 (SHA: 83ef1f2ea906ed3820edc7f366e110658c64a82f)
Hardware: RPi2 with TSOP38238 over lirc_rpi.dts
Remote: MCE compatible remote (rc6 standard)

Sascha

**milhouse** · February 2, 2017 at 11:01 AM

I'm a bit confused about what is working and not working after you revert that commit.

The following three test builds include the recent LIRC changes:

1. #1228: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) (bump to 0.9.4c)
2. #0111: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) (lirc: check for socket in lircd-uinput.service)
3. #0114: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) (lirc: fix lircd-uinput@.service)

Can you test these builds to try and determine when this problem is introduced? I'm assuming your remote is working perfectly in #1227.

HiassofT tested a GPIO receiver on RPi3 and didn't have any problems with the 0.9.4c change PR1101 that first appeared in build #1228, so are you sure this is the PR that introduces the problem?

**HiassofT** · February 2, 2017 at 6:03 PM

I just did a test with a clean install of the latest preview of the upcoming 7.95.2 version and my remote worked fine.

I've been using an RPi2, a gpio IR receiver, lirc-rpi overlay in the kernel plus a custom lircd.conf for my hauppauge remote (the default lircd.conf.rpi doesn't support that).

Please run a test when the new 7.95.2 version is out, it should be released very soon.

BTW: instead of using the lircd-rpi overlay you could also try using the gpio-ir overlay (the latter doesn't need userspace lirc but uses in-kernel decoding like most of the USB IR receivers do). To use it add the following line to config.txt (and remove the lirc-rpi overlay):

Code

dtoverlay=gpio-ir,gpio_pin=18,gpio_pull=1,rc-map-name=rc-rc6-mce

adjust the gpio_pin and gpio_pull parameters as needed (they have the same meaning as the corresponding lirc-rpi parameters), if you want to use something else than a RC6 MCE remote change the rc-map-name parameter as well (see the module files in /lib/modules/<kernelversion>/kernel/drivers/media/rc/keymaps).

so long,

Hias

**milhouse** · February 2, 2017 at 6:07 PM

HiassofT has informed me that 7.95.2 (which is due to be released real soon) is working fine on RPi3 with GPIO, so please test again with 7.95.2 (or build latest libreelec-8.0 branch)

Edit: Oh hang on, 83ef1f2ea906ed3820edc7f366e110658c64a82f - that's a fairly recent build from libreelec-8.0. If 7.95.2 is still an issue then please can you identify from the test builds I gave when this problem started.

**inusasha** · February 3, 2017 at 12:12 PM

first i tried to replace my config.txt

Code

device_tree_overlay=lirc-rpi

with Hiassofts

Code

dtoverlay=gpio-ir,gpio_pin=18,gpio_pull=1,rc-map-name=rc-rc6-mce

Both configs tested with 7.95.2 Hiassofts is working, my not...
Very confusing..

**HiassofT** · February 3, 2017 at 12:34 PM

Quote from inusasha

Both configs tested with 7.95.2 Hiassofts is working, my not...
Very confusing..

Thanks a lot for testing, and it's good to know that gpio-ir-recv is working fine!

Did you add some special customizations or config settings?

Please run a test with a clean installation of 7.95.2 and only the following line added to config.txt (keep everything else stock):

Code

dtoverlay=lirc-rpi

Then, run the following command and post the output (we should see that lircd is running and using /etc/lirc/lircd.conf.rpi):

Code

ps | grep lirc

It could well be that something's not 100% working correctly with userspace lircd. As I've tested with a different remote I can't rule out that something's wrong with the MCE remotes or lircd.conf.rpi config file. But that's just a guess,it would be great if we could narrow it down. Unfortunately I don't have an MCE remote so we'll need your help.

Or it could also be that you need to add some lirc-rpi parameters to config.txt like gpio_in_pull=up.

so long,

Hias

**inusasha** · February 3, 2017 at 12:55 PM

I test always a clean environment, before i post bugs

here the output of the ps, and additional "systemctl status"

Code

[code]
LibreELEC:~ # ps | grep lirc
  250 root       0:00 /usr/sbin/eventlircd -f --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd --release=_UP
  423 root       0:00 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --output=/run/lirc/lircd-lirc0 --pidfile=/run/lirc/lircd-lirc0.pid --release=_UP /etc/lirc/lircd.conf.rpi
  439 root       0:00 {kodi.sh} /bin/sh /usr/lib/kodi/kodi.sh --standalone -fs --lircdev /run/lirc/lircd
  443 root       0:28 /usr/lib/kodi/kodi.bin --standalone -fs --lircdev /run/lirc/lircd
  447 root       0:00 /usr/sbin/lircd-uinput /run/lirc/lircd-lirc0
  560 root       0:00 grep lirc

[/code]

Code

● LibreELEC
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 1970-01-01 00:00:04 UTC; 47 years 1 months ago
   CGroup: /
           ├─init.scope
           │ └─1 /usr/lib/systemd/systemd
           └─system.slice
             ├─nmbd.service
             │ └─433 /usr/bin/nmbd --configfile=/run/samba/smb.conf
             ├─pulseaudio.service
             │ └─278 /usr/bin/pulseaudio --system
             ├─dbus.service
             │ └─266 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
             ├─sshd.service
             │ ├─285 /usr/sbin/sshd -D
             │ ├─538 sshd: root@pts/0
             │ ├─539 -sh
             │ ├─557 systemctl status
             │ └─558 less
             ├─smbd.service
             │ └─424 /usr/bin/smbd --configfile=/run/samba/smb.conf
             ├─avahi-daemon.service
             │ └─349 avahi-daemon: running [LibreELEC.local]
             ├─kodi.service
             │ ├─439 /bin/sh /usr/lib/kodi/kodi.sh --standalone -fs --lircdev /run/lirc/lircd
             │ └─443 /usr/lib/kodi/kodi.bin --standalone -fs --lircdev /run/lirc/lircd
             ├─eventlircd.service
             │ └─250 /usr/sbin/eventlircd -f --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd --release=_UP
             ├─wpa_supplicant.service
             │ └─420 /usr/bin/wpa_supplicant -u
             ├─connman.service
             │ └─310 /usr/sbin/connmand -nr --config=/etc/connman/main.conf
             ├─rpcbind.service
             │ └─239 /usr/bin/rpcbind -f
             ├─systemd-logind.service
             │ └─277 /usr/lib/systemd/systemd-logind
             ├─cron.service
             │ └─283 /sbin/crond -f -S
             ├─systemd-udevd.service
             │ └─249 /usr/lib/systemd/systemd-udevd
             ├─system-lircd.slice
             │ ├─lircd-uinput@lirc0.service
             │ │ └─447 /usr/sbin/lircd-uinput /run/lirc/lircd-lirc0
             │ └─lircd@lirc0:default:lircd.conf.rpi.service
             │   └─423 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --output=/run/lirc/lircd-lirc0 --pidfile=/run/lirc/lircd-lirc0.pid --release=_UP /etc/lirc/lircd.conf.rpi
             └─systemd-journald.service
               └─213 /usr/lib/systemd/systemd-journald

Display More

Tests of Milhouse builds
1. #1228: http://forum.kodi.tv/showthread.php?tid=...pid2487956 (bump to 0.9.4c)
working with dtoverlay=lirc-rpi

2. #0111: http://forum.kodi.tv/showthread.php?tid=...pid2498752 (lirc: check for socket in lircd-uinput.service)
not working with dtoverlay=lirc-rpi

**HiassofT** · February 3, 2017 at 1:25 PM

Thanks for the feedback, the output you posted looks fine.

Could you run tests with the official 7.0.3 build and the milhouse builds linked in post #2? It would be good to know if it's some general problem or a regression introduced with some change.

so long,

Hias

**inusasha** · February 3, 2017 at 1:29 PM

7.0.3 is working

Tests of Milhouse builds
1. #1228: http://forum.kodi.tv/showthread.php?tid=...pid2487956 (bump to 0.9.4c)
working with dtoverlay=lirc-rpi

2. #0111: http://forum.kodi.tv/showthread.php?tid=...pid2498752 (lirc: check for socket in lircd-uinput.service)
not working with dtoverlay=lirc-rpi

**HiassofT** · February 3, 2017 at 2:14 PM

Thanks again for testing!

I'm not quite sure if the lirc socket check is actually the culprit, so could you please also test the milhouse builds in between? Do a simple bisect until you found the first build that introduces the issue (for example #0101 OK, #0102 not OK) - that should help us narrow down the exact cause.

Full list of builds with easy access is here: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)

so long,

Hias

**inusasha** · February 3, 2017 at 2:20 PM

Yeah... this is faster then build it my own

Thanks for helping,
Sascha

Edit:
MvH build #110 is working

**inusasha** · February 3, 2017 at 5:03 PM

Code

LibreELEC:~ # systemctl restart lircd-uinput@lirc0
LibreELEC:~ # irw
67 0 KEY_UP devinput
67 0 KEY_UP_UP devinput
69 0 KEY_LEFT devinput
268 0 KEY_LEFT_UP devinput
6a 0 KEY_RIGHT devinput
266 0 KEY_RIGHT_UP devinput
6c 0 KEY_DOWN devinput
6c 0 KEY_DOWN_UP devinput

The KEY_LEFT and KEY_LEFT_UP the key id is different.
But KEY_DOWN and KEY_DOWN_UP has the same key id...
Can this confuse lirc ore lirc-uinput?

PS: after restart of lircd-uinput@lirc0, i can press RIGHT and LEFT one time again...

Tested with 7.95.2

EDIT: in /usr/include/linux/input-event-codes.h is KEY_RIGHT_UP and KEY_LEFT_UP defined... may we need an other SUFFIX, then _UP?
(edit1.b: was introduced with v4.7-rc6)

Code

/* Diagonal movement keys */
#define KEY_RIGHT_UP            0x266
#define KEY_RIGHT_DOWN            0x267
#define KEY_LEFT_UP            0x268
#define KEY_LEFT_DOWN            0x269

EDIT2: quick tested with these changes

Diff

diff --git a/packages/sysutils/eventlircd/system.d/eventlircd.service b/packages/sysutils/eventlircd/system.d/eventlircd.service
index 7859753..7b920c4 100644
--- a/packages/sysutils/eventlircd/system.d/eventlircd.service
+++ b/packages/sysutils/eventlircd/system.d/eventlircd.service
@@ -2,7 +2,7 @@
 Description=Eventlirc server daemon
 
 [Service]
-ExecStart=/usr/sbin/eventlircd -f --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd --release=_UP
+ExecStart=/usr/sbin/eventlircd -f --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd --release=_UPS
 KillMode=process
 TimeoutStopSec=1s
 
diff --git a/packages/sysutils/lirc/scripts/lircd_helper b/packages/sysutils/lirc/scripts/lircd_helper
index 6895403..a6f1dc4 100755
--- a/packages/sysutils/lirc/scripts/lircd_helper
+++ b/packages/sysutils/lirc/scripts/lircd_helper
@@ -36,7 +36,7 @@ case "$ACTION" in
       LIRCD_CONFIG="--driver=$DRIVER --device=/dev/$DEVICE"
       LIRCD_CONFIG="$LIRCD_CONFIG --output=/run/lirc/lircd-$DEVICE"
       LIRCD_CONFIG="$LIRCD_CONFIG --pidfile=/run/lirc/lircd-$DEVICE.pid"
-      LIRCD_CONFIG="$LIRCD_CONFIG --release=_UP"
+      LIRCD_CONFIG="$LIRCD_CONFIG --release=_UPS"
 
       if [ -e "/storage/.config/lircd.conf" ]; then
         LIRCD_CONFIG="$LIRCD_CONFIG /storage/.config/lircd.conf"

Display More

and it seems to work. But i am not sure about side-effects

**HiassofT** · February 3, 2017 at 7:02 PM

Quote from inusasha

EDIT: in /usr/include/linux/input-event-codes.h is KEY_RIGHT_UP and KEY_LEFT_UP defined... may we need an other SUFFIX, then _UP?
(edit1.b: was introduced with v4.7-rc6)

Cool, this looks like a very possible explanation for your issues!

I'll run some tests myself and see if I can reproduce - not sure why I haven't seen any issues yet (if KEY_RIGHT_UP is now a valid event I should be able to see some odd behaviour).

I'll report back after I finished my tests (could maybe take until tomorrow or so).

so long & thanks a lot for digging into this,

Hias

**milhouse** · February 3, 2017 at 8:09 PM

inusasha can you test build #0114 as that included a fix for a lirc problem introduced in build #0111.

Edit: if you've already identified the probable issue then ignore this request!

**HiassofT** · February 3, 2017 at 9:14 PM

I ran some tests with 7.95.2 but unfortunatley couldn't reproduce the issue locally. But I have a few more things for you to try to narrow down the issue.

First of all, the --release=XXX settings of lircd and lircd-uinput have to match, otherwise we get repeating keys. lircd defaults to no release lirc event, lircd-uinput defaults to _UP.

The --release option of eventlircd can be dropped though, kodi doesn't seem to know what to do with that.

For testing, install the system tools addon (in the LibreELEC programs addon catetory), that'll give you evtest (you can also use ir-keytable to monitor input events but you need to know which input event device to monitor - evtest will display a nice list on startup you can select from).

Then, stop kodi, eventlircd, lircd and lircd-uinput: and verify they are really gone (stopping lircd via systemctl doesn't seem to work, therefore killall was needed):

Code

LibreELEC:~ # systemctl stop kodi
LibreELEC:~ # systemctl stop eventlircd
LibreELEC:~ # systemctl stop lircd-uinput@lirc0
LibreELEC:~ # systemctl stop lircd@lirc0
LibreELEC:~ # killall lircd
LibreELEC:~ # ps | grep lirc
  590 root       0:00 grep lirc

Now start lircd manually. I did this via the following command line (you need to use /etc/lirc/lircd.conf.rpi as a configuration file):

Code

LibreELEC:~ # /usr/sbin/lircd --loglevel=debug --release=_UP --nodaemon --driver=default --device=/dev/lirc0 --output=/run/lirc/lircd-lirc0 --pidfile=/run/lirc/lircd-lirc0.pid /storage/.config/lircd.conf
Warning: cannot open /etc/lirc/lirc_options.conf
lircd-0.9.4c[592]: Debug: lircd:  Opening log, level: Debug
lircd-0.9.4c[592]: Warning: Running as root
lircd-0.9.4c[592]: Info: Using remote: hauppaugeHias.
lircd-0.9.4c[592]: Notice: lircd(default) ready, using /run/lirc/lircd-lirc0

In another terminal verify that lircd is running correctly. Start irw, press a few keys and then stop irw with ctrl-c

Code

LibreELEC:~ # irw /run/lirc/lircd-lirc0
0000000000001797 00 KEY_RIGHT hauppaugeHias
0000000000001797 00 KEY_RIGHT_UP hauppaugeHias
0000000000001797 00 KEY_RIGHT hauppaugeHias
0000000000001797 00 KEY_RIGHT_UP hauppaugeHias
0000000000001797 00 KEY_RIGHT hauppaugeHias
0000000000001797 01 KEY_RIGHT hauppaugeHias
0000000000001797 02 KEY_RIGHT hauppaugeHias
0000000000001797 03 KEY_RIGHT hauppaugeHias
0000000000001797 04 KEY_RIGHT hauppaugeHias
0000000000001797 00 KEY_RIGHT_UP hauppaugeHias

Display More

The count (second value) should go up if you hold down the key and it's repeating. When releasing the key you should see a "virtual" release key with the KEYNAME_UP event (_UP as configured with --release=_UP)

If that's working fine, stop irw and run lircd-uinput. Again press some keys:

Code

LibreELEC:~ # /usr/sbin/lircd-uinput --loglevel=debug --release=_UP /run/lirc/lircd-lirc0
Warning: cannot open /etc/lirc/lirc_options.conf
lircd-0.9.4c[614]: Debug: lircd-uinput:  Opening log, level: Debug
lircd-0.9.4c[614]: Info: Reading data from /run/lirc/lircd-lirc0, writing to /dev/uinput
lircd-0.9.4c[614]: Info: Using "_UP" as release suffix
lircd-0.9.4c[614]: Debug: Sending KEY_RIGHT as 106:1
lircd-0.9.4c[614]: Debug: Sending KEY_RIGHT as 106:1
lircd-0.9.4c[614]: Debug: Sending KEY_RIGHT as 106:1
lircd-0.9.4c[614]: Debug: Sending KEY_RIGHT as 106:1
lircd-0.9.4c[614]: Debug: Sending KEY_RIGHT as 106:1
lircd-0.9.4c[614]: Debug: Sending KEY_RIGHT_UP as 106:0

Display More

Here note that event code at the end: 106:1 means keycode 106, pressed, 106:0 means released.

If the --release setting doesn't match the one from lircd lircd-uinput won't generate a input release event, resulting in endlessly repeating keys.

You can verify that using evtest. With lircd and lircd-uinput both set to _UP you should get this:

Code

LibreELEC:~ # evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      Logitech K400
/dev/input/event1:      lircd-uinput
Select the device event number [0-1]: 1
... <long info about supported events/keys snipped>
Event: time 1486155190.776951, type 20 (EV_REP), code 0 (REP_DELAY), value 1000
Event: time 1486155190.776951, type 1 (EV_KEY), code 106 (KEY_RIGHT), value 1
Event: time 1486155190.776951, -------------- SYN_REPORT ------------
Event: time 1486155191.788824, type 1 (EV_KEY), code 106 (KEY_RIGHT), value 2
Event: time 1486155191.788824, -------------- SYN_REPORT ------------
Event: time 1486155191.825485, type 1 (EV_KEY), code 106 (KEY_RIGHT), value 2
Event: time 1486155191.825485, -------------- SYN_REPORT ------------
Event: time 1486155191.862150, type 1 (EV_KEY), code 106 (KEY_RIGHT), value 2
Event: time 1486155191.862150, -------------- SYN_REPORT ------------
Event: time 1486155191.898815, type 1 (EV_KEY), code 106 (KEY_RIGHT), value 2
Event: time 1486155191.898815, -------------- SYN_REPORT ------------
Event: time 1486155191.935483, type 1 (EV_KEY), code 106 (KEY_RIGHT), value 2
Event: time 1486155191.935483, -------------- SYN_REPORT ------------
Event: time 1486155191.953290, type 1 (EV_KEY), code 106 (KEY_RIGHT), value 0
Event: time 1486155191.953290, -------------- SYN_REPORT ------------

Display More

value 1 (at the very end) means initial keypress, 2 is repeating keypress, 0 is release.

In the snipped part evtest reports all the key/eventcodes it'll handle, but doesn't show a symbolic name for keycode 614 decimal / 0x266 hex etc - evtest seems to be too old to know about these.

Doing the same test with ir-keytable instead of evtest results in this output:

Code

LibreELEC:~ # ir-keytable -d /dev/input/event1 -t
Testing events. Please, press CTRL-C to abort.
1486155236.010594: event type EV_KEY(0x01) key_down: KEY_RIGHT(0x0001)
1486155236.010594: event type EV_SYN(0x00).
1486155237.015482: event type EV_KEY(0x01) key_down: KEY_RIGHT(0x0001)
1486155237.015482: event type EV_SYN(0x00).
1486155237.052144: event type EV_KEY(0x01) key_down: KEY_RIGHT(0x0001)
1486155237.052144: event type EV_SYN(0x00).
1486155237.074032: event type EV_KEY(0x01) key_up: KEY_RIGHT(0x0001)
1486155237.074032: event type EV_SYN(0x00).

It's basically the same output like with evtest, but the press/hold/release value isn't reported.

Once we've verified that lircd-uinput is working correctly we can bring eventlircd into play. Let's do that without the --release option first:

Code

LibreELEC:~ # /usr/sbin/eventlircd -f -vvv --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd
eventlircd[648]: input device /dev/input/event1: events of unsupported event type EV_REP will be discarded
eventlircd[648]: input device /dev/input/event1: grabbed
eventlircd[648]: input device /dev/input/event1: created output event device

Now let's verify with irw that eventlircd correctly translates the input events into lirc events:

Code

LibreELEC:~ # irw /run/lirc/lircd
6a 0 KEY_RIGHT devinput
6a 1 KEY_RIGHT devinput
6a 2 KEY_RIGHT devinput
6a 3 KEY_RIGHT devinput
6a 4 KEY_RIGHT devinput
6a 5 KEY_RIGHT devinput
6a 6 KEY_RIGHT devinput
6a 7 KEY_RIGHT devinput
6a 8 KEY_RIGHT devinput
6a 0 KEY_RIGHT devinput
6a 1 KEY_RIGHT devinput
6a 2 KEY_RIGHT devinput
6a 3 KEY_RIGHT devinput
6a 4 KEY_RIGHT devinput
6a 5 KEY_RIGHT devinput
6a 6 KEY_RIGHT devinput
6a 7 KEY_RIGHT devinput
6a 8 KEY_RIGHT devinput

Display More

Here I pressed right two times for a longer period. During repeats the second value counts up, after release the next keypress with start with count 0 (here it counted from 0-8 two times).

If you start eventlircd with the --release option you should also get the "virtual" lirc up events (here I used _UP_FROM_EVENTLIRCD just to make it clear where they are coming from):

Code

LibreELEC:~ # /usr/sbin/eventlircd -f -vvv --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd --release=_UP_FROM_EVENTLIRCD
eventlircd[657]: input device /dev/input/event1: events of unsupported event type EV_REP will be discarded
eventlircd[657]: input device /dev/input/event1: grabbed
eventlircd[657]: input device /dev/input/event1: created output event device

Code

LibreELEC:~ # irw /run/lirc/lircd
6a 0 KEY_RIGHT devinput
6a 1 KEY_RIGHT devinput
6a 2 KEY_RIGHT devinput
6a 0 KEY_RIGHT_UP_FROM_EVENTLIRCD devinput

Please repeat these steps and compare the output with mine. Then repeat the test with lircd and lircd-uinput both started with --release=_FAKEUP (or something like that that's not _UP). Please post all the outputs so I can also have a closer look at them.

so long,

Hias

**inusasha** · February 3, 2017 at 9:55 PM

HiassofT: i will test tomorrow

I found another problem, which breaks some tests. When start with a new image (over img.gz), the complete remote is not working in first boot. (lircd-uinput is not running, condition file does not exist). after the second boot, all services are up and remote is working.
This is independent from the LEFT/RIGHT-key problem, but some test, i had to repeat.

Sascha

**HiassofT** · February 4, 2017 at 9:15 AM

Quote from inusasha

I found another problem, which breaks some tests. When start with a new image (over img.gz), the complete remote is not working in first boot. (lircd-uinput is not running, condition file does not exist). after the second boot, all services are up and remote is working.
This is independent from the LEFT/RIGHT-key problem, but some test, i had to repeat.

This is very interesting info - I've suspected before that the lircd systemd config is racy and could lead to such things.

If lircd-uinput is scheduled to start before lircd has created the socket the ConditionPathExist (on the socket) will fail and lircd-uinput won't start. The upstream systemd config does this differently, the socket is create via an independent systemd config (lircd.socket): LIRC / Git / [0d26f0] /systemd

Could you please try to reproduce this and when it happens grab the systemctl status of the services? the boot log would also be interesting:

Code

systemctl status lircd@lirc0
systemctl status lircd-uinput@lirc0
systemctl status eventlircd
journalctl -a | paste

It could be that we have another race between eventlircd and kodi grabbing the event input device. If kodi grabs it before eventlircd the button presses should show up as keyboard input instead of LIRC input in kodi.log and systemctl status eventlircd will contain an error message that the input device has already been grabbed by another process. So far I haven't seen this in the wild but could provoke it manually by stopping and then starting eventlircd while kodi is running.

so long,

Hias
[hr]
Please check another thing in addition to the stuff I just posted:

With lsof and grep we can quickly verify who grabbed which input device. So if there's a race between kodi and eventlircd we should be able to verify it:

First find out which event device is which physical/virtual device:

Code

LibreELEC:~ # grep . /sys/class/input/event?/device/name
/sys/class/input/event0/device/name:Logitech K400
/sys/class/input/event1/device/name:lircd-uinput
/sys/class/input/event2/device/name:eventlircd

Now run lsof to see which process is using which input device:

Code

LibreELEC:~ # lsof | grep /dev/input/event
268     /usr/sbin/eventlircd    /dev/input/event1
436     /usr/lib/kodi/kodi.bin  /dev/input/event0
436     /usr/lib/kodi/kodi.bin  /dev/input/event2

Here we see that kodi is using event0 (my logitech keyboard) and event2 (eventlircd, for receiving BTN_events) while eventlircd is reading from lircd-uinput. That's fine so far.

But if I restart eventlircd while kodi is running kodi will grab the lircd-uinput device, and eventlircd can't grab it and errors out. So eventlircd is bypassed.

Code

LibreELEC:~ # systemctl stop eventlircd
LibreELEC:~ # systemctl start eventlircd
LibreELEC:~ # lsof | grep /dev/input/event
436     /usr/lib/kodi/kodi.bin  /dev/input/event1
436     /usr/lib/kodi/kodi.bin  /dev/input/event0

And we can see eventlircd status is failed:

Code

LibreELEC:~ # systemctl status -l --no-pager eventlircd
● eventlircd.service - Eventlirc server daemon
   Loaded: loaded (/usr/lib/systemd/system/eventlircd.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sat 2017-02-04 09:43:51 UTC; 1min 21s ago
  Process: 541 ExecStart=/usr/sbin/eventlircd -f --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd --release=_UP (code=exited, status=1/FAILURE)
 Main PID: 541 (code=exited, status=1/FAILURE)


Feb 04 09:43:51 LibreELEC systemd[1]: Started Eventlirc server daemon.
Feb 04 09:43:51 LibreELEC systemd[1]: eventlircd.service: Main process exited, code=exited, status=1/FAILURE
Feb 04 09:43:51 LibreELEC systemd[1]: eventlircd.service: Unit entered failed state.
Feb 04 09:43:51 LibreELEC systemd[1]: eventlircd.service: Failed with result 'exit-code'.

Display More

Of course we shouldn't manually restart eventlircd while kodi is running as this will provoke issues - this was just to illustrate the error scenario that could happen when there's a race between eventlircd and kodi grabbing the lircd-uinput device.

so long,

Hias

**inusasha** · February 4, 2017 at 11:23 AM

Topic: no starting lircd@first boot

Code

LibreELEC:~ # systemctl status lircd@lirc0 --no-pager
● lircd@lirc0.service - Lirc with lirc0
   Loaded: loaded (/usr/lib/systemd/system/lircd@.service; disabled; vendor preset: disabled)
   Active: inactive (dead)


LibreELEC:~ # systemctl status lircd-uinput@lirc0 --no-pager
● lircd-uinput@lirc0.service - lircd-uinput with lirc0
   Loaded: loaded (/usr/lib/systemd/system/lircd-uinput@.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
Condition: start condition failed at Fri 2017-02-03 22:22:46 UTC; 12h ago
           └─ ConditionPathExists=/storage/.cache/services/lircd.conf was not met


LibreELEC:~ # systemctl status eventlircd --no-pager
● eventlircd.service - Eventlirc server daemon
   Loaded: loaded (/usr/lib/systemd/system/eventlircd.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2017-02-03 22:22:45 UTC; 12h ago
 Main PID: 260 (eventlircd)
   CGroup: /system.slice/eventlircd.service
           └─260 /usr/sbin/eventlircd -f --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd --release=_UP


Feb 03 22:22:45 LibreELEC systemd[1]: Started Eventlirc server daemon.

Display More

journalctl: gCYh

7.95.1 - lirc not working correct on rpi

Similar Threads

My MCE remote stopped working, changes to lirc?

Failed to start udev Coldplug all Devices