When you press a shift (ctrl, alt, shift) and a key - *sometimes* the
controller ignores the repeat delay and repeats the key, sending very
close (tens of miliseconds) key_down interrups (kbd MAKEs). In other
words, *sometimes* when I briefly press 'Ctrl-C' and get a bunch (4-5)
of them...
I saw this by logging scancodes from the handle_scancode function. A
log of (jiffies, scancode) with kbd rate 30 cps, delay 250 ms was:
18, 54 (that's a shift pressed)
22, 54 (normal repeat of the shift, at 30 cps)
25, 54 (normal repeat of the shift, at 30 cps)
28, 25 (that's a key pressed while shift still pressed)
29, 25 (**this is the problem: there should have been 250 ms between
the prev interrupt and this one!!)
32, 25 (this is ok, repeating at 30 cps)
35, 182 (this is the shift released)
36, 25 (this is a second repeat of the key, normal)
37, 153 (the key released)
I hope you can see the problem right now. I think it depends a lot
when you press the key wrt to the shift repeat period: for instance,
in the prev example it was pressed at jiffies==28, and at jiffies==29
the shift key would have been repeated, normally - but instead is
repeated the key... Well, strange.
My fix (included in the orig msg) sets up a delay of 200 ms (20
jiffies) after each new scancode received, and ignores a same scancode
in this period. If another scancode appears in this time window - it
resets the counter - well, trivial fix... Since this does not break
anything, IMO, I would be very happy if smbd would put it in the
kernel, at least configurable somehow...
Thanks
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/