How about a keycode sensitive repeat delay?
A short delay for vol+/-, ch+/-, etc.
A medium delay for digits, fast forward, rewind, pause, play, stop, etc.
A long delay for power, mute, etc.
Regards,
Andy
Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote:
>Em 29-08-2010 03:40, Anton Blanchard escreveu:
>>
>> I'm seeing double IR events on 2.6.36-rc2 and a DViCO FusionHDTV DVB-T Dual
>> Express. I enabled some debug and it looks like we are only getting one IR
>> event from the device as expected:
>>
>> [ 1351.032084] ir_keydown: i2c IR (FusionHDTV): key down event, key 0x0067, scancode 0x0051
>> [ 1351.281284] ir_keyup: keyup key 0x0067
>>
>> ie one key down event and one key up event 250ms later. I wonder if the input
>> layer software autorepeat is the culprit. It seems to set autorepeat to start
>> at 250ms:
>>
>> /*
>> * If delay and period are pre-set by the driver, then autorepeating
>> * is handled by the driver itself and we don't do it in input.c.
>> */
>> init_timer(&dev->timer);
>> if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD]) {
>> dev->timer.data = (long) dev;
>> dev->timer.function = input_repeat_key;
>> dev->rep[REP_DELAY] = 250;
>> dev->rep[REP_PERIOD] = 33;
>> }
>>
>> If I shorten the IR key up events to 100ms via the patch below the problem
>> goes away. I guess the other option would be to initialise REP_DELAY and
>> REP_PERIOD so the input layer autorepeat doesn't cut in at all. Thoughts?
>
>> Anton
>> --
>>
>> diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
>> index 7e82a9d..cf44d5a 100644
>> --- a/drivers/media/IR/ir-keytable.c
>> +++ b/drivers/media/IR/ir-keytable.c
>> @@ -22,7 +22,7 @@
>> #define IR_TAB_MAX_SIZE 8192
>>
>> /* FIXME: IR_KEYPRESS_TIMEOUT should be protocol specific */
>> -#define IR_KEYPRESS_TIMEOUT 250
>> +#define IR_KEYPRESS_TIMEOUT 100
>
>Yes, 250ms is too high, if we want to use REP_DELAY = 250ms.
>
>There's one issue on touching on this constant: it is currently just one global
>timeout value that will be used by all protocols. This timeout should be enough to
>retrieve and proccess the repeat key event on all protocols, and on all devices, or
>we'll need to do a per-protocol (and eventually per device) timeout init. From
>http://www.sbprojects.com/knowledge/ir/ir.htm, we see that NEC prococol uses 110 ms
>for repeat code, and we need some aditional time to wake up the decoding task. I'd
>say that anything lower than 150-180ms would risk to not decode repeat events with
>NEC.
>
>I got exactly the same problem when adding RC CORE support at the dib0700 driver. At
>that driver, there's an additional time of sending/receiving URB's from USB. So, we
>probably need a higher timeout. Even so, I tried to reduce the timeout to 200ms or 150ms
>(not sure), but it didn't work. So, I ended by just patching the dibcom driver to do
>dev->rep[REP_DELAY] = 500:
>
>commit 8dc09004978538d211ccc36b5046919489e30a55
>Author: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>
>Date: Sat Jul 31 23:37:19 2010 -0300
>
> V4L/DVB: dib0700: avoid bad repeat
>
> a 250ms delay is too low for this device. It ends by producing false
> repeat events. Increase the delay time to 500 ms to avoid troubles.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>
>
>diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c b/drivers/media/dvb/dvb-usb/dib0700_core.c
>index 164fa9c..a05d955 100644
>--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
>+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
>@@ -648,6 +648,9 @@ static int dib0700_probe(struct usb_interface *intf,
> else
> dev->props.rc.core.bulk_mode = false;
>
>+ /* Need a higher delay, to avoid wrong repeat */
>+ dev->rc_input_dev->rep[REP_DELAY] = 500;
>+
> dib0700_rc_setup(dev);
>
>Maybe the better solution is to use, by default:
> rc_input_dev->rep[REP_DELAY] = 500;
> #define IR_KEYPRESS_TIMEOUT 250
>
>And, eventually, adding a patch to allow changing it per device.
>
>That's said, IMHO, 500ms is a very reasonable time for starting repeat with remotes.
>Opinions?
>
>Cheers,
>Mauro.
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majordomo@xxxxxxxxxxxxxxx
>More majordomo info at http://vger.kernel.org/majordomo-info.html
��.n��������+%������w��{.n�����{��g����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
