if (!kbd_translate(scancode, &keycode, raw_mode))
return;
keycodes are the same for up and down. Probably later on the up/down
bit gets set. Anyway, id really doesn't matter, I tried with
keycodes, but many programs use kbd RAW mode therefore keycode
filtering (as opposed to scancode filtering) is really useless
(e.g. X).
> On the other hand 250ms is definitely too long - all keyboards I have
> here start repeating somewhat earlier than that.
Ok, we can change it to 200 ms in order to be below any PC kbd I
know.
> > 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.
Strange, it shouldn't... It enforces only the kbd delay, not the
repeat rate... Does it affect your kbd rate????
> 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.
Well, though I consider myself a quick typist, I seldom think at smth
else while I type and my fingers are a bit lazier - resting a bit more
on the keys - therefore I might not release a key after 100ms - also I
am very accustomed with the 250ms delay, I know exactly when to
release a key in this time frame so it doesn't repeat. If we put 100
ms (I tried) sometimes I get duplicates (catching one glitch after
100ms, probably releasing the key at 110 ms or smth...).
> 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.
Of course, I agree that fast key repeat is important, but is 250 ms
too long for you as kbd delay? Because it doesn't affect the kbd
rate, IMHO... Also, maybe we should make this configurable, so it
does get compiled in only for those who care - and maybe the delay
also configurable - I don't know enough about kernel configuration -
maybe smbd can help?
Andrei
-
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/