Ubuntu
linux-ports-meta package

[Hardy] Caps Lock causes keys to repeat

Bug #213669 reported by Harvey Muller on 2008年04月07日

This bug affects 3 people

Affects		Status	Importance	Assigned to	Milestone
linux-ports-meta (Ubuntu)	Invalid	Undecided	Unassigned

Bug Description

Binary package hint: xserver-xorg

Problem:

Entering [Caps Lock] and then any other character causes the second key to be repeated continually, until the [Caps Lock] key is hit again. I discovered this problem after learning to use emacs, and subsequently switching the [Caps Lock] and [Ctrl] keys. This error occurs in any text editor, the command line, or any form field that accepts input.

To reproduce:

It doesn't occur in every instance, but can reliably be reproduced within 20 - 25 tests. To test, either open a terminal or any editor, and then depress the [Caps Lock] key immediately followed by a character. I used the 's' and 'x' keys, as these are the two that commonly reproduce the error using emacs with the [Caps Lock] and [Ctrl] keys swapped. Once the key starts repeating, you can halt it by hitting the [Caps Lock] key again.

Research:

I restarted the machine and booted to a root console, without X. I could not reproduce the error in an environment without X. I then started X by running xinit, and was able to reproduce the error. This is how I generally isolated it to X. I do not know how to isolate it further.

This may remotely be related to Bug #74006 Cap lock key stuck in cap lock - https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/74006

Tags:

Revision history for this message

Harvey Muller (hlmuller) wrote on 2008年04月11日: Re: [Bug 213669] Re: [Hardy] Caps Lock causes keys to repeat #1

Greetings Timo,

After reading through the lengthy bug you have marked this a duplicate of (124406), I have a question.

Although there is a chance they may be related, the symptoms experienced in Bug 213669 are not reported in the bug you have tied this to. I am not experiencing any of the other issues and cannot reproduce them, only the Caps Lock key causes repeats, which can be halted by hitting the Caps Lock key.

I understand however that linking 213669 to 124406 may be a method to tie all like issues together for resolution. Is this the case?

If so, I'll start watching bug 124406, if not I respectfully request that bug 213669 be unlinked from 124406.

Best regards,

Harvey

----- Original Message ----
> From: Timo Aaltonen <email address hidden>
> To: <email address hidden>
> Sent: Friday, April 11, 2008 4:00:44 AM
> Subject: [Bug 213669] Re: [Hardy] Caps Lock causes keys to repeat
>
> *** This bug is a duplicate of bug 124406 ***
> https://bugs.launchpad.net/bugs/124406
>
> ** This bug has been marked a duplicate of bug 124406
> Keyboard keys get stuck and repeat (Feisty, Gutsy)
>
> --
> [Hardy] Caps Lock causes keys to repeat
> https://bugs.launchpad.net/bugs/213669
> You received this bug notification because you are a direct subscriber
> of the
> bug.

Greetings Timo,
After reading through the lengthy bug you have marked this a duplicate of (124406), I have a question.
Although there is a chance they may be related, the symptoms experienced in Bug 213669 are not reported in the bug you have tied this to. I am not experiencing any of the other issues and cannot reproduce them, only the Caps Lock key causes repeats, which can be halted by hitting the Caps Lock key.
I understand however that linking 213669 to 124406 may be a method to tie all like issues together for resolution. Is this the case?
If so, I'll start watching bug 124406, if not I respectfully request that bug 213669 be unlinked from 124406.
Best regards,
Harvey
----- Original Message ----
> From: Timo Aaltonen <tepsipakki@ubuntu.com>
> To: hlmuller@yahoo.com
> Sent: Friday, April 11, 2008 4:00:44 AM
> Subject: [Bug 213669] Re: [Hardy] Caps Lock causes keys to repeat
> 
> *** This bug is a duplicate of bug 124406 ***
> https://bugs.launchpad.net/bugs/124406
> 
> ** This bug has been marked a duplicate of bug 124406
> Keyboard keys get stuck and repeat (Feisty, Gutsy)
> 
> -- 
> [Hardy] Caps Lock causes keys to repeat
> https://bugs.launchpad.net/bugs/213669
> You received this bug notification because you are a direct subscriber
> of the 
> bug.

Revision history for this message

Timo Aaltonen (tjaalton) wrote on 2008年04月16日: #2

please do monitor that one, and shout if the issue persists when that bug is fixed.

Revision history for this message

Mark Schreiber (mark7) wrote on 2009年06月07日: #3

Download full text (19.5 KiB)

Looks like Bug 213669 has been closed -- too many unrelated problems being reported there, which I think is probably a good call. I'm going to extract the relevant posts there and stick them here.

Quick summary of what I've been able to find: The problem is still present in Ubuntu Jaunty. Both Harvey and I are using Dell Inspiron 1420 laptops, and both of us have swapcaps enabled. On both systems, the kernel knows that a key (I usually see "S", as I hit caps-lock-s to get C-x C-s frequently in emacs) is down, and does not generate repeat events for it, but the "key up" event does not appear in evdev, so this can be narrowed to a kernel problem somewhere above the hardware driver level. On my system, the situation is only cleared up when another key is hit -- it does not clear up after a certain amount of time. I see no keydowns being lost. Because console applications appear to rely on kernel-generated auto-repeats rather than evdev key-ups, they "don't see" this problem -- the kernel does *not* generate auto-repeat events with this bug. Instead, xorg is never told that the key is up and thus generates auto-repeat events.

Extracted posts:

===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/125
Harvey Muller wrote on 2008年04月16日: (permalink)

Cruncher and wilderjds,

Cruncher:

The bug (#213669) I experience is not as described here, the repeating does not stop by itself. It is also not similar to #194214, in that I cannot reproduce those problems. When I experience the bug, simply hitting any other key after the repeats begins, stops the repeats.

I am running 2.6.24-16-generic and still experience the repeat bug. I do not believe my specific bug is this one, but Timo Aaltonen has deemed it a duplicate.

wilderjds:

I only get stuck repeat keys when using the Caps Lock key, holding it down then pressing another key. The second key pressed will stick frequently but not all the time.

The bug isn't triggered by cpufreq changes in my case. It happily causes repeats when both processors are stable at the low freq. And

I am able to reproduce the stuck repeats in a minimal X environment (i.e. no compiz, window manager, etc.)

===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/127

Mark Schreiber wrote on 2008年04月16日: (permalink)

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.

O...

Looks like Bug 213669 has been closed -- too many unrelated problems being reported there, which I think is probably a good call. I'm going to extract the relevant posts there and stick them here.
Quick summary of what I've been able to find: The problem is still present in Ubuntu Jaunty. Both Harvey and I are using Dell Inspiron 1420 laptops, and both of us have swapcaps enabled. On both systems, the kernel knows that a key (I usually see "S", as I hit caps-lock-s to get C-x C-s frequently in emacs) is down, and does not generate repeat events for it, but the "key up" event does not appear in evdev, so this can be narrowed to a kernel problem somewhere above the hardware driver level. On my system, the situation is only cleared up when another key is hit -- it does not clear up after a certain amount of time. I see no keydowns being lost. Because console applications appear to rely on kernel-generated auto-repeats rather than evdev key-ups, they "don't see" this problem -- the kernel does *not* generate auto-repeat events with this bug. Instead, xorg is never told that the key is up and thus generates auto-repeat events.
Extracted posts:
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/125
 Harvey Muller wrote on 2008年04月16日: (permalink) 
Cruncher and wilderjds,
Cruncher:
The bug (#213669) I experience is not as described here, the repeating does not stop by itself. It is also not similar to #194214, in that I cannot reproduce those problems. When I experience the bug, simply hitting any other key after the repeats begins, stops the repeats.
I am running 2.6.24-16-generic and still experience the repeat bug. I do not believe my specific bug is this one, but Timo Aaltonen has deemed it a duplicate.
wilderjds:
I only get stuck repeat keys when using the Caps Lock key, holding it down then pressing another key. The second key pressed will stick frequently but not all the time.
The bug isn't triggered by cpufreq changes in my case. It happily causes repeats when both processors are stable at the low freq. And
I am able to reproduce the stuck repeats in a minimal X environment (i.e. no compiz, window manager, etc.)
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/127
Mark Schreiber wrote on 2008年04月16日: (permalink) 
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.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/128
Mark Schreiber wrote on 2008年04月17日: (permalink)
Managed to reproduce without tapping any keys. Switched using mouse to xterm, and snatched this snippit from the terminal. Indeed, no keyup event is showing up until after I hit the next key sequence (a ^C) to terminate the stream of "s"es :
3742240 affb 4806 0b19 0003 0004 0004 001f 0000
3742260 affb 4806 0b22 0003 0001 001f 0001 0000
3742300 affb 4806 0b25 0003 0000 0000 0000 0000
3742320 affb 4806 08d6 0004 0004 0004 002d 0000
3742340 affb 4806 08de 0004 0001 002d 0000 0000
3742360 affb 4806 08e1 0004 0000 0000 0000 0000
3742400 affb 4806 d98c 0004 0004 0004 003a 0000
3742420 affb 4806 d997 0004 0001 003a 0000 0000
3742440 affb 4806 d99c 0004 0000 0000 0000 0000
ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss3742460 b015 4806 8412 000d 0004 0004 003a 0000
3742500 b015 4806 841f 000d 0001 003a 0001 0000
3742520 b015 4806 8424 000d 0000 0000 0000 0000
3742540 b015 4806 8ae1 000d 0004 0004 001f 0000
3742560 b015 4806 8aed 000d 0001 001f 0000 0000
3742600 b015 4806 8af2 000d 0000 0000 0000 0000
3742620 b016 4806 8f14 0000 0004 0004 002e 0000
3742640 b016 4806 8f1f 0000 0001 002e 0001 0000
3742660 b016 4806 8f25 0000 0000 0000 0000 0000
Since I believe the kernel is responsible for generating /dev/input/event* output, I would say that this is a kernel and not an xorg bug. Since there are no key repeat events being generated here the kernel must be getting enough information from the hardware to know that the key is not down, but is still not passing on the key up event.
Produced on Gutsy, linux-image-2.6.22-14-generic, Ubuntu package version 2.6.22-14.52. Just for good measure, xserver-xorg was 1:7.2-5ubuntu13.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/129
Mark Schreiber wrote on 2008年04月17日: (permalink)
Just to make things a bit more clear, the log immediately before the key events included in my previous log message was:
3742100 affb 4806 454d 0000 0004 0004 003a 0000
3742120 affb 4806 4557 0000 0001 003a 0001 0000
3742140 affb 4806 455a 0000 0000 0000 0000 0000
3742160 affb 4806 8e76 0001 0004 0004 002d 0000
3742200 affb 4806 8e80 0001 0001 002d 0001 0000
3742220 affb 4806 8e83 0001 0000 0000 0000 0000
(i.e. I was saving a file in emacs with C-x C-s). I tend to hit the keystroke fairly quickly. Some other users have suggested that their laptop coming under load tends to aggravate this -- the file saving event would have occurred as soon as I hit the "C-s", so there would have been a small burst of work, though the system was largely unloaded. This might explain why I've never seen streams of "a"s or "e"s when hitting C-a or C-e to go to the beginning or end of a line.
laptop_mode was disabled on the laptop, and frequency scaling active, since I've seen some mention of maybe frequency scaling being relevant.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/131
Mark Schreiber wrote on 2008年04月17日: (permalink)
How to reproduce reliably:
I can get about a 25% reproduction rate when hitting C-x C-s in emacs. However, the key sequence must be very rapid -- I basically have my fingers in the right position and just roll my hand over the keys. It seems to depend on the Control key being released very shortly after the "s" key is released -- if I wait a bit before releasing Control, the problem does not show up
One other note -- problem definitely still shows up with frequency scaling disabled.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/133
Harvey Muller wrote on 2008年04月17日: (permalink)
Mark,
I am curious, because we both have the same hardware, and initially experienced the bug in the same application, emacs. Have you mapped the Ctrl key to the Caps Lock key? I have observed that the Caps Lock key is part of the trigger of the repeats. Without remapping, the normal Ctrl key does not contribute to repeats. The Caps Lock key however will.
Additionally, I am unable to reproduce repeats in Recovery Mode (without X) using a console. Can you reproduce the problem in a console without X?
Thanks,
Harvey
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/134
Mark Schreiber wrote on 2008年04月17日: (permalink)
>Have you mapped the Ctrl key to the Caps Lock key?
Good catch.
Yes, I'm using swapcaps in xorg.
I used dumpkeys, swapped keycode 29 and 58, and ran the result through loadkeys.
When I ran emacs in a console, I did not get duplicated keypresses but I did get the missing key up event (based on the od -x output from the event1 device) -- the same thing I see when emacs is running in X. It looks like the "non-duplication" is because xorg is responsible for generating repeats in X and the kernel is responsible for generating repeats in the terminal. So the events from event1 are still wrong and the key is never being "released" -- it just isn't user-visible in the form of a repeating keypress. From a user standpoint, of course, this may not matter, since the key doesn't appear to be down to the user.
Interestingly enough, as you've noticed, I could not reproduce the problem when using the standard Control/Caps Lock mappings in the console -- only when the two are swapped. This may be because I simply can't release the lower-left control key quickly enough, but I did spend a while trying to get it to happen without luck.
Unless someone can produce this with the standard Control/Caps Lock mappings, I think that, as a user-visible bug, this can be narrowed to people who are using swapped caps in xorg.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/136
Harvey Muller wrote on 2008年04月18日: (permalink)
 * repeat.key (11.7 KiB, application/pgp-keys)
http://launchpadlibrarian.net/13550604/repeat.key
I am attaching a capture of the events for both "good" key press / releases and "bad" ones.
There is no discernable difference between the events between "good" and "bad" except in timing. There are no missing or extra events recorded when comparing the "bad" to the "good".
The capture was obtained by running the following and pressing [Caps Lock][X][Caps Lock][S]:
 $ sudo xev | tee repeat.key
I have to record more repeats to confirm that timing may be a triggering factor.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/137
Harvey Muller wrote on 2008年04月18日: (permalink)
Mark's comments got me thinking laterally. Perhaps there's an issue between X's software key repeat and the kernels. I turned the kernel repeat off by appending:
 atkbd.softrepeat=1
to the kernel boot parameters in grub.
It seems to help, as I have not had a repeat yet, but I'll keep testing and report the results back here later.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/138
Harvey Muller wrote on 2008年04月19日: (permalink)
atkbd.softrepeat=1 is not the solution. It reduces the occurrences of the repeats perceptibly, but does not prevent them.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/140
Harvey Muller wrote on 2008年04月20日: (permalink)
I can reliably reproduce the key repeat problem 100% of the time. So it would seem the issue is not isolated to the Caps Lock key.
When depressing the blue [Fn] key and then [F10] to eject the cdrom drawer, it creates a repeat. The repeat can be stopped by hitting any key. But the drawer will continue to eject by the number of times the repeat occurred before it is halted by hitting another key. After the eject cycles have been exhausted, the [Fn][F10] key will no longer eject the cdrom drawer during the current session.
This is on an Inspiron 1420. Mark, are you able to reproduce this?
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/141
Mark Schreiber wrote on 2008年04月24日: (permalink)
Unfortunately, I don't use GNOME, and don't have any software packages running that listen for a fn-F10, so I can't check ATM whether X believes that the key is down.
Assuming that my guessing as to the meaning of the hex dump from /dev/input/eventX is correct (2 is generated auto-repeat, 1 is down, 0 is up), that key generates events that are a little unusual too -- there's no key down or key up events generated -- just key repeat, one per key press. But I could also be misunderstanding them -- I should really dig up something that can understand the input from /dev/input/event devices to be sure. Also on an Inspiron 1420. This is not the case for fn-print screen, which generates the normal 1 and 0 events, with repeat events if held down.
Doesn't have the same kernel-level behavior that causes the other repeat problem, though it might be a bug in-and-of-itself if this is inadvertent.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/145
Mark Schreiber wrote on 2008年04月28日: (permalink)
>Has anyone tried creating a custom kernel with a faster interrupt timer?
Even if that reduced the frequency of the problem, the underlying kernel bug would still be present. The kernel must have enough state to know that the key is up (else it would generate repeat events), but is not passing the key-up event along through the /dev/input/event* devices.
There are a number of different issues here.
I saw this problem in both gutsy and hardy -- rare incidents of control+key resulting in the key being stuck down until the next keypress. pauls saw it only in hardy. Harvey gets the same behavior on identical hardware as me (inspiron 1420). Harvey also mentioned what I would guess would be an unrelated type of behavior (behavior of fn+f10, which is not timing-dependent and reproducible 100% of the time). Finally, there are the "locked keys until X server reboot" and the "scheduler bug that clears up after a few seconds" people.
(Harvey, can you please log od -x output from /dev/input/event(the event device for the keyboard), as I did, and try to repro the problem? Your "repeat.key" log shows xev output, which I would expect to not be able to differentiate between things -- the input system is what feeds xorg, and the problem is already present at that point.)
I should really split what Harvey and I are seeing off into a new bug, just to reduce the number of similar issues being thrown into this one...
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/146
http://launchpadlibrarian.net/14011822/od.log
 * od.log (296.0 KiB, text/plain)
Mark,
On splitting off, the most recent duplicate bug is one that I created. I think it's Timo's intent to lump our issues in with the rest.
I've attached od.log as you requested. I did not generate it earlier, because I cannot read the output. I was able to generate the bug and attempted to insert markers into the log to help you see where the repeat bug 'should' be starting and ending. There are no markers, because I forgot to add 'sudo' to the echo commands.
Oddly enough, I was unable to trigger the [Fn][F10] repeat bug, which was previously 100% reproducible. So that statement is now incorrect.
Harvey
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/150
Mark Schreiber wrote on 2008年05月06日: (permalink)
Harvey,
>I've attached od.log as you requested. I did not generate it earlier, because I cannot read the output.
[chuckle] Well, neither can I other than that bit that I've decoded. Okay, I'm not sure exactly where you ran into the stuck key problem, but assuming that it was your 's' key (am I right?), this confirms that it's the same problem as mine. There are key down and key up events for the 's' key, but no repeat events -- "001f 0000" and "001f 0001" but no "001f 0002". Thanks.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/160
Mark Schreiber wrote on 2008年05月31日: (permalink)
Setting atkbd.softraw=0 does not resolve the issue.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/161
Mark Schreiber wrote on 2008年05月31日: (permalink)
Also, a correction from above -- the problematic internal keyboard on my Inspiron 1420 is not being presented to the kernel as a USB keyboard, but as a BUS_I8042 AT keyboard (only realized this when I tried using usbmon to capture traffic from the keyboard).
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/182
Results of testing on a Dell Inspiron 1420. Installed 20080829 daily-live amd64 desktop (Intrepid Alpha 5) with kernel 2.7.27.
I am unable to reproduce the problem. I performed the installation, switched the Caps Lock/Ctrl keys and spent 10 minutes trying to get an unwanted key repeat. Continual use will confirm it is resolved.
Thanks,
Harvey
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/227
Harvey Muller wrote on 2009年04月14日: (permalink)
Tested an amd64 Jaunty installation for this issue (Beta plus updates), and the results are GOOD. My original bug report is a duplicate of this bug:
 https://bugs.launchpad.net/bugs/213669
Not only can I NOT generate a key repeat now, but when the Caps and Ctrl key are swapped, the Ctrl key triggers the Caps Lock led which is nice.
Thanks,
Harvey
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/237
Harvey Muller wrote on 2009年04月27日: (permalink)
The 'xset r off' behavior is interesting. If I run, as previously identified:
 $ xset r off
I get a hard 'Enter' key repeat that I do not know how to recover from other than rebooting.
If I run instead:
 $ sleep 2 && xset r off
Then I do not get the 'Enter' key repeat. But I do get key repeats again as described in the dup bug I reported #213669. But this is resolvable by running:
 $ xset r on
I am currently not having problem with key repeats unless I run 'xset r off'. And I do not normally have a reason to do so.
===
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/245
This is still present for me in Jaunty.
Unless the problem that Harvey and I are seeing is different (which seems very unlikely; both of us have Inspiron 1420s, both of us see the problem only with swapcaps, and both of us see the same symptoms: a key-up event for some regular key does not make it up out of evdev, making xorg think that the key is still down -- but the kernel knows that the key is up, as it does not generate auto-repeat events, and the problem does not thus "show up" on the console, where key repeats come from kernel-generated autorepeat events rather than the key behing held down), I expect that the problem is actually still present for Harvey too.
===

Revision history for this message

Harvey Muller (hlmuller) wrote on 2009年06月08日: #4

Mark, and anyone that follows:

In bug 124406, I indicated the key repeat issue was resolved. It is in fact not resolved, but the key repeat problem is triggered now very rarely. To repeat <pun intended> the problem is still present.

Best regards,

Harvey

p.s. I also confirm Mark's observation, that the 's' key is a common repeater.

Revision history for this message

Mark Schreiber (mark7) wrote on 2009年06月09日: #5

Unmarking as duplicate of Bug 124406 (now that I've figured out how to do so in Launchpad).

Bryce Harrington (bryce) on 2009年06月17日

affects: xorg (Ubuntu) → xserver-xorg-input-evdev (Ubuntu)

Bryce Harrington (bryce) on 2009年09月02日

tags: added: hardy

Revision history for this message

Michael Richardson (mcr-sandelman) wrote on 2009年10月21日: #6

My experience (with CAPS-LOCK as an additional CTRL key) is that the CTRL key stays down.
xkbwatch confirms this. A vt control switch (CTRL+ALT + F4) and then back to X (ALT+F7) solves my problem.
But, it's very annoying.
I too, experience this in Xemacs mostly, where I hold the "CTRL" (labelled CAPSLOCK) down for long periods of time.

Revision history for this message

Mark Schreiber (mark7) wrote on 2009年11月19日: #7

I've seen this in Jaunty and am seeing it currently in Karmic.

tags: added: jaunty karmic

Revision history for this message

Cruncher (ubuntu-wkresse) wrote on 2010年01月17日: #8

http://ajaxxx.livejournal.com/62378.html presents a possible explanation that seems quite relevant, and sounds as if it could be the true source of many of the known keyboard glitches.
It would also explain why nobody experiences the bug in the console tty, only in X.

Revision history for this message

Mark Schreiber (mark7) wrote on 2010年01月17日: #9

Cruncher: that might explain some issues that someone else is seeing, but I'm confident that it's not causing what I'm seeing. In comment #3, I summarize some of my own troubleshooting. od -x on /dev/input/event1 sees the problem as well, and od uses blocking I/O, not SIGIO. Whatever is broken is inside the kernel input code -- it isn't an xorg problem.

Hmm, actually, that means that this bug is miscategorized -- I should recategorize.

affects: xserver-xorg-input-evdev (Ubuntu) → linux-ports-meta (Ubuntu)

Revision history for this message

Harvey Muller (hlmuller) wrote on 2011年05月19日: #10

I no longer own this hardware and cannot confirm resolution. Bug may be closed.

Revision history for this message

Mark Schreiber (mark7) wrote on 2011年05月22日: #11

I still do have my hardware. Bug is still present in natty.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012年04月23日: #12

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux-ports-meta (Ubuntu):

status: New → Confirmed

Revision history for this message

penalvch (penalvch) wrote on 2014年12月12日: #13

Harvey Muller, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux-ports-meta/+bug/213669/comments/10 regarding you no longer have the hardware. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.