Ubuntu

Keys get "stuck" down

Reported by Chris Halse Rogers on 2008-02-22
220
This bug affects 13 people
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
High
xorg (Ubuntu)
Undecided
Unassigned
Nominated for Hardy by lifestream
Nominated for Intrepid by lifestream
xorg-server (Ubuntu)
High
Unassigned
Nominated for Hardy by lifestream
Nominated for Intrepid by lifestream

Bug Description

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

Related branches

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

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.

pushed to master as 50e80c39870adfdc84fdbc00dddf1362117ad443

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.

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

(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) wrote :

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

Chris Halse Rogers (raof) wrote :
Will Farrington (wcfarrington) wrote :

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) wrote :

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.

Changed in compiz:
importance: Undecided → Medium
status: New → Confirmed
Chris Halse Rogers (raof) wrote :

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

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

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) wrote :

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) wrote :

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

Fred (eldmannen+launchpad) wrote :

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) wrote :

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

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) wrote :

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

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) wrote :

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) wrote :

sysrq?

Oli (oli) wrote :

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

Fred (eldmannen+launchpad) wrote :

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) wrote :

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.

Timo Aaltonen (tjaalton) on 2008-03-05
Changed in xorg-server:
importance: Medium → High
Fred (eldmannen+launchpad) wrote :

Okay, this bug is Confirmed and High priority.

Please, is someone working on this?

Theodore Book (tbook) wrote :

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) wrote :

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

Cruncher (ubuntu-wkresse) wrote :

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

Dana Goyette (danagoyette) wrote :

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 (helgesdk) wrote :

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 (helgesdk) wrote :

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) wrote :

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 (helgesdk) wrote :

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) wrote :

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

Changed in xorg-server:
status: Unknown → Confirmed
Bryce Harrington (bryce) on 2008-03-25
Changed in xorg:
status: New → Invalid
Changed in xorg-server:
status: Confirmed → Invalid
Changed in xorg-server:
status: Confirmed → Triaged
Changed in xorg-server:
status: Invalid → Confirmed
Timo Aaltonen (tjaalton) on 2008-03-30
Changed in xorg-server:
assignee: nobody → tjaalton
status: Triaged → In Progress
Timo Aaltonen (tjaalton) on 2008-03-30
Changed in xorg-server:
status: In Progress → Fix Committed
Changed in xorg-server:
status: Fix Committed → Fix Released
78 comments hidden view all 158 comments
Oli (oli) wrote :

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) wrote :

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 (helgesdk) wrote :

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 McLachlan (hew) wrote :

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) wrote :

> 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) wrote :

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) wrote :

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.

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

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,

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

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,

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

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

Thanks for worrying.

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

Regards,

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

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.

Changed in xorg-server:
status: Confirmed → Invalid
KCastleton (karl-castleton) wrote :

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) wrote :

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.

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

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

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

Changed in xorg-server:
status: Invalid → Fix Released
Oli (oli) wrote :

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) wrote :

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) wrote :

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.

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

legolas558 (legolas558) wrote :

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

Benjamin B. (mail-b-burkhart) wrote :

Me too ...

David Oftedal (rounin) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Changed in xorg-server:
status: Fix Released → New
legolas558 (legolas558) wrote :

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

Cruncher (ubuntu-wkresse) wrote :

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) wrote :

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

Tom Jaeger (thjaeger) wrote :

Closing since this bug was fixed a long time ago.

Changed in xorg-server:
status: New → Fix Released
Theodore Book (tbook) wrote :

This bug seems to have re-emerged in Lucid.

Theodore Book (tbook) wrote :

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.

Changed in xorg-server (Ubuntu):
status: Fix Released → Confirmed
Timo Aaltonen (tjaalton) wrote :

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

Changed in xorg-server (Ubuntu):
assignee: Timo Aaltonen (tjaalton) → nobody
status: Confirmed → Fix Released
Cinquero (cinquero) wrote :

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.

Changed in xorg-server:
importance: Unknown → High
Changed in xorg-server:
importance: High → Unknown
Changed in xorg-server:
importance: Unknown → High
Displaying first 40 and last 40 comments. View all 158 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.