public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Anssi Hannula <anssi.hannula@iki.fi>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Peter Hutterer <peter.hutterer@who-t.net>,
	linux-media@vger.kernel.org,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	xorg-devel@lists.freedesktop.org
Subject: Re: IR remote control autorepeat / evdev
Date: Fri, 13 May 2011 02:48:05 +0300	[thread overview]
Message-ID: <4DCC71B5.8080306@iki.fi> (raw)
In-Reply-To: <4DCB39AF.2000807@redhat.com>

On 12.05.2011 04:36, Mauro Carvalho Chehab wrote:
> Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu:
>> Em 12-05-2011 02:37, Anssi Hannula escreveu:
> 
>>> I don't see any other places:
>>> $ git grep 'REP_PERIOD' .
>>> dvb/dvb-usb/dvb-usb-remote.c:   input_dev->rep[REP_PERIOD] =
>>> d->props.rc.legacy.rc_interval;
>>
>> Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we
>> should change it to something like 125ms, for example, as 33ms is too 
>> short, as it takes up to 114ms for a repeat event to arrive.
>>
> IMO, the enclosed patch should do a better job with repeat events, without
> needing to change rc-core/input/event logic.

It will indeed reduce the amount of ghost events so it brings us in the
right direction.

I'd still like to get rid of the ghost repeats entirely, or at least
some way for users to do it if we don't do it by default.

Maybe we could replace the kernel softrepeat with native repeats (for
those protocols/drivers that have them), while making sure that repeat
events before REP_DELAY are ignored and repeat events less than
REP_PERIOD since the previous event are ignored, so the users can still
configure them as they like?

Or maybe just a module option that causes rc-core to use native repeat
events, for those of us that want accurate repeat events without ghosting?


> -
> 
> Subject: Use a more consistent value for RC repeat period
> From: Mauro Carvalho Chehab <mchehab@redhat.com>
> 
> The default REP_PERIOD is 33 ms. This doesn't make sense for IR's,
> as, in general, an IR repeat scancode is provided at every 110/115ms,
> depending on the RC protocol. So, increase its default, to do a
> better job avoiding ghost repeat events.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> 
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index f53f9c6..ee67169 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -1044,6 +1044,13 @@ int rc_register_device(struct rc_dev *dev)
>  	 */
>  	dev->input_dev->rep[REP_DELAY] = 500;
>  
> +	/*
> +	 * As a repeat event on protocols like RC-5 and NEC take as long as
> +	 * 110/114ms, using 33ms as a repeat period is not the right thing
> +	 * to do.
> +	 */
> +	dev->input_dev->rep[REP_PERIOD] = 125;
> +
>  	path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL);
>  	printk(KERN_INFO "%s: %s as %s\n",
>  		dev_name(&dev->dev),
> 


-- 
Anssi Hannula

  parent reply	other threads:[~2011-05-12 23:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-08  4:38 IR remote control autorepeat / evdev Anssi Hannula
2011-05-10  4:11 ` Peter Hutterer
2011-05-10  5:14   ` Anssi Hannula
2011-05-10  5:30     ` Peter Hutterer
2011-05-10 13:43       ` Anssi Hannula
2011-05-11  4:46         ` Mauro Carvalho Chehab
2011-05-11 16:33           ` Anssi Hannula
2011-05-11 16:51             ` Mauro Carvalho Chehab
2011-05-11 17:59               ` Anssi Hannula
2011-05-11 20:53                 ` Dmitry Torokhov
2011-05-12  0:17                   ` Anssi Hannula
2011-05-12  0:55                     ` Mauro Carvalho Chehab
2011-05-11 23:52                 ` Mauro Carvalho Chehab
2011-05-12  0:37                   ` Anssi Hannula
2011-05-12  1:10                     ` Mauro Carvalho Chehab
2011-05-12  1:36                       ` Mauro Carvalho Chehab
2011-05-12  3:48                         ` Jarod Wilson
2011-05-12  6:05                         ` Peter Hutterer
2011-05-12 13:24                           ` Jarod Wilson
2011-05-13  7:51                           ` Mauro Carvalho Chehab
2011-05-16  1:35                             ` Peter Hutterer
2011-05-12 23:48                         ` Anssi Hannula [this message]
2011-05-13 22:39                           ` Mauro Carvalho Chehab
2011-05-13 23:07                             ` Anssi Hannula
2011-05-15  3:41                               ` Mauro Carvalho Chehab
2011-05-23 21:36                                 ` Anssi Hannula

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=4DCC71B5.8080306@iki.fi \
    --to=anssi.hannula@iki.fi \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=peter.hutterer@who-t.net \
    --cc=xorg-devel@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox