linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Young <sean@mess.org>
To: "Marko Mäkelä" <marko.makela@iki.fi>
Cc: linux-media@vger.kernel.org
Subject: Re: Inconsistent RC5 ir-keytable events
Date: Thu, 13 Jan 2022 16:55:52 +0000	[thread overview]
Message-ID: <YeBZmM0ISnFGcsVa@gofer.mess.org> (raw)
In-Reply-To: <YdbVfObDZZnFIDc3@jyty>

On Thu, Jan 06, 2022 at 01:41:48PM +0200, Marko Mäkelä wrote:
> Wed, Jan 05, 2022 at 09:53:55AM +0000, Sean Young wrote:
> > On Tue, Jan 04, 2022 at 06:07:06PM +0200, Marko Mäkelä wrote:
> > > I tested once more the stock driver (value=200) with the NEC
> > > protocol.  The GNOME volume control would only react to the initial
> > > press of the button, not on the repeats. Also in ir-keytable -t, I
> > > only see one key_down/key_up followed by LIRC-only messages:
> > > 
> > > 2776.698529: lirc protocol(nec): scancode = 0x1e
> > > 2776.698539: event type EV_MSC(0x04): scancode = 0x1e
> > > 2776.698539: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
> > > 2776.698539: event type EV_SYN(0x00).
> > > 2776.824077: event type EV_KEY(0x01) key_up: KEY_VOLUMEUP(0x0073)
> > > 2776.824077: event type EV_SYN(0x00).
> > > 2776.909965: lirc protocol(nec): scancode = 0x1e repeat
> > > 2776.909973: event type EV_MSC(0x04): scancode = 0x1e
> > > 2776.909973: event type EV_SYN(0x00).
> > > 2777.121976: lirc protocol(nec): scancode = 0x1e repeat
> > > 2777.121983: event type EV_MSC(0x04): scancode = 0x1e
> > > 2777.121983: event type EV_SYN(0x00).
> > 
> > Here the is such a delay between the the first message and the repeat,
> > that rc-core does not honour the repeat any more.
> 
> I repeated the experiment with a stock Debian 5.15.0-2-amd64 kernel (based
> on 5.15.5). First, I checked the RCU with a digital camera.  Because the
> blinking of the IR LED appeared a little erratic, I replaced the CR2025 cell
> (voltage=3.25V) with a better one (voltage=3.3V). It got brighter and better
> in the digital viewfinder, but there was no improvement for ir-keytable -t:
> 
> Testing events. Please, press CTRL-C to abort.
> 25559.898935: lirc protocol(nec): scancode = 0x1e
> 25559.898948: event type EV_MSC(0x04): scancode = 0x1e
> 25559.898948: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
> 25559.898948: event type EV_SYN(0x00).
> 25560.024055: event type EV_KEY(0x01) key_up: KEY_VOLUMEUP(0x0073)
> 25560.024055: event type EV_SYN(0x00).
> 25560.110134: lirc protocol(nec): scancode = 0x1e repeat
> 25560.110141: event type EV_MSC(0x04): scancode = 0x1e
> 25560.110141: event type EV_SYN(0x00).
> 25560.322180: lirc protocol(nec): scancode = 0x1e repeat
> 25560.322188: event type EV_MSC(0x04): scancode = 0x1e
> 25560.322188: event type EV_SYN(0x00).
> 25560.534173: lirc protocol(nec): scancode = 0x1e repeat
> 25560.534180: event type EV_MSC(0x04): scancode = 0x1e
> 25560.534180: event type EV_SYN(0x00).
> 25560.746156: lirc protocol(nec): scancode = 0x1e repeat
> 25560.746163: event type EV_MSC(0x04): scancode = 0x1e
> 25560.746163: event type EV_SYN(0x00).
> 25560.958173: lirc protocol(nec): scancode = 0x1e repeat
> 25560.958181: event type EV_MSC(0x04): scancode = 0x1e
> 25560.958181: event type EV_SYN(0x00).
> 25997.954229: lirc protocol(nec): scancode = 0x1e repeat
> 25997.954241: event type EV_MSC(0x04): scancode = 0x1e
> 25997.954241: event type EV_SYN(0x00).
> 25998.166182: lirc protocol(nec): scancode = 0x1e repeat
> 25998.166189: event type EV_MSC(0x04): scancode = 0x1e
> 25998.166189: event type EV_SYN(0x00).

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!).

Thanks

Sean
---
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

This device presents an IR buffer, which can be read and cleared.
Clearing the buffer is racey with receiving IR, so wait until the IR
message is finished before clearing it.

This should minimize the chance of the buffer clear happening while
IR is being received, although we cannot avoid this completely.

Signed-off-by: Sean Young <sean@mess.org>
---
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 26 ++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 795a012d4020..f6fc362573d0 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1720,6 +1720,7 @@ static int rtl2832u_rc_query(struct dvb_usb_device *d)
 		{IR_RX_BUF_CTRL,         0x80, 0xff},
 		{IR_RX_CTRL,             0x80, 0xff},
 	};
+	u32 idle_length;
 
 	/* init remote controller */
 	if (!dev->rc_active) {
@@ -1770,6 +1771,22 @@ static int rtl2832u_rc_query(struct dvb_usb_device *d)
 	if (ret)
 		goto err;
 
+	dev_dbg(&d->intf->dev, "IR_RX_BUF=%*ph\n", len, buf);
+
+	/* if the receiver is not idle yet, do not process */
+	idle_length = 0;
+	if (len > 2) {
+		if (!(buf[len - 1] & 0x80))
+			idle_length += buf[len - 1] & 0x7f;
+		if (!(buf[len - 2] & 0x80))
+			idle_length += buf[len - 2] & 0x7f;
+	}
+
+	dev_dbg(&d->intf->dev, "idle_length=%x\n", idle_length);
+
+	if (idle_length < 0xbf)
+		return 0;
+
 	/* let hw receive new code */
 	for (i = 0; i < ARRAY_SIZE(refresh_tab); i++) {
 		ret = rtl28xxu_wr_reg_mask(d, refresh_tab[i].reg,
@@ -1807,9 +1824,12 @@ static int rtl2832u_get_rc_config(struct dvb_usb_device *d,
 	rc->allowed_protos = RC_PROTO_BIT_ALL_IR_DECODER;
 	rc->driver_type = RC_DRIVER_IR_RAW;
 	rc->query = rtl2832u_rc_query;
-	rc->interval = 200;
-	/* we program idle len to 0xc0, set timeout to one less */
-	rc->timeout = 0xbf * 51;
+	rc->interval = 50;
+	/*
+	 * The idle len is set to 0xc0, set timeout to one less plus
+	 * the query interval with some extra margin for error
+	 */
+	rc->timeout = 0xbf * 51 + MS_TO_US(60);
 
 	return 0;
 }
-- 
2.34.1


  reply	other threads:[~2022-01-13 16:55 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 [this message]
2022-01-14  6:31                 ` Marko Mäkelä
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=YeBZmM0ISnFGcsVa@gofer.mess.org \
    --to=sean@mess.org \
    --cc=linux-media@vger.kernel.org \
    --cc=marko.makela@iki.fi \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).