Bug #213669 “[Hardy] Caps Lock causes keys to repeat” : Bugs : linux-ports-meta package : Ubuntu

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.

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.

Changed in linux-ports-meta (Ubuntu):
status:	Confirmed → Invalid

Ubuntu
linux-ports-meta package

[Hardy] Caps Lock causes keys to repeat

Bug Description

Other bug subscribers

Remote bug watches

Ubuntulinux-ports-meta package

[Hardy] Caps Lock causes keys to repeat

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
linux-ports-meta package