#148 Remote has become too sensitive upon updating to lirc-0.9.3

[John A.]

Upon updating to version 0.9.3, my streamzap remote[1] has become too sensitive. A key press is often echoed twice to applications such as Kodi. Under previous versions (e.g. 0.9.2a and below) it worked flawlessly. I attached my remote config file for reference.

1. http://www.streamzap.com/consumer/pc_remote/index.php

[student975]

See also:

https://bugs.archlinux.org/task/46457
https://bugs.archlinux.org/task/46550

[John A.]

I never attempted a bisect before but did so just now.
What I think is true:
tag = lirc-0_9_2a is good
tag = lirc-0_9_3pre3 is bad

Here is the bisect log with me building and running lircd via the attached "build" script directly in the git repo and testing in Kodi which I would start after lircd began to run:

% git bisect start

% git bisect good lirc-0_9_2a

% git bisect bad lirc-0_9_3pre3
Bisecting: 136 revisions left to test after this (roughly 7 steps)
[4ebae71cb8517b906ad676bf81eda22a0aed8fbe] daemons: Formatted.

% git bisect good
Bisecting: 68 revisions left to test after this (roughly 6 steps)
[5a7e6618cb5f6fd05c5dbf1503733b7f63241352] lirc-lsplugins: Display log after parsing file(s).

% git bisect good
Bisecting: 34 revisions left to test after this (roughly 5 steps)
[91aa31c87d4a0fcc2b92d9aa2307a92d1ff09dd6] doc: index: Clean up manpage TOC, add programs overview.

% git bisect good
Bisecting: 17 revisions left to test after this (roughly 4 steps)
[9aaffcae5cbc4135eccdb67ab1fa73f079b86067] build: Let configure die without suitbale python (#112)

% git bisect good
Bisecting: 8 revisions left to test after this (roughly 3 steps)
[6b799dbe89bb47bb3ba35545ac3529b06733cadc] irrecord-ui: More user feedback, formatting.

% git bisect good
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[7c68069f6c35ffb78e39f58e24084850d5bf9949] lircd: Set supplementary groups (RH bz 1253907).

% git bisect bad
Bisecting: 1 revision left to test after this (roughly 1 step)
[b59b88e79c2ae62ca8f2e1766a50678de5e3c4e7] plugins: default: Work around kernel bug (#119).

% git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[2d468b78b6659db6b78b66c44901e4ab86133011] tools: pronto2lirc: Fix stoneage python syntax (#118).

% git bisect good
b59b88e79c2ae62ca8f2e1766a50678de5e3c4e7 is the first bad commit
commit b59b88e79c2ae62ca8f2e1766a50678de5e3c4e7
Author: Alec Leamas <leamas.alec@gmail.com>
Date:   Sun Aug 16 09:21:50 2015 +0200

    plugins: default: Work around kernel bug (#119).

        :040000 040000 7593a67b6d8b2206943fd4807f409e1cc89d31d9 85e18e31f94266dd83b4ac38fbfeeaea52467515 M  plugins

[Alec Leamas]

Thanks for excellent bug-hunting! I think I understand what's going on here.

As downstream, it should be safe to just revert this commit as long as you work on an updated kernel. The work-around is required for "early" versions of the 4.1 line, but the underlying kernel problem is fixed (havn't checkad exactly at which point). Fedora is as of now on 4.1.6 which has solved the problem.

As upstream, it's more complicated...

[John A.]

From the git log it seems that I cannot find the commit that my bisect found which is "b59b88e79c2ae62ca8f2e1766a50678de5e3c4e7" per my output above.

Now if I search for "Work around kernel bug (#119)" in the git log it comes back to "219b01d0fc34bc0e3fd39075375045f032dcca19" in the git repo.

How can I generate a patch reverting just this commit against the proper 0.9.3 release?

[Jon]

I'm having this issue also (seeing keypresses twice) but I'm getting a different commit from git bisect: 7dca803fc6b6b7090d057194f2828c21e186dfd6 (from the release-0_9_3 branch)

Could it be a separate issue on my end? Should I report it as a separate ticket?

[Alec Leamas]

Hm, yes please. File another ticket for it!

[John A.]

Two things:

1) How can I use git to generate a single patch reverting just that commit? I used the gitweb and saw that only one first was changed (plugins/default.c) so I just extracted the 0.9.3 tarball to "a" and then copied it to "b" and edited b/plugins/default.c to what it was before that commit manually. Then I created the attached patch with "diff -uprN a/plugins/default.c b/plugins/default.c"

Applying that patch against the the 0.9.3 source and building seems to have solved the problem. I will communicate this to the Arch packagers.

2) Since you said 4.1.6+ should be fine without the workaround we [Arch] could simply include this patch for our packages since the current lts kernel for Arch is 4.1.10 and the standard one is 4.2.3 (as I write this).

[Alec Leamas]

1) How can I use git to generate a single patch reverting just that commit?

git revert fa1afe1
git format-patch HEAD^..HEAD

2) Since you said 4.1.6+ should be fine without the workaround
we [Arch] could simply include this patch for our packages since
the current lts kernel for Arch is 4.1.9 and the standard one> 4.2.3 (as I write this).

Yes

BTW: Have you noticed the other post-release patches in the release-0_9_3 branch?

[John A.]

Not sure about post-release patches... I only dug into this due to bug affecting my stuff :)

[John A.]

...if the problem is affecting a now unsupported version of the kernel, perhaps the code should be removed upstream (here with you) leaving the non-standard solution, ie the patch, to those running a deprecated version of the kernel. I think that would inconvenience less distros/packagers in the long term, no?

[Alec Leamas]

Indeed. That's my own thinking as well. Thanks for input, it certainly helps. However, short of time right now.

[John A.]

@Alec - OK!

[Alec Leamas]

Fixed in [d9ade8], basically reverting the broken fix. This makes lirc incompatible with at least the 4.04 kernel.

[Alec Leamas]

Fix backported to 0.9.3a in [b5fe80]