Keys get "stuck" down

Binary package hint: compiz

When using Compiz it is possible for keys to get "stuck" down. A simple way for me to reproduce is to scroll wildly in firefox with the mouse wheel (or trackpad scroll edge) for a couple of seconds while holding down the "page down" button. After doing this the X server believes the "page down" key is permanently pressed, making other tasks obviously difficult. Repeating this procedure (holding down "page down" and scrolling madly) will generally unstick the key after a couple of tries, but once this has occurred the keyboard behaviour is still slightly strange: some modifier key combinations (alt-tab, super-tab for compiz, super-space for Gnome-Do) no longer work, and the key-repeat settings no longer apply - pressing a key produces exactly one character/event, no matter how long you hold it down for. However, Ctrl-left, Ctrl-backspace and the like still work.

This behaviour is not limited to the "page down" key, nor does it require madly mouse-scrolling - that just makes it dependably reproducible. It also happens to me with WoW under wine, where I often have the ',' key held down and use the mouse at the same time. It seems to require keyboard+mouse activity.

I'm filing this under Compiz because I can only reproduce this behaviour while Compiz is running. Try as I might, I can't reproduce under Metacity.

Some or all of bug #190934 may be the same as this. However, simply restarting X fixes this for me - I don't need to delete any settings, or kill gconf.

ProblemType: Bug
Architecture: amd64
Date: Fri Feb 22 13:09:11 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: nvidia
Package: compiz 1:0.7.0-0ubuntu3
PackageArchitecture: all
SourcePackage: compiz
Uname: Linux CowboyLaputopu 2.6.24-8-generic #1 SMP Thu Feb 14 20:13:27 UTC 2008 x86_64 GNU/Linux

After playing with this in a non-compiz, non-composite environment, I've come to the conclusion that it's an X11 issue and not a Compiz issue.

I've been asked to clarify that I reproduced these conditions in both wmii and sawfish under standard X (and not GNOME).

I'm running Hardy latest.

I get this behaviour when using VMware and playing games. It's extremely annoying to say the least.

And I can confirm that this only happens when compiz is used.

I get this behaviour when messing around with Photoshop on Virtualbox. You can press the space bar to pan the document.

I am getting this problem too. When I play a game.
I use Ubuntu 8.04 with GNOME and Compiz. But I noticed this happen in Fluxbox too.

Linux ubuntu 2.6.24-8-generic #1 SMP Thu Feb 14 20:40:45 UTC 2008 i686 GNU/Linux

$ dpkg -l *xserver* | grep ii
ii x11-xserver-utils 7.3+2 X server utilities
ii xserver-xorg 1:7.3+10ubuntu5 the X.Org X server
ii xserver-xorg-core 2:1.4.1~git20080131-1ubuntu4 Xorg X server - core server
ii xserver-xorg-input-all 1:7.3+10ubuntu5 the X.Org X server -- input driver metapacka
ii xserver-xorg-input-evdev 1:1.2.0-1 X.Org X server -- evdev input driver
ii xserver-xorg-input-kbd 1:1.2.2-3ubuntu1 X.Org X server -- keyboard input driver
ii xserver-xorg-input-mouse 1:1.2.3-2 X.Org X server -- mouse input driver
ii xserver-xorg-video-all 1:7.3+10ubuntu5 the X.Org X server -- output driver metapack
ii xserver-xorg-video-nv 1:2.1.7-1 X.Org X server -- NV display driver
ii xserver-xorg-video-vesa 1:1.3.0-4ubuntu3 X.Org X server -- VESA display driver
ii xserver-xorg-video-vga 1:4.1.0-8 X.Org X server -- VGA display driver

I had this bug before, and made report on bug #194343

I had this three times until now on hardy. The first two times without compiz, today with compiz. It always happened when I was editing an email in Thunderbird, everytime the cursor-left key got stuck, and simultaneously the Control key (when opening a terminal, D closes it like CTRL-D). It always started when I was marking some text with the keyboard (CTRL+Shift+Cursor to mark whole blocks).

Ciao

Martin

Another related bug is this: bug 190934
When I get the key stuck, then unsticking it produces the same broken modifiers. In addition, ctrl-alt-backspace will no longer work -- if you run 'xev' in console and press ctrl-alt-backspace, you get the "Terminate_Server" keysym, which Xorg itself should be grabbing. When that happens, I have to use alt-sysrq-k to kill Xorg instead.

sysrq?

Ah I see it now... The same button as Print Screen?

Ctrl+Alt+Backspace also don't work for me when this bug occurs.

I kill X, by pressing the Power button on my computer case.
This brings up the GNOME shutdown dialog, and then I click on "Log out".

This bug sounds much like what was reported already in bug #122118. My best guess is that it's a kernel bug that happens under heavy load. If that's the case, then it could be that this bug is back in the new kernels. This can be tested pretty easily if someone can downgrade to Gutsy's kernel and give it a try.

Okay, this bug is Confirmed and High priority.

Please, is someone working on this?

In response to Tuxfan's comment, I am still using Gutsy, and have the bug. As I mentioned in one of the bugs now marked as a duplicate, the bug appeared when I upgraded to Gutsy, and is associated with the use of the Broadcom 43xx firmware support through the restricted drivers manager. When the firmware is enabled, I experience the bug, when it is disabled, I do not.

Theodore Book, I have Hardy Heron. I don't have Broadcom 43xx firmfare in restricted drivers managers, only Nvidia device driver.
But my keys can get stuck too...

Theodore: as I said in the mentioned bug #122118 I'm using Gutsy too without problems with the kernel version 2.6.22-14.52 of linux-image-2.6.22-14-generic. What's your kernel?

Comments on bug #124406 seem to support my guess that this is a kernel bug (starting from: https://bugs.launchpad.net/ubuntu/+bug/124406/comments/3). And that it was fixed in some version and has come back in some other version: https://bugs.launchpad.net/ubuntu/+bug/124406/comments/74

To summarize a bit the content of bug #124406 which contains very important information (I'll probably have missed some of them in this list):
- compiz or other 3D accelerators are not required for this bug to occur
- for most it started to occur after an upgrade to Gutsy (=2.6.22), but some even experienced it in Feisty
- for some, upgrading the kernel to Hardy Alpha2 fixed the problem, for others, it resurfaced with newer kernels
- at least one occurence in Gentoo
- the kernel bug in question is here: http://bugzilla.kernel.org/show_bug.cgi?id=9448

Here it is:

tbook@ambrose:~$ uname -a
Linux ambrose 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686
GNU/Linux

TuxFan wrote:
> Theodore: as I said in the mentioned bug #122118 I'm using Gutsy too
> without problems with the kernel version 2.6.22-14.52 of linux-
> image-2.6.22-14-generic. What's your kernel?
>
> Comments on bug #124406 seem to support my guess that this is a kernel
> bug (starting from:
> https://bugs.launchpad.net/ubuntu/+bug/124406/comments/3). And that it
> was fixed in some version and has come back in some other version:
> https://bugs.launchpad.net/ubuntu/+bug/124406/comments/74
>
>

Hmm, under the direction of RAOF in IRC, I have booted the 2.6.22-14-generic kernel, and can confirm that the issue does still occur there (I'm on Hardy, dist-upgraded from Gutsy). The bug is instantly reproducible by pressing a key and using a mouse button at the same time -- for example, save your work first!, then go to a terminal and hold a key such as 'pgup' or 'home', and scroll the mouse; this will cause the key to get stuck down (The 'delete' key is particularly dangerous!) and you'll have to alt-sysrq-k to kill Xorg.

I actually first noticed this key "stuckage" about one or two months ago after some Xorg update; if I grep through my pidgin logs, the first time I see myself complaining about this issue was on January 31.

I can confirm this bug in 8.04, running 2.6.24-12-generic and -server.
It's a very bare installation with xserver-xorg and openbox on top of a Ubuntu Server.

The keyboard repeat bug particularly happens when issuing heavy commands in xterm, like "apt-cache search xserver". Issuing such a command, the return key will stuck until a moment after it has finished, obscuring the output with newlines.

I tried several kernel parameters without luck (noapic, nolapic, clock=tsc, clock=pit, notsc, e.g.).

A temporary workaround for this is to add aliases in ~/.bashrc like this:
alias apt-cache='sleep 0.1 && apt-cache'

I haven't used X so much since I installed Hardy in the weekend, so I can't tell how many programs are affected by this bug.

I must say this bug is REALLY a showstopper for Hardy atm.

Sorry for double-posting so quickly, but I just found a more permanent solution (Murphy's law, heh).

I no longer have the keyboard repeat bug.

Add "noapic acpi=off" to the kernel parameters in /boot/grub/menu.lst

Like this:
kernel /vmlinuz-2.6.24-12-generic root=UUID=22067212-2c20-4a6f-86c2-46b98667fbe2 ro quiet splash noapic acpi=off

This is niiiiice :P

Someone in #ubuntu+1 (on freenode) said this was a problem with 'dynticks'.

Indeed, it is a show stopper. I really hope it gets fixed.
I've heard people with other distribution have this bug too!

I wish there was an edit button.

After a while the bug appeared again.
Setting "noapic acpi=off" did NOT solve the problem. I think it was just coincidence that it seemed to work for a while.

Helge,
Someone mentioned that I could try "nohz=off", I have not tried it.
Perhaps you might be interested in trying it out?

On the crashing note, often when I have things looping, newly launched apps will crash out. Firefox (latest beta) and Tomboy are two key examples of this. When I can next safely restart X, I'll force a modifier key lock-up. I think that's what causes most crashes.

nq: open up a terminal, force the bug and switch back to the terminal. Are you seeing repeated keystrokes?

And yeah, looks like I'm on the right version:

xserver-xorg-core:
  Installed: 2:1.4.1~git20080131-1ubuntu6
  Candidate: 2:1.4.1~git20080131-1ubuntu6
  Version table:
 *** 2:1.4.1~git20080131-1ubuntu6 0
        500 http://archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

The following bugs are listed as duplicates of this bug,
https://bugs.launchpad.net/ubuntu/+bug/158436
https://bugs.launchpad.net/ubuntu/+bug/124406
which is not the case. In my case, i dont have to kill
the xserver to get the keys unstuck, after 30-50 repeats
everything goes back to normal. It only happens with
key combinations, that is I dont see wwwwwwwwwwwwww
but alt-tab, alt-f4, ctrl-n repeats forever. I'll post the
same comment to those bugs I've attached, please
remove them from duplicate lists as they dont have
the exact same symptoms ie in both of them the
key repeats are settled down after some time.

For the first time today I experienced keys getting completely stuck in X.
It began to switch desktops continuously, a little more than once a second.

Normally I can only trigger the similar symptom:
Whenever I execute a very I/O-intensive task in a terminal (like aptitude), the return key gets stuck until a moment after the system has time to relax again.

As has been mentioned here several times, this bug has already been fixed. This was a bug where keys would stick and WOULD NOT clear themselves. Even ctrl-alt-backspace had no effect.

If you are experiencing keys getting stuck which clear themselves after a while, or you are able to use ctrl-alt-backspace to restart X, then you are NOT experiencing this bug. Please report your issues under another bug.

> As has been mentioned here several times, this bug has already been fixed.

Hewus: I wish you'd read my comments here before posting that. It would have saved me posting this comment. I have this bug still. Keys do not clear themselves. Control+alt+backspace does not work. No modifier keys work.

I'm not disagreeing that Helge and zadig probably don't have this issue, but saying this bug is fixed is false.

Helge wrote:
> Normally I can only trigger the similar symptom:
> Whenever I execute a very I/O-intensive task in a terminal (like aptitude), the return key gets stuck until a moment after the system has time to relax again.
>
This presumably is the same issue that I encountered. It's fixed in
recent kernels, see bug #124406.

Oli wrote:
 > I'm not disagreeing that Helge and zadig probably don't have this issue,
> but saying this bug is fixed is false.
You must have a different bug. Nobody else has reported crashing
applications so far.

I don't know if this will help anyone but I had two new hardy installs that had random repeating "stuck" keys where the 6.10 LTS did not on the same equipment. The way I made the systems usable was to use System->Preferences->Keyboard and unchecked check box "keys repeat when ..." to turn key repeat off completely. It is a little inconvenient for a lot of scrolling up and down but random stuck keys was much worse. I hope this helps.

Is this still a problem on updated systems? This bug has been fixed for me for weeks, but I keep seeing other bugs marked as duplicates of this.

Asa: It is here on this system.

Tom: So what bug do I have? Its behaviour here mimics each and every symptom of the bug submitted here. I'm really happy that the bug is fixed for most people here but yeah... Please don't try to say it's fixed everywhere because it's not.

There's another thread: https://bugs.launchpad.net/ubuntu/+bug/124406

They're no closer to finding out what's wrong but the kernel is getting a lot of the blame. There is one useful nugget of information that means I can actually get on with life though:
 - create a launcher on your panel
 - set the command to: setxkbmap
 - when the bug rears its filthy blood-stained head, click it
 - carry on as if nothing happened

The same guy that came up with that found a way to 100% replicate the bug. Load up VMWare and a guest OS, give the guest focus, hold control, and drag the mouse out of the guest. BAM. I do a lot of copy-n-pasting out of VMWare so I guess that's why I'm seeing it so much.

I'm curious as to why it's only some apps though. I can do that ^^^ all day long in VirtualBox and it's fine... Hence why I'm moving to VB now =) FOSS FTW!

Oli: What you are describing with VMWare is exactly the problem I just started having after I just upgraded (sorry I'm late to the party). I can reproduce it exactly the same way you describe with VMWare and the setxkbmap trick works perfectly for me.

Can anyone tell me if there is a thread specifically for this problem as Oli describes. I hate to continue monitoring this thread that has been resolved already if there's a new one that fits my problem better. I did a little searching but I haven't found the perfect thread for this problem yet. Another problem I've been having (as a side note) for a long while is that when the computer is idle for a while if VMWare has focus the screen saver won't kick in but as soon as vmware loses focus the screen saver kicks in even though I'm moving the mouse... The only reason I mention that is that I have my screen saver requiring a password and I just had to power off my machine because I couldn't type the password with this keyboard bug active... Sorry to get so far off topic. Thanks in advance to anyone that can point me to the right thread for this bug.

kernel 2.6.24-19.21
xorg 1:7.3+10ubuntu10.1

on my Intel Core2 Duo laptop I very seldom reckon psmouse driver resync in syslog ( bug #34501)
psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.

psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
however today that driver kept losing sync for almost half an hour.

At first the problem was shown as vertical scroll not working any more (this happens fairly often after I keep my pc a few hours (10+) without rebooting).

Then the mouse problem increased in frequency.

At last the keyboard stopped responding too! The two bugs seems actually linked.
On

I could not use Sysrq. I had to hard reboot the system.

Hi there.

The psmouse.c problem (see this kernel bug http://bugzilla.kernel.org/show_bug.cgi?id=8740) can be fixed using i8042.nomux=1, the keyboard stuck keys problem is instead the current kernel bug 9147:

http://bugzilla.kernel.org/show_bug.cgi?id=9147

To which there is no known workaround except that of disabling ACPI (or some ACPI modules).

Me too ...

My reply to https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/237604 might be of interest:

[quote]

I've been having this problem across several versions of Ubuntu, and have been affected by the problem both in KDE and Gnome.

One link that has been suggested is that it could be related to some keycode-related error messages that keep appearing in dmesg :

[quote][4335062.871000] atkbd.c: Use 'setkeycodes e02a <keycode>' to make it known.
[4335063.546000] atkbd.c: Unknown key pressed (translated set 2, code 0xaa on isa0060/serio0).
[4335063.546000] atkbd.c: Use 'setkeycodes e02a <keycode>' to make it known.
[4335063.607000] atkbd.c: Unknown key released (translated set 2, code 0xaa on isa0060/serio0).
[4335063.607000] atkbd.c: Use 'setkeycodes e02a <keycode>' to make it known.
[4335073.996000] atkbd.c: Unknown key pressed (translated set 2, code 0xaa on isa0060/serio0).
[4335073.996000] atkbd.c: Use 'setkeycodes e02a <keycode>' to make it known.
[4335074.114000] atkbd.c: Unknown key released (translated set 2, code 0xaa on isa0060/serio0).
[4335074.114000] atkbd.c: Use 'setkeycodes e02a <keycode>' to make it known.[/quote]

These error messages can be stopped by going to System->Administration->Services and disabling a service known as hotkeys-setup.

In yet another attempt to make Ubuntu usable again I've disabled this service, so if the system remains functional, expect to hear more from me.[/quote]

16 hours, and it's still working. So it's not entirely unlikely hotkeys-setup has been causing the keyboard problems all along.

I'm using Intrepid, proprietary NVIDIA drivers and Compiz Fusion. This bug seems to only occur when there's mouse activity; for example, if I hold down a key in gedit, it gets appended (as expected). While I'm holding down the key, if I move the mouse, it stops getting appended. Once I stop moving the mouse, the key works again.

Ah, I forgot to note here that disabling setup-hotkeys or hotkey-setup or whatever it was called didn't solve the problem after all. However, an old mailing list posting from 2003 hints at the keyboard handling in the kernel 2.6 series being the cause of a remarkably similar problem:

"The answers differ for 2.4 and 2.6. For 2.4 each keypress is a keypress,
and key releases are rather unimportant as long as the key is not a
modifier key. For 2.6 we have synthetic repeat, so a second keypress from
the keyboard is ignored, the key repeats with kernel-defined frequency,
and the repeat is ended by the key release."

http://lkml.org/lkml/2003/9/14/148

I'm seeing similar behaviour in Jaunty as a new regression in the last couple of days updates. It's not happening very often - a few times an hour - but it is happening. It does not seem like a hardware problem because it's come on very suddenly and is on many different keys, especially modifiers and space.

I'm using metacity, not compiz, and am on an X61s with an intel graphics card.

(If you'd rather I open a new bug just say so.)

why hasn't this bug been merged to bug 124406? it is clearly not a xorg-server bug

The bugs are probably closely related and may even have identical causes in the end, but the original symptoms are very different. For this bug there was a patch to xorg-server that worked for most people - but apparently not all.
But until it is established that they *do* have identical causes, I'd vote for keeping the bug separate.

@Martin Pool: Are you sure you experience *this* bug? The symtoms of this bug are described for example here: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/194214/comments/103 (if you say it happens "a few times an hour", I don't think you keep restarting your X-Server every couple of minutes to get out of key repeat loops?), however the symptoms of bug 124406 are intermittent key repeats (and probably key losses) that stop *by themselves* after a few repeats, and are much more visible for normal keys instead of modifier keys.

@Cruncher you're right, it probably is bug 124406 that i'm seeing

Closing since this bug was fixed a long time ago.

This bug seems to have re-emerged in Lucid.

This bug has re-appeared in Lucid. It seems to correspond to high CPU usage. Beyond that, I am not an expert on these things, but am happy to help if possible.

then file a new bug, don't reopen ancient ones.

Just for completeness:

Had that problem too. Since I have removed the screensaver handling B.S. from the xine-ui, no problem any more... somehow xine uses the Xtst extension from xorg to simulate input. And that seemed to mess up things.