IR remote control autorepeat / evdev

[Peter Hutterer]

On Fri, May 13, 2011 at 09:51:02AM +0200, Mauro Carvalho Chehab wrote:
> Em 12-05-2011 08:05, Peter Hutterer escreveu:
> > On Thu, May 12, 2011 at 03:36:47AM +0200, 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.
> >>
> >> -
> >>
> >> Subject: Use a more consistent value for RC repeat period
> >> From: Mauro Carvalho Chehab <mchehab at 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 at 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),
> > 
> > so if I get this right, a XkbSetControls(.. XkbRepeatKeysMask ...) by a
> > client to set the repeat rate would provide the same solution - for those
> > clients/devices affected. 
> 
> Yes, if we preserve the same logic. The above will probably still generate
> ghost repeats if the user keeps the IR pressed for a long time, as we're using
> a separate timer at the rc-core logic than the one used inside evdev.
> 
> > The interesting question is how clients would identify the devices that are
> > affected by this (other than trial and error).
> 
> That is easy. I've added a logic that detects it on Xorg evdev on some RFC patches
> I've prepared in the past to allow using a keycode with more than 247 for IR's.
> I'll work on a new version for it and submit again when I have some time.
> Anyway, I'm enclosing a patch with the old version. 

Note that "clients" refers to X clients, i.e. applications. While it's
usually trivial to add new functionality to evdev or other drivers, exposing
information to the actual client requires some protocol extension or
additions to existing extensions. While we have mechanisms in place for
devices to be labelled, we don't have anyone to actually read this
information (or even some standard on how to apply the labels).