#209 Update from v0.9.3.a to v0.9.4.a renders my remote non-functional

[John A.]

Perhaps related to issue 208, upon updating a functional lirc setup on Arch x86_64 or Arch ARM for Raspberry Pi 2, my Streamzap USB remote is non-functional. Downgrading the following two pacakges followed by a restart of lircd fixes the issue:

lirc-1:0.9.3.a-2
libirman-0.4.6-1

What's even more interesting is that I can, in fact run v0.9.4a of lirc with libirman-0.5.2-1 if I use the linux-lts kernel package which ships kernel version 4.4.15. If I try using the updated packages with the main Arch linux kernel which is version 4.6.4 currently, the remote does not work.

I have my streamzap remote configured per my github readme if that helps to debug on your end.

[Alec Leamas]

No, this is probably not related to [#208]. OTOH, the kernel seems so be involved e. g., see https://bugzilla.redhat.com/show_bug.cgi?id=1260862

If possible, could you use mode2 and record one or two buttons using kernel 4.4.15 and 4.6.4 so ew can see if the kernel produces different output depending on version?

[John A.]

Using the following packages:
lirc-1:0.9.3.a-2
libirman-0.4.6-1

I just hit 'left' then 'right' for the following. Do note that Arch packages different kernel config files for the linux package (4.6.4) and the linux-lts package (4.4.15) which may or may not affect this :/

Under kernel v4.6.4:
% sudo mode2
Using device: /dev/lirc0
Using device: /dev/lirc0
Running as regular user graysky
space 16777215
pulse 896
space 896
pulse 1920
space 1664
pulse 1664
space 896
pulse 896
space 896
pulse 896
space 1920
pulse 896
space 896
pulse 1664
space 1664
pulse 1664
space 896
pulse 896
space 896
pulse 896
space 1664
pulse 896
space 16777215
space 431132
pulse 896
space 896
pulse 896
space 896
pulse 896
space 896
pulse 1664
space 896
pulse 896
space 896
pulse 896
space 1664
pulse 896
space 896
pulse 1664
space 1664
pulse 1920
space 896
pulse 896
space 1664
pulse 896
space 896
pulse 896
space 16777215

Under kernel v4.4.15:
% sudo mode2
Using device: /dev/lirc0
Using device: /dev/lirc0
Running as regular user graysky
space 11487183
pulse 896
space 896
pulse 1664
space 1664
pulse 1920
space 896
pulse 896
space 896
pulse 896
space 1664
pulse 896
space 896
pulse 1664
space 1920
pulse 1664
space 896
pulse 896
space 896
pulse 896
space 1664
pulse 896
space 16777215
space 671165
pulse 896
space 896
pulse 896
space 896
pulse 896
space 896
pulse 1664
space 896
pulse 896
space 896
pulse 896
space 1920
pulse 896
space 896
pulse 1664
space 1664
pulse 1664
space 896
pulse 896
space 1664
pulse 896
space 896
pulse 896
space 16777215

[Alec Leamas]

Comparing these side by side there seem to be two differences: The initial sync, and that some pulses which are reported as 1920 us using 4.4.15 is reported ad 1620 us using 4.4.6.

Thoughts:

• This looks like a kernel bug, since 4.4.6 obviously doesn't give the same output as 4.1.15.
• The "double spaces" bug is present. lirc tries to cope with it, but will always lose information doing so (see link above).
• Since the timings are different it might be possible to walk around the kernel bug by makinng a nerw lircd.conf using irrecord + kernel 4.4.6.

[John A.]

Yes, there are differences, but using version 0.9.3a, the same config file works with either 4.4.15 or 4.6.4... the issues only occur under 0.9.4a and as reported in #208, I am unable to record a new conf file :/

[Alec Leamas]

First: The kernel differences is IMHO a bug, and I would appreciate if you filed a issue on e. g., arch's kernel package.

Second: your installation description seems a bit odd since you don't mention lirc_options.conf. In particular, the irrecord --device /dev/lirc0 will default to use the devinput driver unless you patch lirc_options.conf. Using the devinput driver with the /dev/lirc0 device doesn't make sense. Since you have timings available, you might want to use irrecord --device /dev/lirc0 --driver default instead.

However, given that the remote is fully supported by the kernel here is another option to use the devinput driver. This might be the most straight-forward path if there is no need to send (blast) IR data. See http://lirc.org/html/configuration-guide.html Note that neither irrecord nor a specific lircd.conf file is used in this case. The devinput setup is the default one from 0.9.4.

EDIT: ALso note that the handling of config files has changed: The default setup includes all configs in /etc/lirc/lircd.conf.d; New files could just be dropped there.

[John A.]

Yes! The problem is that default options have changed in /etc/lirc/lirc_options.conf with 0.9.4a:

Old:
driver = default
device = /dev/lirc0

New:
driver = devinput
device = auto

Using the "old" values followed-up restarting lircd fixes the problem with the updated packages. Credit to dustovich in this thread for pointing it out.

Do you still think there is a kernel bug at work? If so, which component or which setting is to blame?

[Alec Leamas]

Yes! The problem is that default options have changed in /etc/lirc/lirc_options.conf with 0.9.4a:

Note that using the devinput driver might be a better and simpler alternative. But in any case the device and driver options must match, so to speak.

Do you still think there is a kernel bug at work?

yes

EDIT: The timing values (as reported by mode2) should certainly not change when updating the kernel.

If so, which component or which setting is to blame?

I guess the Arch kernel package?

[John A.]

I spoke too soon. Changing these lines in 0.9.4a causes each key press on my remote to be doubled!

[Alec Leamas]

A classic issue. You need to set the driver protocol to 'lirc' by echoing this to the proper /sys/class/rc entry. See the configuration guide (link above).

[John A.]

Alec - The default seems to be using 'lirc' yet I still get doubled keypresses about 20% of the time which is true under 4.4.15 or 4.6.4. Any thoughts are welcomed.

% cat /sys/class/rc/rc0/protocols
other unknown rc-5 nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp [lirc]

[John A.]

OK... I think I understand now.

1) Delete /etc/lirc.d/lirc.conf.d/00-streamzap.conf
2) Boot into linux-lts (4.4.15)
3) Start lircd.service

Now using 0.9.4a, the streamzap remote works without any extra configuration on my part... BUT if I reboot into the current 4.6.4 kernel, the remote does not work at all (no output from irw can be observerd).

So this is the kernel bug but I don't think Arch is the right place to do it unless you think it is something to do with the differences in the kernel config files... if the difference is due to something broken in the kernel code itself, the bug should be reported there to bugzilla for the kenrel.

So two questions:

1) Do you think this kernel bug is due to differences in the Arch config from 4.4.15 to 4.6.4 (note I have attached both to this bug report for your review).
2) If not due to config differences, which component of the kernel is broken and what debugging data can I supply to the bugzilla report?

[Alec Leamas]

No, these issues are all about how you configure lircd to use either the devinput or the default driver. Trying to sort things out:

• The default driver used in 0.9.3 is default whereas in 0.9.4 it's devinput.
• The default driver is typically used with the /dev/lirc0 device.
• The devinput driver uses a event device under /dev/input. Under 0.9.3 this must be given explicitly, 0.9.4 has an 'auto' device which uses the first available /dev/input device.
• Your last solution uses the devinput driver and the auto device available from 0.9l.4.
• The previous solution uses the default driver + the /dev/lirc0 device. This is also fine, but is more complicated (you need timings information in your config file, and make the kernel use the right protocol to avoid double keypresses).

The kernel bug is demonstrated by your mode2 logs. These shows that the timings reported from the kernel differs between the two kernel versions. Quoting myself: The initial sync differs, some pulses which are reported as 1920 us using 4.4.15 is reported ad 1620 us using 4.4.6. The mode2 output from the same remote should certainly not change when the kernel is updated. This is IMHO what should be reported.

You might want to update your configuration example by describing lirc_options.conf. To edit this is the most common task when configuring lirc, users need to know that it exists and what to put in it in this case. You might very well go for using devinput also in 0.9.3, but you then need to set the device manually as described in the configuration guide.

[Alec Leamas]

Closing bug. This is basically a configuration issue + a kernel bug found. While the kernel bug is indeed a bug id does not affect lircd, though

[John A.]

I opened this bug upstream: https://bugzilla.kernel.org/show_bug.cgi?id=135411

Thank you for the help to troubleshoot this.