Comment 127 for bug 124406
Revision history for this message
| Mark Schreiber (mark7) wrote Re: Keyboard keys get stuck and repeat (Feisty, Gutsy) | #127 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
Not certain whether this is the same problem. It sounds awfully similar, except for the fact that I haven't seen my behavior "clear up" in a few seconds, as some have mentioned. With Gutsy on an Inspiron 1420 laptop, I sporadically see keys "stick" when using the built-in keyboard (I haven't tried external keyboards). Hitting another key clears up the situation immediately (which makes sense -- the internal keyboard is USB, and USB interface keyboards send the whole keyboard state on any keypress). Happens most frequently with "s" at at the end of a line in emacs, presumably since I pause in typing and allow enough time for the key repeat to kick in. I have not tried working on the Linux console to see whether it is affected as well -- it does happen in xorg. I type heavily, since I'm coding much of the day, and get this probably at least five or six times a day.
One interesting bit of information that I can add is that I ran "sudo od -x /dev/input/event1" (to dump out all events coming in from the keyboard -- your keyboard device may be different). I left this running, and managed to capture a log of a stuck "s" key occurring happening. Normally, when holding a key down, I get many of the following events generated:
0432620 6bd6 4806 a3c4 000e 0004 0004 001f 0000
0432640 6bd6 4806 a3cc 000e 0001 001f 0002 0000
0432660 6bd6 4806 a3cf 000e 0000 0000 0000 0000
Where "001f 0002" seems to indicate that the key is being held down -- these events are generated in rapid succession when the key is down. When the key is released, I get "001f 0000", and when initially pressed, I get "001f 0001". In this case, even though the "s" key was stuck down and repeating, I had *no* "001f 0002" events in the output from the event device -- just a "001f 0001" and "001f 0000" event.
I haven't yet determined whether the "001f 0000" event came in only after a subsequent keystroke or whether it was immediately generated. I'll try to catch this and provide a follow-up.
No unusual dmesg output. They internal keyboard in question has (from "sudo lsusb -v" output) an idVendor of 0x0a5c (Broadcom Corp.) and an idProduct of 0x4502.