Keys get "stuck" down

[Chris Halse Rogers]

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

[Peter Hutterer (peter-hutterer)]

(In reply to comment #0)
> When some window is opened by some grabbed key, grabbing all keys and they
> destroyed (like the window ratpoison opened uppon C-t :, or the window icewm
> shows when doing Alt-Tab), the xserver is caught in an endless loop within
> PlayReleasedEvents in dix/events.c.

interesting bug... tricky to track down.

The bug only occurs if Xkb triggers an autorepeat. In this case, XkbHandleActions overwrites dev->public.realInputProc with EnqueueEvent. When the device is unfrozen, the realInputProc is written back to the processInputProc and the whole thing craps out.

Here's a preliminary hack to fix it. It stops the loop occuring (tested with ratpoison) but I'm not sure what other implications it has. It most probably is not the correct solution.

diff --git a/include/xkbsrv.h b/include/xkbsrv.h
index 167dbec..9f7f0d6 100644
--- a/include/xkbsrv.h
+++ b/include/xkbsrv.h
@@ -258,7 +258,8 @@ typedef struct
      device->public.processInputProc = proc; \
  oldprocs->processInputProc = \
  oldprocs->realInputProc = device->public.realInputProc; \
- device->public.realInputProc = proc; \
+ if (proc != device->public.enqueueInputProc) \
+ device->public.realInputProc = proc; \
  oldprocs->unwrapProc = device->unwrapProc; \
  device->unwrapProc = unwrapproc;

[Raul Sanchez Siles (rasasi78)]

I've hit this one as well. On x86 and x86_64 laptops. It occurs when I press repeatedly volume up/down keys, kmilo get the focus and does some action but it doesn't dissapear (it should) and X is locked, even if the mouse moves.

This is not a realiable way to reproduce the problem, but most times I get it is like this.

Debian unstable (server 1.4.1 and intel 2.2 driver). I would like to note that this problem didn't happen on server 1.4.

Sorry, but I haven't test the patch, this is a backtrace on my x64_64 laptop:
#0 0x000000000045a09b in ComputeFreezes () at ../../dix/events.c:1164
#1 0x00000000004551d1 in ProcUngrabKeyboard (client=0x8ccb40)
    at ../../dix/events.c:4296
#2 0x000000000044e3d2 in Dispatch () at ../../dix/dispatch.c:502
#3 0x0000000000436bcc in main (argc=8, argv=0x7fffe198e7d8,
    envp=<value optimized out>) at ../../dix/main.c:452

Thanks.

[Peter Hutterer (peter-hutterer)]

pushed to master as 50e80c39870adfdc84fdbc00dddf1362117ad443

[James H. Cloos Jr. (cloos-jhcloos)]

In https://bugs.freedesktop.org/show_bug.cgi?id=13688#c8 (8th comment of bug 13688), discussing the patch in this bug’s comment 1, <email address hidden> writes:

> That patch fixes the IceWM crash... but replaces it with another bug. Now when
> I press backspace first time after using the dialog, the server quits without
> any error message, like if I had pressed control-alt-backspace instead.

I haven’t yet tried the current server again since commit 50e80c39870adfdc84fdbc00dddf1362117ad443 was pushed, but expect to do so Sunday.

I’ll follow up on whether I also see the undesired server-quit.

[Raul Sanchez Siles (rasasi78)]

After having check that Debian unstable solves this (git20071212) I still have found some important issues detailed on https://bugs.freedesktop.org/show_bug.cgi?id=13937

[Peter Hutterer (peter-hutterer)]

(In reply to comment #5)
> After having check that Debian unstable solves this (git20071212) I still have
> found some important issues detailed on
> https://bugs.freedesktop.org/show_bug.cgi?id=13937

I'm pretty sure #13937 has a different cause. Marking this bug as fixed.

[Chris Halse Rogers (raof)]

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

[Will Farrington (wcfarrington)]

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.

[Will Farrington (wcfarrington)]

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.

[Senutek (senutek)]

> I'm pretty sure #13937 has a different cause. Marking this bug as fixed.

I don't know. I have only changed 2 lines in 1.4.0.90

https://bugs.freedesktop.org/show_bug.cgi?id=13937#c1

So it's not complete solution.
I have reopened this bug. If you want more information I can play with GDB/add some printfs if you tell me where. It's very annoying bug.

[Peter Hutterer (peter-hutterer)]

(In reply to comment #7)
> > I'm pretty sure #13937 has a different cause. Marking this bug as fixed.
>
> I don't know. I have only changed 2 lines in 1.4.0.90
>
> https://bugs.freedesktop.org/show_bug.cgi?id=13937#c1
>
> So it's not complete solution.
> I have reopened this bug. If you want more information I can play with GDB/add
> some printfs if you tell me where. It's very annoying bug.

does the autorepeat/whatever work before the bug is triggered?

[Senutek (senutek)]

Yes. autorepeat works until I press:
(few times, combination of)
Win+KeyPad_Plus - Amarok turn up volume
Win+KeyPad_Minus - Amarok turn up volume
Win+Shift+KeyPad_Minus - Amarok seek forward
Win+B - Amarok next track

Last two are a bit CPU time consuming. BTW I have Core 2 Duo.

After that X freeze (without patch) or (with patch):

1. autorepeat does not working (everywhere). xset r rate doesn't change it
2. alt+tab will not change window focus (however xev prints alt and tab keys)
3. amarok playlist (only it, amarok search bar - same window) behave like Shift was pressed (multiple continuous selection instead of track selection)

[Oli (oli)]

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.

[Chow Loong Jin (hyperair)]

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

[Fred (eldmannen+launchpad)]

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

[Fred (eldmannen+launchpad)]

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

[Peter Hutterer (peter-hutterer)]

I can't reproduce this bug. Can you provide more information about how exactly you reproduce the bug?

Also, I'm pretty sure you're triggering a new bug somewhere in the abyss of xkb.

[Martin Emrich (emme)]

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

[Coron (coron)]

I encountered the bug when using ratpoison, too. The proposed workaround was not in place, then. After searching through the commits between v1.4 and 1.4.0.90 I found that commit
83e76fb3f7a89a237893c2b7df450d4f90eab52d
introduced the bug. If I reinstate the ProcessKeyboardEvents pointer in the COND_WRAP* macros in xkbActions, the X server won't loop endlessly.

[Dana Goyette (danagoyette)]

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.

[Oli (oli)]

sysrq?

[Oli (oli)]

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

[Fred (eldmannen+launchpad)]

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".

[TuxFan (make)]

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.

[Fred (eldmannen+launchpad)]

Okay, this bug is Confirmed and High priority.

Please, is someone working on this?

[Theodore Book (tbook)]

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.

[Fred (eldmannen+launchpad)]

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...

[TuxFan (make)]

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

[Cruncher (ubuntu-wkresse)]

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

[Theodore Book (tbook)]

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
>
>

[Dana Goyette (danagoyette)]

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.

[Helge Willum Thingvad (helgesdk)]

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.

[Helge Willum Thingvad (helgesdk)]

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

[Fred (eldmannen+launchpad)]

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!

[Helge Willum Thingvad (helgesdk)]

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.

[Fred (eldmannen+launchpad)]

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

[Chris Halse Rogers (raof)]

On 3/11/08, Helge <email address hidden> wrote:
>
> 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.
>
You are seeing a different bug. This bug is triggered by mouse button
activity while a key is pressed, and results in the key remaining
pressed indefinitely (or until the condition is triggered again, but
the keyboard is still in a broken state after this).

Please file a new bug for this behaviour, or find an existing bug with
the same symptoms and subscribe to it.

[Chris Halse Rogers (raof)]

For those playing at home, none of the options "nohz=off", "acpi=off",
"hpet=disable", or "nosmp" have any effect on my ability to trigger
this bug on either the -12-generic or -12-rt kernels.

[Fred (eldmannen+launchpad)]

Can someone please goto the bottom of this, and find exactly what is causing this problem, and why?
And then make a solution for it?

When can we expect this highly annoying bug to be fixed?

[Chris Halse Rogers (raof)]

On 3/12/08, Fred <email address hidden> wrote:
> Can someone please goto the bottom of this, and find exactly what is causing this problem, and why?
> And then make a solution for it?
>
> When can we expect this highly annoying bug to be fixed?

A short while after someone works out what is wrong, and finds a way
to fix it. If it were obvious, it would already be fixed. If we knew
enough information to know when it would be fixed, it would already be
fixed :).

You are welcome to help in this - finding the first version of the X
server packages which exhibits this bug would be extremely handy, for
example.

[Tom Jaeger (thjaeger)]

There's been some speculation here about this being a kernel issue. I don't think so, based on the testing I've done so far:

Latest hardy: Problem occurs
Latest hardy with gutsy kernel: Problem occurs
About one-month old hardy with gutsy kernel and gutsy xserver: I couldn't reproduce the problem.

If all else fails, this is how the problem can be isolated:
* Check that the issue is present in the latest upstream xserver git
* Check that it wasn't present in upstream xserver 1.3
* Do a git bisect

This is obviously a lengthy and painful process, but given the severity of the issue, it might be worth it. However, we should make sure that we get the opinion of an xorg developer first. Did anybody file an upstream bug report yet? Or has this been discussed on an xorg mailing list?

[Per Baekgaard (baekgaard)]

I got this bug when I upgraded my AMD64/Dual Core (Asus MB/NVidia grpx) system to 7.10. It wasn't there before in the previous release.

After some fiddling around and reading the threads here, I tested various options for getting rid of it. I eventually added the "ec_intr=0" option to the kernel, and now the keys no longer get stuck. I have been stable now without this bug for quite some time.

I do get an occasional system freeze, though, from time to time, but I don't think those two bugs are related.

-- Per.

[Fred (eldmannen+launchpad)]

I posted to LKML about this.

Replies that I got;
* " I had the same problem back in the 2.6.16 to 2.6.20 days (no dynticks). The only solution I found was to get rid of gnome. Since then I've been happily running with xfce."
Can anyone confirm or deny that this is re-producable in other desktop environments than GNOME?

* "Very probably this is due to broken way how X themselves implement auto-repeat, instead of using kernel-provided auto-repeat functionality. I guess you are not able to reproduce this problem in the console, but only X, right?"
Yeah, I've never seen this problem in the console. Anyone have?

* "AFAIK it's a problem with X being confused by scheduler behavior (which is not necessarily wrong)."

[Fred (eldmannen+launchpad)]

I don't know what "ec_intr=0" exactly is, but I googled it, and it seems to have something todo with ACPI. Can someone further explain?

Anyone can form that this fixes it?

[Tom Jaeger (thjaeger)]

ec_intr=0 does not fix the issue on my system.

A link to Fred's LKML thread:
http://thread.gmane.org/gmane.linux.kernel/652769

[Dana Goyette (danagoyette)]

Hmm, yesterday and today I went through older versions of xorg (mainly just xserver-xorg-core) by two or three at a time, and the first version I encountered that didn't have the sticking issue is 2:1.4-3ubuntu1 ( xserver-xorg-core_1.4-3ubuntu1_i386.deb ) . I tried the same actions of scrolling while holding pgup, and could not make the keys get stuck.
 Some time today, I think I'll try going forward one version at a time; the version I tried before the 1.4 version above still had the issue: xserver-xorg-core_1.4.1~git20071212-1ubuntu2_i386.deb

[Fred (eldmannen+launchpad)]

Thank you Dana and good luck.
We appreciate your effort! :)

[Dana Goyette (danagoyette)]

Well, I must be lucky: the very next version ( 2:1.4.1~git20071105-1ubuntu3 ) reintroduces the bug. Therefore, the bug must've been introduced somewhere between the following two versions:

 Date Status Target Pocket Component Section Version
 2007-11-01 18:03:03 PDT Superseded hardy i386 release main x11 2:1.4-3ubuntu1
   2007-11-11 13:03:02 PST Superseded hardy i386 release main x11 2:1.4.1~git20071105-1ubuntu3

(lines copied from https://launchpad.net/ubuntu/hardy/i386/xserver-xorg-core .)

I have also restored all other related Xorg server packages to their current versions, with no effect on behavior; thus, thus only the 'core' seems to matter.

[Cruncher (ubuntu-wkresse)]

Umh, the matter is more complicated I fear. The first time it occured for me was after the Feisty->Gutsy upgrade. I've got xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu8.3 installed ever since.
The bug vanished for me after switching from Gutsy kernel 2.6.22-14-386 to Hardy Alpha2 kernel 2.6.24-2-386 (just the kernel, nothing else except nvidia-glx-legacy and libc6).
But maybe it is related to something that changed between the xserver versions you mentioned, anyway.

[Fred (eldmannen+launchpad)]

Great to hear Dana that you have made progress.
You seem to have identified the version and the part of Xorg.

Now if we could 'diff' them or git bisect them or something...
To find the 'evil code'.

[Asa Ayers (asa-ayers)]

I've found that if I go to System > Preferences > Keyboard and uncheck "Key presses repeat when key is held down" it solves my problem. I hope that helps in figuring out whats going on.

[Chow Loong Jin (hyperair)]

I'm afraid that brings us nowhere nearer. We have already ascertained that it's because xorg doesn't see the key release event.

[Fred (eldmannen)]

But then I can't hold down the keys.
Example, if I want to move my guy in a game to the left, I don't want
to press Left-key 25 times, I want to hold it down.
If I want to erase some text, I don't want press backspace 10 times, I
want to hold down backspace.

On Sat, Mar 15, 2008 at 9:28 PM, Asa Ayers <email address hidden> wrote:
> I've found that if I go to System > Preferences > Keyboard and uncheck
> "Key presses repeat when key is held down" it solves my problem. I hope
> that helps in figuring out whats going on.
>
>
>
> --
> Keys get "stuck" down
> https://bugs.launchpad.net/bugs/194214
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Asa Ayers (asa-ayers)]

It depends on the game, I play WoW in Wine and it detects then a key is pressed and when it comes back up, so its fine for me. its not a perfect solution, but its the only workaround I'm aware of. so far the non-repeating keys have only been a problem when I use a terminal where I can't select the text to delete and backspace once.

>But then I can't hold down the keys.
>Example, if I want to move my guy in a game to the left, I don't want
>to press Left-key 25 times, I want to hold it down.
>If I want to erase some text, I don't want press backspace 10 times, I
>want to hold down backspace.
>
>On Sat, Mar 15, 2008 at 9:28 PM, Asa Ayers <email address hidden> wrote:
>> I've found that if I go to System > Preferences > Keyboard and uncheck
>> "Key presses repeat when key is held down" it solves my problem. I hope
>> that helps in figuring out whats going on.

[woz (bugs-x1a4)]

I seem to be having the same or a similar problem.

I'm running gutsy ubuntu with everything up to date. I am also running synergy. I originally had a different bug that appears to be at least partially documented elsewhere of vmware not picking up the shift key when using synergy. Then, I also got this bug where my control key is stuck down. It doesn't affect any of my other computers that are hooked up through synergy though.

I also just installed compiz before this began to happen.

[dl.zerocool (dl.zerocool)]

[ I've found that if I go to System > Preferences > Keyboard and uncheck "Key presses repeat when key is held down" it solves my problem. I hope that helps in figuring out whats going on. ]

I've tried this and the problem occurs anyway, I've the feeling that is when we move mouse and have a key pressed, I can be wrong.

Anyway in gutsy I didn't had this trouble, I upgrade to hardy and it happened. The problem is not young cause I had this problem on hardy alpha 2 or 3 don't remember exactly
and it was the same thing, I reinstalled gutsy to get a full working os again.

Something on Xserver is certainly the base of the problem.

[dl.zerocool (dl.zerocool)]

This two logs are from an gdm restart just after the problem occurs.

I used:
dmesg > dmesg.log
and
sudo lspci -vvnn > lspci-vvnn.log

[dl.zerocool (dl.zerocool)]

Hello,

I'm actually using debian/unstable and the probleme is the same, it wasn't on testing.

So I presume this is a Kernel / Xserver problem.

Hope someone will find somethingl, because I don't know what to do and this is really really annoying!

[Tom Jaeger (thjaeger)]

bonsai,
Until someone comes up with a fix or a workaround, your best bet is to downgrade your xserver-xorg-core package to <= 2:1.4-3ubuntu1.

[Fred (eldmannen+launchpad)]

Okay, so we seem to know that the problem is here;

2007-11-01 18:03:03 PDT Superseded hardy i386 release main x11 2:1.4-3ubuntu1 <-- works
2007-11-11 13:03:02 PST Superseded hardy i386 release main x11 2:1.4.1~git20071105-1ubuntu3 <-- does not work

Can someone please, check what was changed and fix it?

[Tom Jaeger (thjaeger)]

We know next to nothing about what's causing the issue. I'll attach a diff between the two versions, in case anyone wants to give it a try.

[Fred (eldmannen+launchpad)]

Tom Jaeger,
Good that you attached a diff.
But how do you know, that it is the file /composite/compext.c who is the culprit?

Upload both files, so we can do a side-by-side comparison.

[Chris Halse Rogers (raof)]

I've run a git-bisect against upstream xserver, results here:
The bug is introduced somewhere in the following commits

a53172827c69a88155a088843c9a3e8a7a7a0463
b76b1d51fe3053fa2a60b64de9ac93f50ef252f5
83e76fb3f7a89a237893c2b7df450d4f90eab52d
b600e7c123ce637359a75c43bf67b3462eadb37e
15117d47bf883f3eefc57404f1dfc0c933ab054a

I can't do better than that, since all these revisions fail to build.
The git bisect log is:
git-bisect start
# bad: [0050d7e78d990fa945bd808554b0a86721262786] DIX: XKB: Set xkbInfo to NULL as well as freeing it (bug #10639)
git-bisect bad 0050d7e78d990fa945bd808554b0a86721262786
# good: [99dd8b9414d1eb7aabc682be0b9cfd7a27eb2a6b] Bump version to 1.4.0.
git-bisect good 99dd8b9414d1eb7aabc682be0b9cfd7a27eb2a6b
# bad: [15117d47bf883f3eefc57404f1dfc0c933ab054a] xkb: enable XI event processing for xkb.
git-bisect bad 15117d47bf883f3eefc57404f1dfc0c933ab054a
# good: [bd779f8cde1c71a0db8470b8c993504da7c1104e] configure.ac/XFree86: Only build XF86Misc and XF86VidMode when appropriate
git-bisect good bd779f8cde1c71a0db8470b8c993504da7c1104e
# skip: [b76b1d51fe3053fa2a60b64de9ac93f50ef252f5] XFree86: Remove ridiculous SIGIO debugging
git-bisect skip b76b1d51fe3053fa2a60b64de9ac93f50ef252f5
# skip: [a53172827c69a88155a088843c9a3e8a7a7a0463] xkb: Store the action filters per device in the XkbSrvInfoRec.
git-bisect skip a53172827c69a88155a088843c9a3e8a7a7a0463
# skip: [b600e7c123ce637359a75c43bf67b3462eadb37e] XKB: Add more bits to xkbsrv.h
git-bisect skip b600e7c123ce637359a75c43bf67b3462eadb37e
# good: [63c6d9d622a10303f594a07bd86dda8e5f894ca7] Xi: Include XI protocol header in exevents.h
git-bisect good 63c6d9d622a10303f594a07bd86dda8e5f894ca7
# skip: [83e76fb3f7a89a237893c2b7df450d4f90eab52d] Save processInputProc before wrapping it and restore it later, instead of using a hardcoded ProcessKeyboardEvent. Otherwise we lose the ability to process DeviceKeyEvents after the first key press.
git-bisect skip 83e76fb3f7a89a237893c2b7df450d4f90eab52d

I'll try to build upstream git head, and verify that the bug is still reproducible in there.

[Fred (eldmannen+launchpad)]

Chris Halse Rogers,
Thank you for your work, I am sure all affected by this bug are glad that you done this.
Great that we now have a git bitsect.

I look forward to hear from you when you build an upstream git head.

I hope the git bisect makes sense to people here...

[Richard Klinda (rklinda)]

I experience these issues too, my question, is there a web site / blog / forum that is about exclusively this bug?

AFAICT there are a lot of interested people, this bug is a massively major PITA.

[Tom Jaeger (thjaeger)]

I continued Chris's git-bisect (the build errors were pretty easy to fix, much easier than getting X to build at all and getting compiz to run on top of it). The issue manifested itself in a slightly different manner for me - the X server hung instead of auto-repeating, but I assume it's the same problem. Anyway, this seems to be the commit that is causing the trouble:

# bad: [83e76fb3f7a89a237893c2b7df450d4f90eab52d] Save processInputProc before wrapping it and restore it later, instead of using a hardcoded ProcessKeyboardEvent. Otherwise we lose the ability to process DeviceKeyEvents after the first key press.

The attached patch reverses this commit on the current hardy X server (there were a few additional occurrences of UNWRAP_PROCESS_INPUT_PROC, but those could be dealt with in a completely analogous way).

[Tom Jaeger (thjaeger)]

Updated xserver-xorg-core deb, which seems to fix the issue on my system.

[Fred (eldmannen+launchpad)]

Great to see progress.
Anyone can confirm that Tom Jaeger's uploaded file fixes this?
Make a patch.
Hopefully we can soon get it fixed upstreams...

[Chris Halse Rogers (raof)]

I can confirm that the patch fixes this problem. I'm not familiar enough with X to know whether or not this is the right solution, but it certainly is _a_ solution.

Debdiff for the server I built attached.

[slavik (gslavik)]

Any chance for an amd64 deb or instructions on building xorg-core with the patch?

[Tom Jaeger (thjaeger)]

Actually, I'm absolutely sure that this _not_ the right solution. Right now, I'm thinking that all the patch does is effectively disabling xkb.

[Tom Jaeger (thjaeger)]

So, putting this in your xorg.conf might in theory be a better workaround,

Section "ServerFlags"
        Option "XkbDisable" "true"
EndSection

but it seems that gnome does not like this at all...

[Cruncher (ubuntu-wkresse)]

As I said here https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/194214/comments/41 ,
the bug occured for me since my upgrade to Gutsy, which uses xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu8.3 ...

[Chris Halse Rogers (raof)]

On Mon, 2008-03-24 at 02:03 +0000, Cruncher wrote:
> As I said here https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/194214/comments/41 ,
> the bug occured for me since my upgrade to Gutsy, which uses xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu8.3 ...

Then yours is probably a different bug, or this was fixed in 1.4 and
broken again shortly after. I'd be inclined to think the former - your
bug probably has a different cause to this one.

[Tom Jaeger (thjaeger)]

I think I figured out what the problem is (see the freedesktop bug for details). I also assigned the bug to Peter Hutterer, so hopefully we'll see some real progress on this soon.

I also included a proposed (but basically untested) fix, if you want to try that out. I'm calling it a night.

[Tom Jaeger (thjaeger)]

New deb based on the proposed fix.

[Fred (eldmannen+launchpad)]

Great to see progress.

I hope this gets fixed before 8.04 "Hardy Heron" gets released.

[Tom Jaeger (thjaeger)]

*** Bug 14449 has been marked as a duplicate of this bug. ***

[slavik (gslavik)]

amd64 version of the deb with the debdiff applied.

[Tom Jaeger (thjaeger)]

If I'm not mistaken (which isn't all that unlikely, this stuff is complex), there is a problem with the workaround:
If the sequence is Freeze - UNWRAP - Thaw - COND_WRAP (if that's possible?), then after thawing we'll have dev->public.processInputProc == dev->public.realInputProc, so the assignment device->public.processInputProc = proc in COND_WRAP goes through, allowing EnqueueEvent to escape. It's just not as bad since we haven't replaced realInputProc with EnqueueEvent.

If you're still having issues with the workaround in place, the patch attached to bug #14449 might be worth a try. In basically tries to enforce the invariant (in case of Freezing/Thawing, there might be other users of the mechanism) that
processInputProc == (!frozen ? realInputProc : EnqueueEvent).

[Fred (eldmannen+launchpad)]

Was an update just rolled out?

I think I just got an update, and it fixed this...

Anyone confirm?

[Bryce Harrington (bryce)]

Don't need this assigned both to xorg and xorg-server, so closing the xorg component.

[Chris Halse Rogers (raof)]

Here's a candidate debdiff with the revised patch applied.
You can find both amd64 & i386 packages built from it here:
http://cooperteam.net/xserver-xorg-core_1.4.1~git20080131-1ubuntu6_amd64.deb
http://cooperteam.net/xserver-xorg-core_1.4.1~git20080131-1ubuntu6_i386.deb

[Tom Jaeger (thjaeger)]

Okay, so there has been a workaround for this in master since Dec 07.

https://bugs.freedesktop.org/show_bug.cgi?id=13511

I still like my patch better, though...

[Bryce Harrington (bryce)]

Excellent. Can others please test these and verify the fix (and that it doesn't introduce additional problems)?

If it looks good and we get a few confirmations, we can upload this for hardy.

[Chris Halse Rogers (raof)]

Ack'd. Works for me, doesn't seem to introduce any regressions. (nvidia-glx-new, amd64).

[Elliot Murphy (statik)]

This is working well for me too.

[PPln (px33)]

Everything works, including, direct rendering (nvidia 169.12) and wacom tablet that works even better than before

[Fred (eldmannen+launchpad)]

I have installed;
http://cooperteam.net/xserver-xorg-core_1.4.1~git20080131-1ubuntu6_i386.deb
from Chris Halse Rogers

And it works... and I think it have fixed the bug too!

Chris Halse Rogers is awesome and hes my hero and hes master programmer of all and very cool!
Tom Jaeger and Dana are very cool too!

[ram32 (osiris1987)]

Worked for me, thanks :)

[Fred (eldmannen+launchpad)]

Hmm... I might have had a problem, its strange...

So I was watching porno, and clicking on the pictures with the mouse.
I never touched the keyboard (I think), just the mouse.
Then suddenly the 'up' key got stuck, and it started to scroll up all the time.

[zadig (zadig-jaja)]

I have ubuntu gutsy installed and I cannot install the deb files attached,
the package installer lists zillions of conflicts with the installed xserver*
packages.

http://cooperteam.net/xserver-xorg-core_1.4.1~git20080131-1ubuntu6_i386.deb
                                    xserver-xorg-core_1.4.1~git20080131-1ubuntu5_i386.deb

I had this bug for a long time, and disabled the autorepeat a month ago and
it disappeared but still interested in the 'Real' solution. Not sure how to apply these
patches.

[Carsten Schurig (cs42)]

The xserver-xorg-core deb fixed my problem. Can't reproduce this bug even after hours.

[Helge Willum Thingvad (helgesdk)]

xserver-xorg-core_1.4.1~git20080131-1ubuntu6_i386.deb did NOT fix my problem, however it might be different because my keys (usually Return) only get stuck temporarily while issuing a CPU intensive command in a terminal emulator.

[vzz (vuohiz)]

I got this bug without any workload simply by opening terminal, pressing a key down and doubleclicking few times with mouse. The patch is working fine on my system, no more stuck keys. Using Hardy/amd64.

[Timo Aaltonen (tjaalton)]

I'd rather wait for upstream to confirm that this patch is the way to go. After that it can be uploaded.

[Richard Klinda (rklinda)]

Is it possible to see the upstream's response to this bug? I tried to find the discussion on http://lists.freedesktop.org/archives/xorg/2008-March/thread.html but i haven't find anything related to this.

[Tom Jaeger (thjaeger)]

Since there hasn't been any activity on the xorg bug tracker, I'll send a slightly modified version of the patch to the xorg mailing list as soon as I get some more testing done. The new patch is attached. I've eliminated another possible cause of an inconsistent state, and removed the workaround I mentioned in https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/194214/comments/74, which I didn't realize had already made its way into ubuntu. By the way, this workaround is the reason why we were seeing infinite auto-repeats as opposed to the endless loops that I experienced during git-bisect.

[Tom Jaeger (thjaeger)]

http://lists.freedesktop.org/archives/xorg/2008-March/034256.html

[Timo Aaltonen (tjaalton)]

Fixed in git, thanks!

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg-server - 2:1.4.1~git20080131-1ubuntu6

---------------
xorg-server (2:1.4.1~git20080131-1ubuntu6) hardy; urgency=low

  * 157_fix_exa_pixmap_width.diff:
    A patch from upstream to allow wider pixmaps with EXA (LP: #205599)
  * 158_xkb_wrapping.diff:
    A patch reviewed by upstream that prevents keys from getting stuck under
    certain situations. (LP: #194214)
  * 51_xkb-and-loathing.diff:
    Re-enable. Ignore SIGALRM around calls to Popen()/Pclose() to fix a hang
    when opening menus in OpenOffice.org. (LP: #204137)

 -- Timo Aaltonen <email address hidden> Sun, 30 Mar 2008 19:18:32 +0300

[Fred (eldmannen+launchpad)]

All praise Tom Jaeger, the master coder of the universe!

[Fred (eldmannen+launchpad)]

This problem is /almost/ solved for me.

But even with xserver-xorg-core 2:1.4.1~git20080131-1ubuntu6
It sometimes the 'up' key gets stuck. I don't think I even pressed that key sometimes...
I am not sure its the same problem, but it seems pretty related...

[Nicholas LaRoche (nlaroche)]

I have a problem on my system whereby keys will get stuck and then keyboard-repeat will turn off.

I've run into the issue on both Gentoo and Ubuntu 7.10, with a USB Keyboard.

[Timo Aaltonen (tjaalton)]

Nicholas: this bug is fixed in 8.04.

Fred: file a new bug if you think it's necessary.

[zadig (zadig-jaja)]

Are we going to get this through system update, symantic, as a deb
or just need to learn how to get the source code and do it the hard
way ? I hate being a noob !

[Chris Halse Rogers (raof)]

If you're using Hardy, then just updating will fix this. If you're not using Hardy, you don't have this bug.

[Oli (oli)]

Well this isn't fixed for me. I know that's a useless statement but I don't exactly know how to qualify it further other than explaining:

Mashing a bunch of keys and mousebuttons in VMWare or some fullscreen games reproduces this almost instantaneously. Still only happens under compiz. Same MO as before.

[zadig (zadig-jaja)]

Chris: I am not using hardy and I still have the bug. I have gutsy installed :S

[nq (nquach08)]

I am currently using 8.04 with all the latest patches and still having this error. As others above have mention it usually happens when trying to click the mouse or type while another application is doing any intensive cpu or disk access. Personally for me its usually happens when running VMware Workstation but I have experience the same issues with other applications as well. When this occurs, I am unable to type in any new applications that is launched. It automatically crashes/closes the application regardless of the key I press. Odd thing for me is any existing application that is already open before this occurs will not crash or close, but it looks like my shift key is stuck as I am unable to type any capital letters.

[Mike (0x656b694d)]

As i can see, nobody have any universal solution yet. It does mean nobody knows what is happening.
My story with this issue is the following. I´d got stuck keys after upgrade to Feisty. By some reason i decided to completely reinstall my system, and did it. The bug gone. From my experience, this issue is a consequence of an inaccurate update.

The bug has gone after reinstalling Feisty from the CD. On the exactly same hardware.

Regards,
-Mike

[Chris Halse Rogers (raof)]

@zadig: You do not have this bug. You have a bug with similar
symptoms. This bug was introduced in a X server version that is not
in Gutsy. Please file a new bug (or, better, test Hardy to see if you
can reproduce your bug there, and then file a bug).

@nq: You, also, are not seeing this bug. Your symptoms are different
- newly started apps crash for you, but you are able to type. This
bug is about a key (any key) being eternally repeated. Please open
another bug, or find an existing bug which describes your symptoms.

[Oli (oli)]

Chris: What part of nq's last comment isn't completely aligned with this bug description? They and I are still having near identical experiences to what you described... Here's how I see it:

 - one key or a combination of keys are indefinitely looped
 - it often kills off modifier keys (shift, alt, etc) but not necessarily all of them
 - usually triggered under load
 - anecdotally associated with mouse clicking (certainly my experience when playing games)
 - associated with Compiz (many users can only reproduce this bug under Compiz - though that may be to do with load)
 - restarting X halts the loop
 - it's a bloody annoying bug

And it's still all over my system. Seriously though, doesn't that MO look a lot like your description? It's all very well stating that this patch fixed it for you but that doesn't mean a variation on the same bug isn't manifesting in other code. Multiple people saying the same thing would tend to suggest this issue isn't (or, at least, shouldn't be) closed.

[Chris Halse Rogers (raof)]

On 4/4/08, Oli <email address hidden> wrote:
> Chris: What part of nq's last comment isn't completely aligned with this
> bug description? They and I are still having near identical experiences
> to what you described... Here's how I see it:
>
> - one key or a combination of keys are indefinitely looped
> - it often kills off modifier keys (shift, alt, etc) but not necessarily all of them
> - usually triggered under load
> - anecdotally associated with mouse clicking (certainly my experience when playing games)
> - associated with Compiz (many users can only reproduce this bug under Compiz - though that may be to do with load)
> - restarting X halts the loop
> - it's a bloody annoying bug

Absolutely. However, nq said:
"When this occurs, I am unable to type
in any new applications that is launched. It automatically
crashes/closes the application regardless of the key I press. Odd thing
for me is any existing application that is already open before this
occurs will not crash or close..."
Which doesn't sound to me like "a key keeps repeating".

> And it's still all over my system. Seriously though, doesn't that MO
> look a lot like your description? It's all very well stating that this
> patch fixed it for you but that doesn't mean a variation on the same bug
> isn't manifesting in other code. Multiple people saying the same thing
> would tend to suggest this issue isn't (or, at least, shouldn't be)
> closed.

Right. Well, the xserver-xorg-core-2:1.4.1~git20080131-1ubuntu6
upload fixed this problem for me. Can you check that you're actually
using this version of the package - from the Ubuntu repositories?
(apt-cache policy xserver-xorg-core should print this info out).

[Oli (oli)]

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

[zadig (zadig-jaja)]

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.

[Helge Willum Thingvad (helgesdk)]

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.

[Hew (hew)]

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.

[Oli (oli)]

> 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.

[Tom Jaeger (thjaeger)]

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.

[Tom Jaeger (thjaeger)]

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.

[Peter Hutterer (peter-hutterer)]

Simon, Pawel, Raoul:
is this still a problem? Tom's patch is already in master, does it fix this issue?

[Raul Sanchez Siles (rasasi78)]

Hello:

Peter thanks for caring.

I'm still running Debian unstable, which means xserver 1.4.1 with some cherry picked commits. Still with that the problem is "solved". This means, server usable, key combinations works but there's still a minor issue in my case.

My laptop has a volume slider, the one that triggered the bug. Now it almost works but once I move slightly the slider, I get the volumeup/volumedown event autorepeated continuously as I would have been pressed it without release. This continues like this till I press another key.

I'm not sure if this problem is still related to this bug, if not I'd consider this fixed.

Regards,

[Peter Hutterer (peter-hutterer)]

(In reply to comment #15)
> My laptop has a volume slider, the one that triggered the bug. Now it almost
> works but once I move slightly the slider, I get the volumeup/volumedown event
> autorepeated continuously as I would have been pressed it without release. This
> continues like this till I press another key.

this sounds a lot like a driver/device issue. Can you check the actual output of the device with evtest. This way we can narrow down whether X is autorepeating something or the device/kernel just giving us continuous events.

[Raul Sanchez Siles (rasasi78)]

Thanks for the hint. I didn't really know how to tackle this. I'm attaching the evtest output. Once running I first pressed a regular key to test and then I moved the slider a little. When I stopped moving the slider, X was still receiving volume events but not evtest. This looks significant.

Regards,

[Raul Sanchez Siles (rasasi78)]

Created an attachment (id=16147)
evtest output for keyboard.

[Peter Hutterer (peter-hutterer)]

(In reply to comment #17)
> Thanks for the hint. I didn't really know how to tackle this. I'm attaching the
> evtest output. Once running I first pressed a regular key to test and then I
> moved the slider a little. When I stopped moving the slider, X was still
> receiving volume events but not evtest. This looks significant.
>

have a look at the last event. VolumeDown is pressed (value 1), but no release event is ever sent. This would cause xkb to autorepeat. Makes sense?
Can you try to trigger the bug again, looking for exactly this to happen?

[Raul Sanchez Siles (rasasi78)]

Thanks for worrying.

Yes Peter, that's exactly what happens. I'm attaching a more comprehensive evtest output.

Regards,

[Raul Sanchez Siles (rasasi78)]

Created an attachment (id=16204)
evtest output for keyboard.

[Daniel Stone (daniels)]

On Sun, Apr 27, 2008 at 04:59:24AM -0700, <email address hidden> wrote:
> Thanks for worrying.
>
> Yes Peter, that's exactly what happens. I'm attaching a more comprehensive
> evtest output.

Okay. Could you please file a bug on the kernel, stating exactly what
happens, your exact hardware (cat /proc/bus/input/devices, dmesg, lsusb,
maybe even lshal), giving the evtest log, and describing the problem --
key down events need a faked key release? It's the kernel's job to give
us sensible output: we can't tell the difference between a key that's
being held down and a key which doesn't generate release events.

[KCastleton (karl-castleton)]

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.

[Asa Ayers (asa-ayers)]

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.

[Dag B (dag-bakke)]

*** Bug 15519 has been marked as a duplicate of this bug. ***

[Coron (coron)]

Peter: what patch are you talking about?
commit 37b1258f0a288a79ce6a3eef3559e17a67c4dd96
in the master branch fixes this issue for me

[Peter Hutterer (peter-hutterer)]

(In reply to comment #24)
> Peter: what patch are you talking about?
> commit 37b1258f0a288a79ce6a3eef3559e17a67c4dd96
> in the master branch fixes this issue for me

cool thx.

Just for correctness, I'm marking this bug as FIXED instead of NOTABUG. The originally reported bug was in fact fixed, the other issue reported by Raul is a separate bug (and not ours)

[Oli (oli)]

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!

[ksenter (cksenter)]

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.

[aldebx (aldebx)]

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.

[Kaneda-bohater (kaneda-bohater)]

*** Bug 16424 has been marked as a duplicate of this bug. ***

[legolas558 (legolas558)]

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).

[Ben (benny-and-the-bikes)]

Me too ...

[David Oftedal (rounin)]

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]

[David Oftedal (rounin)]

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

[wj32 (wj32-64)]

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.

[David Oftedal (rounin)]

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

[Martin Pool (mbp)]

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.)

[legolas558 (legolas558)]

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

[Cruncher (ubuntu-wkresse)]

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.

[Martin Pool (mbp)]

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

[Tom Jaeger (thjaeger)]

Closing since this bug was fixed a long time ago.

[Theodore Book (tbook)]

This bug seems to have re-emerged in Lucid.

[Theodore Book (tbook)]

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.

[Timo Aaltonen (tjaalton)]

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

[Cinquero (cinquero)]

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.