#291 default driver "asleep"

[Peter Pumpkin]

LIRC version" 0.9.4.c-9
IR Hardware: Microsoft Remote Control and Receiver 1.0A for Media Center PC and an Xbox One Media Remote
Output of ls -l /dev/lirc: crw-rw---- 1 root video 245, 0 Jun 9 12:59 /dev/lirc0
Output of lsmod: pastebin
Passages from journactl: pastebin
lircd's logfile and config files are attached.

Description of the problem:
I've been using LIRC with a custom config for my remote since Ubuntu 15.10, mainly used it with Kodi and irexec. After upgrading to 17.04, LIRC became unresponsive. After reading the logs and googling the issues I stumbled upon this This guy's/gal's thread documents his issues with LIRC's devinput driver after updating from Fedora 12 to 14, to be specific, the remote stopped working completely. While searching for the solution, the poster tried changing LIRC's driver to "default", which made the remote work, but only sometimes.

Switching to "default" works like this: after rebooting or a long wait period buttons oresses don't work, it seems like LIRC almost "falls asleep". It will ignore all the button presses unless you make them around 4-5 times in succession really fast (making 1 click per 2 seconds doesn't "wake it up"). After that, all the button presses get recognized without issues (until it falls asleep again). I checked this with irw. The log files all show me pressing the buttons on the remote slowly (press, wait 2 secs, press again). The IR reciever LED lights up, so it recognizes the button press. Then, after about 4-5 button presses I rapidly click the buttons and you can actually see irw recognizing the presses.

The data provided in this ticket I got from a Virtual Machine I set up to replicate the issue, because on my main machine I temporarily switched to irexec (at least I hope it's temporary, I really don't like the kernel implementation)

If there's any more data I can provide, please do tell. I'm really eager to fix this

[Peter Pumpkin]

Forgot to clarify, I provided the link the the Fedora guy because it seems he had the exact same problems: devinput driver dead, default driver is "asleep"

[Alec Leamas]

Well, following your link from 2010 and 0.8,7 (!), the first question is if this is about the kernel or lirc. Note that as of 2010, lirc contained kernel code, and Jarod was in the process to move large parts of lirc into the kernel.

Please test your setup with ir-keytable(1). If that's OK, it's about lirc; otherwise it's about the kernel.

If ir-keytable seems to work, the easiest way way is to use the devinput driver as described in http://lirc.org/html/configuration-guide.html

[Peter Pumpkin]

Thanks for your reply!

Yeah, that's the problem, as you saw in that thread, the issue was fixed kernel level, it seemed to have nothing to do with lirc, but I still thought it wouldn't hurt to attach the link, since the issue seems to be identical on the surface level.
I tried ir-keytable after LIRC stopped working for me; and ir-keytable works. Some behaviour is weird, but all the ir signals get recognized, and that's the main takeaway.

devinput driver is the thing that seemed to get broken in the first place. I used devinput, since it was the driver mentioned in lirc_options.conf by default, but now it's completely unresponsive when called using lircd --driver=devinput. devinput being broken is the reason I tried switching to the default driver and saw that it works at least half the time.

[Alec Leamas]

The devinput driver is not broken as such. If ir-keytable works, the devinput driver should also work - otherwise there is something specific for your setup.

What does ir-keytable "Some behaviour is weird" refer to ?

[Peter Pumpkin]

Directional buttons pressed more than 2 times in a row kind of "queue up", and then get registered all at once, fiddling with repeat and delay settings didn't help. Also, some button presses have a longer delay than others (that may have to do with Kodi, though, and not ir-keytable)

[Alec Leamas]

Well.all problems related to that ir-keytable doesn't work is, by definition, a kernel issue. You might want to look for help at a kernel forum for this.

That said, you might be able to get some similar, "weird" behaviour using the devinput driver and a corresponding lircd.conf (see link in previous reply).

[Peter Pumpkin]

It mentions that since 0.9.4, devinput driver is only supposed to work with remotes that are supported by the kernel, and mine is not (that's why I created a custom config).
I started using LIRC in Septermber 2015, and ran fine up until May 2017, when I updated to Zesty. May it be possible that in Zesty the Ubuntu team started "shipping" LIRC 0.9.4, where before it was an older version? I'm gasping at straws, I know, but after reading the guide again, there seems to be nothing else that would mess with my setup.

[Alec Leamas]

It mentions that since 0.9.4, devinput driver is only supposed to work with remotes that are supported by the kernel,

Indeed, that's how it is. However, this has always been the case for this driver - it's just a thin layer on top of the kernel decoding. If the devinput driver used to work, it means that the kernel was supporting the remote(s) involved

May it be possible that in Zesty the Ubuntu team started "shipping" LIRC 0.9.4, where before it was an older version?

This is exactly the situation.

and mine is not (that's why I created a custom config).

Still, you are getting data from mode2 using /dev/lirc0, which means that the setup should be --driver default --device /dev/lirc0. If this does not work, the likely reason is that lircd.conf is broken. One thing to test is to record a new one using irrecord - it isn't that complicated. As a starter, you could test just a few keys.

[Peter Pumpkin]

Thank you for your continued support!
I tried using irrecord before. Specifically as a means of testing the functionality of the default driver versus the devinput driver - with the default driver specified the binary recognized the IR signals, with devinput it gave out complete radio silence and quit itself because of that silence.
I followed your advice and tried making a new lircd.conf using this command "sudo irrecord --driver default --device /dev/lirc0" first on the VM, then on the actual machine.
In both cases I got the same broken results. First irrecord calculates the gap, and it goes okay. Then it asks me to start recording actual buttons, and the first 3-4 tries fail, the output goes like this:

Now hold down button "KEY_UP".
Something went wrong: Cannot decode data
Please try again. (28 retries left)

Then the button recording process works okay, until I "press enter to finish recording" and I get

Segmentation fault (core dumped)

These results I managed to replicate 3 times on my VM and 2 times on my machine.

irrecord dumps the unfinished config file in my home folder, and it looks functional, however, placing it as lircd.conf crashes lircd on startup, and placing it in lircd.conf.d (which is the preferred way, I suppose) does the same.

Comparing different dumped config files, you can see that the ir codes are the same between them. Well, sort of: they do have extra 4 bytes at the beginning compared to the one I used before - but I guess that's how LIRC 0.9.4. does stuff compared to 0.9.0, that was apparently used to create the cusom config I used before. Stuff like the header also differs a little bit between each one.
I attached the config file "dumped" by irrecord on my VM (well, I stitched it up from 4 different files, but still)

EDIT: I'm dumb: looked at the new config and noticed that those 4 extra bytes at the beginning are 001b, and they're mentioned in the old config as literally "pre_data_bits" - yeah, should have figured it out earlier. The numbers don't seem to match up, though. pre_data_bits says 16, but the actual data is 0x11B, so shouldn't it be 24 bits then?

EDIT 2: So I tried to remove the 16 f bytes that irrecord put after the main IR codes - they seemed to be the only changes compared to the original config, so I figured they're most likely what's causing lircd to crash on startup. Removing them makes lircd not crash and also seems to make it work. I haven't yet figured out if the issue I have is fixed (that's the driver being "asleep") but I'm going to keep testing

EDIT 3: Left the remote untouched for 15 minutes, while still using the machine (played a Steam game) and the remote "fell asleep" - tested it using irw, only triple pressing woke it up, so, basically, the new and edited lircd.conf didn't change anything (the new and unedited lircd.conf crashed lircd.conf on startup)

[Alec Leamas]

• but I guess that's how LIRC 0.9.4. does stuff compared to 0.9.0,

There are no differences in this respect between the two versions.

Segmentation fault (core dumped)

This is definitely a bug. Could you please have a look at https://sourceforge.net/p/lirc/git/ci/master/tree/CONTRIBUTE.md and produce a stacktrace as described therein?

remote "fell asleep" - tested it using irw, only triple pressing woke it up,

This might be a duplicate of [#279]

[Peter Pumpkin]

This is definitely a bug. Could you please produce a stacktrace as described therein?
I'll get on it.

This might be a duplicate of [#279]
Would it be possible for me to build the current build of 0.10 and test it out to see whether or not it actually was [#279]?

[Alec Leamas]

You are on zesty¸right? Then you could try my PPA at https://launchpad.net/~leamas-alec/+archive/ubuntu/lirc-0.10

[Peter Pumpkin]

Trying it out on my VM at the moment.
Am I correct in assuming that making a stacktrace requires you to "make" lirc from source?

[Alec Leamas]

Not really. But you need to install the debug symbol packages, as described in https://wiki.ubuntu.com/Debug%20Symbol%20Packages.

[Peter Pumpkin]

Had the machine on standby for about 20 hours to test whether or not my issue is the same as [#279] - tried it out, no dice. Only double clicking buttons "wakes" the driver up to future inputs.

[Eric Einstein]

I'm having a similar issue. Only multiple presses of the same button eventually "wake" lirc to the point where it is recognizing button presses correctly. Based on the logs (pared down and attached) it can't match to the remote unless it's in the "woken" state.Maybe something to do with the header, the pre and the pre_data settings, but I'm fairly lost about how to troubleshoot this from here.

My .conf file is downloaded from the lirc archive (attached) and was working on a previous installation on the older raspbian jessie.

lirc 0.9.4c
raspbian stretch 4.9.59-v7+

[Alec Leamas]

hm... with 0.10.1 out of the doors we need more input to make sure this bug is still with us. Anyone, out there?

[Sean Young]

I can't reproduce it, no reports since 2019 so close this issue. Please comment/reopen if there are still issues.