IR remote control autorepeat / evdev

[Anssi Hannula]

On 14.05.2011 01:39, Mauro Carvalho Chehab wrote:
> Em 13-05-2011 01:48, Anssi Hannula escreveu:
>> 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? 
>>
> 
> This doesn't seem to be the right thing to do. If the kernel will
> accept 33 ms as the value or REP_PERIOD, but it will internally 
> set the maximum repeat rate is 115 ms (no matter what logic it would
> use for that), Kernel (or X) shouldn't allow the user to set a smaller value. 
> 
> The thing is that writing a logic to block a small value is not easy, since 
> the max value is protocol-dependent (worse than that, on some cases, it is 
> device-specific). It seems better to add a warning at the userspace tools 
> that delays lower than 115 ms can produce ghost events on IR's.