From: "Marko Mäkelä" <marko.makela@iki.fi>
To: Sean Young <sean@mess.org>
Cc: linux-media@vger.kernel.org
Subject: Re: Inconsistent RC5 ir-keytable events
Date: Fri, 14 Jan 2022 08:31:35 +0200 [thread overview]
Message-ID: <YeEYxwUkCV7rSa0A@jyty> (raw)
In-Reply-To: <YeBZmM0ISnFGcsVa@gofer.mess.org>
Thu, Jan 13, 2022 at 04:55:52PM +0000, Sean Young wrote:
>So I had to dig around for a while, but I have the same device here.
>After some experimenting I've written a patch. Please could test it out
>for me, a `Tested-by:` would be appreciated (if it works of course!).
It is significantly better for the bundled remote control unit (using
the NEC protocol). But it can still lose events. I tested by holding
down the VOL+ and VOL- keys. Also the GNOME Desktop was listening to
those events, so I got some additional visual feedback.
Here is a trace from ir-keytable -t, using the NEC protocol:
Testing events. Please, press CTRL-C to abort.
261.125938: lirc protocol(nec): scancode = 0x1e
261.125959: event type EV_MSC(0x04): scancode = 0x1e
261.125959: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
261.125959: event type EV_SYN(0x00).
261.189926: lirc protocol(nec): scancode = 0x1e repeat
261.189939: event type EV_MSC(0x04): scancode = 0x1e
261.189939: event type EV_SYN(0x00).
261.309891: lirc protocol(nec): scancode = 0x1e repeat
261.309905: event type EV_MSC(0x04): scancode = 0x1e
261.309905: event type EV_SYN(0x00).
261.429960: lirc protocol(nec): scancode = 0x1e repeat
261.429973: event type EV_MSC(0x04): scancode = 0x1e
261.429973: event type EV_SYN(0x00).
261.553908: lirc protocol(nec): scancode = 0x1e repeat
261.553923: event type EV_MSC(0x04): scancode = 0x1e
261.553923: event type EV_SYN(0x00).
261.617911: lirc protocol(nec): scancode = 0x1e repeat
261.617924: event type EV_MSC(0x04): scancode = 0x1e
261.617924: event type EV_SYN(0x00).
261.628041: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
261.628041: event type EV_SYN(0x00).
261.737970: lirc protocol(nec): scancode = 0x1e repeat
261.628041: event type EV_MSC(0x04): scancode = 0x1e
261.628041: event type EV_SYN(0x00).
261.760048: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
261.760048: event type EV_SYN(0x00).
261.857958: lirc protocol(nec): scancode = 0x1e repeat
261.760048: event type EV_MSC(0x04): scancode = 0x1e
261.760048: event type EV_SYN(0x00).
261.892056: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
261.892056: event type EV_SYN(0x00).
So far, so good. The initial delay between the key_down events is 500ms.
But, keep reading:
262.024055: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
262.024055: event type EV_SYN(0x00).
262.045960: lirc protocol(nec): scancode = 0x1e repeat
262.024055: event type EV_MSC(0x04): scancode = 0x1e
262.024055: event type EV_SYN(0x00).
262.156052: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
262.156052: event type EV_SYN(0x00).
262.156052: event type EV_KEY(0x01) key_up: KEY_VOLUMEUP(0x0073)
262.156052: event type EV_SYN(0x00).
264.074505: lirc protocol(nec): scancode = 0x1e repeat
264.074524: event type EV_MSC(0x04): scancode = 0x1e
264.074524: event type EV_SYN(0x00).
264.137961: lirc protocol(nec): scancode = 0xa
264.137979: event type EV_MSC(0x04): scancode = 0x0a
264.137979: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
264.137979: event type EV_SYN(0x00).
264.324062: event type EV_KEY(0x01) key_up: KEY_VOLUMEDOWN(0x0072)
264.324062: event type EV_SYN(0x00).
264.325944: lirc protocol(nec): scancode = 0xa repeat
264.325960: event type EV_MSC(0x04): scancode = 0x0a
264.325960: event type EV_SYN(0x00).
264.445972: lirc protocol(nec): scancode = 0xa repeat
264.445988: event type EV_MSC(0x04): scancode = 0x0a
264.445988: event type EV_SYN(0x00).
264.565937: lirc protocol(nec): scancode = 0xa repeat
264.565952: event type EV_MSC(0x04): scancode = 0x0a
[snip]
266.585974: lirc protocol(nec): scancode = 0xa repeat
266.585989: event type EV_MSC(0x04): scancode = 0x0a
266.585989: event type EV_SYN(0x00).
267.270556: lirc protocol(nec): scancode = 0xa repeat
267.270571: event type EV_MSC(0x04): scancode = 0x0a
267.270571: event type EV_SYN(0x00).
267.389958: lirc protocol(nec): scancode = 0xa
267.389976: event type EV_MSC(0x04): scancode = 0x0a
267.389976: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
267.389976: event type EV_SYN(0x00).
267.509941: lirc protocol(nec): scancode = 0xa repeat
267.509957: event type EV_MSC(0x04): scancode = 0x0a
267.509957: event type EV_SYN(0x00).
267.629971: lirc protocol(nec): scancode = 0xa repeat
267.629986: event type EV_MSC(0x04): scancode = 0x0a
267.629986: event type EV_SYN(0x00).
267.749948: lirc protocol(nec): scancode = 0xa repeat
267.749963: event type EV_MSC(0x04): scancode = 0x0a
267.749963: event type EV_SYN(0x00).
267.873963: lirc protocol(nec): scancode = 0xa repeat
267.873978: event type EV_MSC(0x04): scancode = 0x0a
267.873978: event type EV_SYN(0x00).
267.900054: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
267.900054: event type EV_SYN(0x00).
267.937934: lirc protocol(nec): scancode = 0xa repeat
267.900054: event type EV_MSC(0x04): scancode = 0x0a
267.900054: event type EV_SYN(0x00).
268.032044: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
268.032044: event type EV_SYN(0x00).
Why was there a key_up event at 264.324062 even though I continued to
hold down that button? Maybe shortly before another key_down was finally
generated, I had let the button go and pressed it again.
All in all, I long-pressed VOL+, VOL-, VOL+, VOL-, and only for the
second press (VOL-) I failed to get proper repeat events. So, it almost
works. For comparison, I used the stock kernel module, which never
generated repeat events for the NEC protocol.
Then, I loaded the hauppauge.toml and tested with RC5. It was fairly OK,
except for an anomaly: When I pressed Vol- or Vol+ after just having
long-pressed the other key, I got one more event for the previous key!
Here is a trace of that:
1471.642128: event type EV_MSC(0x04): scancode = 0x1e10
1471.642128: event type EV_SYN(0x00).
1471.676071: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
1471.676071: event type EV_SYN(0x00).
1471.808059: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
1471.808059: event type EV_SYN(0x00).
1471.808059: event type EV_KEY(0x01) key_up: KEY_VOLUMEUP(0x0073)
1471.808059: event type EV_SYN(0x00).
1472.266096: lirc protocol(rc5): scancode = 0x1e10 toggle=1
1472.266113: event type EV_MSC(0x04): scancode = 0x1e10
1472.266113: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
1472.266113: event type EV_SYN(0x00).
1472.386062: lirc protocol(rc5): scancode = 0x1e11
1472.386079: event type EV_KEY(0x01) key_up: KEY_VOLUMEUP(0x0073)
1472.386079: event type EV_MSC(0x04): scancode = 0x1e11
1472.386079: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
1472.386079: event type EV_SYN(0x00).
1472.450104: lirc protocol(rc5): scancode = 0x1e11
1472.450118: event type EV_MSC(0x04): scancode = 0x1e11
1472.450118: event type EV_SYN(0x00).
1472.570090: lirc protocol(rc5): scancode = 0x1e11
1472.570105: event type EV_MSC(0x04): scancode = 0x1e11
1472.570105: event type EV_SYN(0x00).
1472.760061: event type EV_KEY(0x01) key_up: KEY_VOLUMEDOWN(0x0072)
1472.760061: event type EV_SYN(0x00).
The events between 1472.266096 and 1472.386079 are fake. I only pressed
and released Vol+ once. Once I started to press Vol- I got fake key_down
and key_up for KEY_VOLUMEUP instead of getting the initial message for
KEY_VOLUMEDOWN.
I tried this also with short presses, pressing Vol- and Vol+
alternatively. Almost all of the time, the GNOME volume control widget
reacted by getting exactly the wrong event (from the previous key
press).
>From f860a05c35a7b0e7b331e61e1b61674c2a9279f0 Mon Sep 17 00:00:00 2001
>From: Sean Young <sean@mess.org>
>Date: Thu, 13 Jan 2022 16:33:13 +0000
>Subject: [PATCH] media: rtl28xxu: improve IR receiver
In my opinion, this patch is a significant improvement for decoding the
NEC protocol, as well as for the RC5 protocol, because for that one it
no longer sends key_up events before each repeated key_down event for a
held-down button.
But, for the RC5 decoder, there appears to be a serious regression that
instead of sending the event for the last received message, it will
repeat an event for the previously pressed button.
Best regards,
Marko
next prev parent reply other threads:[~2022-01-14 6:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <YdKdPosyzj2urFpS@jyty>
2022-01-03 9:21 ` Inconsistent RC5 ir-keytable events Sean Young
2022-01-03 10:35 ` Marko Mäkelä
2022-01-03 11:07 ` Sean Young
2022-01-03 12:21 ` Marko Mäkelä
2022-01-04 16:07 ` Marko Mäkelä
2022-01-05 9:53 ` Sean Young
2022-01-06 11:41 ` Marko Mäkelä
2022-01-13 16:55 ` Sean Young
2022-01-14 6:31 ` Marko Mäkelä [this message]
2022-01-29 17:15 ` Marko Mäkelä
2022-02-08 16:46 ` Sean Young
2022-02-09 8:12 ` Marko Mäkelä
2022-02-12 11:16 ` Sean Young
2022-02-12 16:34 ` Sean Young
2022-02-13 17:12 ` Marko Mäkelä
2022-03-26 18:44 ` Marko Mäkelä
2022-04-10 14:07 ` Marko Mäkelä
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YeEYxwUkCV7rSa0A@jyty \
--to=marko.makela@iki.fi \
--cc=linux-media@vger.kernel.org \
--cc=sean@mess.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.