> > Note that scancode repeat is not good enough: many keys produce an e0 xx pair
> > and repeat that; more complicated things also occur.
> Of course this is covered, please have a look at the patch.
Yes, I saw this patch later. Linux-kernel arrived out-of-order here yesterday.
> > So, you could consider intercepting repetition at the keycode
> > instead of the scancode level.
> At the keycode level I cannot make the difference between key down and
> key up. I rely on both keydowns and ups in my patch.
Of course you have key down and key up at the keycode level.
value < 128 is key down, value+128 is key up.
> > Probably 100ms would suffice. It seems that the key up event comes
> > much earlier.
> No problem, that is a different keycode, therefore it will pass.
You misunderstand my argument. It is not that I expressed concern
about the key-up event. Just the opposite - I was happy to notice
that the key up event has occurred already after 100ms, so your
repetition test has already changed last_keycode after 100 ms,
so a longer period is only required for people who are both very
slow typists and have a broken Toshiba keyboard.
On the other hand 250ms is definitely too long - all keyboards I have
here start repeating somewhat earlier than that.
> Only 250 ms is ok. It only applies _between the first and the second
> identical scancode in a row_. It doesn't affect anything else.
It kills the key repeat on my keyboard.
> 100 ms _does not help anybody_ because when a glitch occurs, it is not
> single shot, but repetitive, and fast - therefore you will end up with
> duplicates.
I don't understand your argument.
Your constraints are the following:
1. You want a time period that is as long as possible, in order to catch
as many glitches as possible.
2. The time period must not be longer than the ordinary key repeat delay.
3. The time period need not be longer than the time until the next key-up
in normal typing. For me that is much less than 100 ms, but other people
may have different opinions.
Now fast key repeat is important - especially for backspace and arrow keys -
it would be a bad idea to kill a little bit of the Linux pleasure just
because of some obscure Toshiba bug. So 250 ms is definitely too long.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/