Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#17380 - [xorg] repeating keystrokes (probably only when using hotplugging)

Attached to Project: Arch Linux
Opened by Pierre Chapuis (catwell) - Friday, 04 December 2009, 14:47 GMT
Last edited by Andrea Scarpino (BaSh) - Tuesday, 07 June 2011, 10:23 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 19
Private No


Sometimes, keystrokes or key combinations are repeated as if they were kept pressed until the user does something to stop it (press the key again, press escape, ...).

This happened to me twice but it is hard to repeat because I don't know what triggers it. I saw nothing in the logs about it.

Many users have experienced the same bug:

Forums thread:
French forums thread:

I have only seen reports of it happening in X and when using hotplugging.
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Tuesday, 07 June 2011, 10:23 GMT
Reason for closing:  None
Additional comments about closing:  old. re-open if necessary
Comment by Benjamin Robin (benjarobin) - Friday, 04 December 2009, 15:26 GMT
We don't need to press the same key again to stop it, just press an other key (in my case). But we can have the repetition of a combination of key like Ctrl + v that copy in an infinity loop the bloc of text in the clipboard (More difficult to reproduce). The easiest case to reproduce is when I do a simple copy with Ctrl + c and the 'c' key is repeated. But it works too with some other key. One time, I can do something very strange (I can not reproduce it): Type some text, the last character was 'r', I take the mouse click on the address bar of firefox and the key start to flooding the address bar with 'r'
Comment by Alois Nespor (anespor) - Saturday, 05 December 2009, 07:39 GMT
same problem (x86_64, own test kernel 2.6.32 )
Comment by Markus (xor_eax_eax) - Saturday, 05 December 2009, 16:52 GMT
same problem here. I kept track of it while programming in Netbeans or wrting text into a formula field of a website while using firefox.

(x86, 2.6.31-ARCH)
xf86-input-keyboard 1.4.0-1
xorg-server 1.7.2-2
gnome-desktop 2.28.1-1

Comment by Klaus (klausd) - Saturday, 05 December 2009, 18:14 GMT
I have a terrible bug that does not let me normally use my PC. I simply can't type not thinking about this bug! So, suddenly the
keyboard becomes crazy (me mad) - the effect is like CAPS LOCK is turned on, INSERT BUTTON was pressed, CTRL BUTTON was presed. This buttons were not pressed but the effect is like they were. Terrible, PC is just not usable!
Comment by Xavier (shining) - Saturday, 05 December 2009, 18:21 GMT
Does any of you have Option "AllowEmptyInput" "off" in xorg.conf ?
If you use that option and have hal running, it is known to break things.

Edit : already 4 negative answers, so this is clearly not the problem. You can ignore the question now :)
Comment by Markus (xor_eax_eax) - Saturday, 05 December 2009, 18:22 GMT
Addition to my previous posting:

In my case I only see the phenomenon with returns and carriage returns. Once, I had an infinite loop of returns in every open bash console and in NetBeans. It was hardly possible to regain control of my desktop!
Comment by Markus (xor_eax_eax) - Saturday, 05 December 2009, 18:23 GMT

I don't have such an option set.
Comment by Klaus (klausd) - Saturday, 05 December 2009, 18:49 GMT
>Does any of you have Option "AllowEmptyInput" "off" in xorg.conf ?

No. I don't have this option in my xorg.conf. Frankly speaking I used to not have xorg.conf at all some time ago (I used xorg's autodetecting ficility). Currently I have xorg.cong. This bug was then and is now. It appears more often when I type big amount of text or when I am coding (type some amount of text).
Comment by Bernd Pol (bernarcher) - Saturday, 05 December 2009, 19:50 GMT
I have not (yet) experienced this problem.
Could it be DE-related? So far I have seen it appears to occur in Gnome mainly.
I do use a plain Openbox (x86_64, last update 2009-12-05 10:58 GMT), a few Gnome applications and mainly (G)Vim, urxvt and Firefox/Thunderbird and all working well.
Comment by Benjamin Robin (benjarobin) - Saturday, 05 December 2009, 19:52 GMT
No, I guess, because in the French forum ( We have user that install only KDE, and some other only Gnome. And for me the option "AllowEmptyInput" is not set into my xorg.conf
Comment by Pierre Chapuis (catwell) - Saturday, 05 December 2009, 21:30 GMT
I don't have AllowEmptyInput set, and I use PekWM.
Comment by Kiss Ákos (akosch) - Sunday, 06 December 2009, 06:42 GMT
I have this too with my enter key: pressing the key again stops it. I'm using xmonad btw...
Comment by Bernd Pol (bernarcher) - Sunday, 06 December 2009, 08:58 GMT
This problem was first mentioned in the french thread cited above on November 24th (02:42 GMT). Thus I assume it has to do with some upgrade shortly before that date. Perhaps comparing pacman.log about this time will shed more light at this phenomenon.

Mine of 2009-11-23 and 11-24 is attached for comparison as I still do not see this problem.
Comment by Alois Nespor (anespor) - Sunday, 06 December 2009, 10:05 GMT
I think it started before. After the upgrade xorg-server.

[2009-11-21 19:25] upgraded gnome-mplayer-svn (1590-1 -> 1592-1)
[2009-11-21 19:25] synchronizing package lists
[2009-11-21 19:26] starting full system upgrade
[2009-11-21 19:26] starting full system upgrade
[2009-11-21 19:27] upgraded gstreamer0.10-bad (0.10.16-1 -> 0.10.17-1)
[2009-11-21 19:27] upgraded gstreamer0.10-good (0.10.16-2 -> 0.10.17-1)
[2009-11-21 19:27] upgraded xf86-input-evdev (2.3.0-1 -> 2.3.1-1)
[2009-11-21 19:27] upgraded xfce4-power-manager ( ->
[2009-11-21 19:27] warning: directory permissions differ on etc/X11/
filesystem: 775 package: 755
[2009-11-21 19:27] upgraded xorg-server ( ->
[2009-11-21 19:27] warning: directory permissions differ on etc/X11/
filesystem: 775 package: 755
[2009-11-21 19:27] upgraded xorg-xinit (1.1.1-1 -> 1.2.0-1)
[2009-11-21 19:57] synchronizing package lists
[2009-11-21 19:57] starting full system upgrade
[2009-11-21 19:57] starting full system upgrade
[2009-11-21 19:57] upgraded eggdbus (0.5-1 -> 0.6-1)
[2009-11-21 19:57] upgraded libexif (0.6.17-1 -> 0.6.19-1)
[2009-11-21 19:57] upgraded polkit (0.94-1 -> 0.95-1)
[2009-11-21 19:57] upgraded poppler (0.12.1-1 -> 0.12.2-1)
[2009-11-21 19:57] upgraded poppler-glib (0.12.1-1 -> 0.12.2-1)
[2009-11-21 19:57] upgraded xcompmgr (1.1.4-2 -> 1.1.5-1)
Comment by Markus (xor_eax_eax) - Sunday, 06 December 2009, 10:48 GMT
Here is my pacman log. It must have to do with one of these packages in my list, because before I never had problems with infinite loops of returns or carriage returns.
Comment by Alois Nespor (anespor) - Sunday, 06 December 2009, 11:18 GMT
Comment by Vitaliy (ngsupb) - Sunday, 06 December 2009, 14:11 GMT
Asus laptop. got this issue after some upgrades. Don't remember what I upgraded and when it appeared.
I have the same problem. It makes me crazy.
Comment by Keerthi (keerthi) - Sunday, 06 December 2009, 14:19 GMT
Same issue here. Very sporadic. For a moment I thought its KDE's fault. But seems a bit more involved at 'X' level. Please fix, its very annoying. No special settings in xorg.conf; running hotplug.
Comment by Bernd Pol (bernarcher) - Sunday, 06 December 2009, 14:30 GMT
OK, for better comparison, here is may pacman.log starting at 2009-11-21.
Comment by Markus (xor_eax_eax) - Sunday, 06 December 2009, 15:20 GMT
I had this annyoing error again. This time I didn't type anything special. I just edit the my.cnf, saved it and run then:

# /etc/rc.d/mysqld restart

I didn't even type the command. I just used the [ARROW UP] button to get to the last command and hit return. After hitting return, this annyoing infinite return loop begun, but I was able to stop it with hitting another key.
Comment by Benjamin Robin (benjarobin) - Sunday, 06 December 2009, 16:45 GMT
@Bernd Pol Sorry to say that, but I wait more than one week before reporting the problem in the french forum. (I am not sure now... maybe only 2 days)
For me I can see this problem more than 5 time in an hour.
I have checked the pacman.log between 14 november and 24 November (when I report the problem) Maybe these packages can cause the problem:
[2009-11-22 01:25] upgraded xf86-input-evdev (2.3.0-1 -> 2.3.1-1)
[2009-11-22 01:25] upgraded xorg-server ( ->
[2009-11-22 01:25] upgraded xorg-xinit (1.1.1-1 -> 1.2.0-1)
[2009-11-22 21:01] upgraded nvidia-utils (190.42-1 -> 190.42-2)

But I am not sure that nvidia-utils is the problem

So I am going to downgrade xf86-input-evdev to try (So it's not this package after 1 hour of test...)
Comment by Vitaliy (ngsupb) - Sunday, 06 December 2009, 17:35 GMT
I am trying to check older versions of xorg-server. I have downgraded to xorg-server-1.7.1-1-i686.pkg.tar.gz
Haven't seen this bug in this version yet.

Could someone test it with this version too?
Comment by Benjamin Robin (benjarobin) - Monday, 07 December 2009, 00:40 GMT
I have downgrade to this version of xorg-server: ( and after more than one hour of testing I don't have any problems.
Comment by Vitaliy (ngsupb) - Monday, 07 December 2009, 08:00 GMT
I don't have any problem with too after one day of testing.
So we certainly can say that this issue appeared
in xorg-server-1.7.2-1 and still exists in xorg-server-1.7.2-2

Someone knows what was changed in these two last versions? :D

Comment by Vitaliy (ngsupb) - Monday, 07 December 2009, 08:11 GMT

as I see they don't recommend to upgrade to 1.7.2 due to some issues that exist in this version.

Probably better to wait for 1.7.3?
Comment by Alessandro Nakamuta (alessandro_ufms) - Monday, 07 December 2009, 10:51 GMT
I downgrade xorg-server to and this problem is gone.
Comment by Pierre Chapuis (catwell) - Monday, 07 December 2009, 11:49 GMT
I can't see how what they talk about in this email could cause the problem though.
Comment by Jan de Groot (JGC) - Monday, 07 December 2009, 11:52 GMT
1.7.2-2 is the same as 1.7.3 upstream with only one difference in that couldn't have caused this bug. I will do some experiments with updated packages today.
Comment by Vitaliy (ngsupb) - Monday, 07 December 2009, 12:39 GMT
>I can't see how what they talk about in this email could cause the problem though.

I can't see too. Probably it isn't know bug :( I have sent a question to their maillist. Will look for a help there.
Comment by Ionut Biru (wonder) - Monday, 07 December 2009, 15:38 GMT
what about 1.7.3-1?
Comment by voltaic (voltaic) - Monday, 07 December 2009, 21:49 GMT
I can confirm this issue on Arch x86_64 on a Thinkpad X200s. Xorg server 1.7.2, evdev 2.3.1, hotplug. Happens sporadically, but mostly in firefox. I am not using a desktop environment, just a window manager (dwm).

I noticed that the copy of evdev I have installed was compiled for xorg I don't know if might be the cause of the problem.
Comment by Alessandro Nakamuta (alessandro_ufms) - Tuesday, 08 December 2009, 09:52 GMT
This issue still happens on 1.7.3-1.

At final of Xorg.0.log on appears:

(II) Open ACPI successful (/var/run/acpid.socket)
(II) Dec 01 22:54:55 NVIDIA(0): Setting mode "nvidia-auto-select"
(II) Dec 01 22:54:57 NVIDIA(0): ACPI display change hotkey events enabled: the X server is new
(II) Dec 01 22:54:57 NVIDIA(0): enough to receive ACPI display change hotkey events.
(--) SynPS/2 Synaptics TouchPad: touchpad found
(II) Asus Laptop extra buttons: Device reopened after 1 attempts.
(II) Macintosh mouse button emulation: Device reopened after 1 attempts.
(II) AT Translated Set 2 keyboard: Device reopened after 1 attempts.
(II) Logitech USB-PS/2 Optical Mouse: Device reopened after 1 attempts.
(II) USB2.0 1.3M UVC WebCam: Device reopened after 1 attempts.
(II) Sleep Button: Device reopened after 1 attempts.
(II) Video Bus: Device reopened after 1 attempts.
(II) Power Button: Device reopened after 1 attempts.

The code above doesn't appears on 1.7.2 and 1.7.3.
Comment by Vitaliy (ngsupb) - Tuesday, 08 December 2009, 10:45 GMT
got an email from xorg mail list.
No ideas what causes it. The advice is to inspect the changes between the versions:S
Someone is able to trace it?

unrelated, shouldn't affect the keyboard driver.

Vitali - if it didn't occur in 1.7.1 but it does in 1.7.2/3, please bisect
to find the patch that caused the regression. there's only a relatively
small number of changes, so it should be easy enough to find.

Comment by Alois Nespor (anespor) - Tuesday, 08 December 2009, 16:16 GMT
I think, I found the affected component.

After the downgrade xf86-input-evdev do not have it for several hours repeating problems.

I used the PKGBUILD from version 2.3.0 and use still xorg-server 1.7.3.

EDIT: Back to trees - After seven hours the bug occurred. Schade.
Comment by Markus (xor_eax_eax) - Tuesday, 08 December 2009, 16:22 GMT

No, because I just switched back to xorg-server and haven't had this problem since then. So my thought is that it's an xorg issue and not an evdev issue.
Comment by Benjamin Robin (benjarobin) - Tuesday, 08 December 2009, 16:41 GMT
@anespor See my comment (06 December 2009): So I am going to downgrade xf86-input-evdev to try (So it's not this package after 1 hour of test...)
I mean in less than one hour, just by downgrading xf86-input-evdev the problem occurs twice
After I try to downgrad xorg-server, after one day, no problem
Comment by Mauro Santos (R00KIE) - Tuesday, 08 December 2009, 19:08 GMT
I confirm this happens with xorg-server 1.7.3. I did the upgrade, logged out (which takes me to the console, I'm not using any graphical login manager) and soon after I started a graphical session it happened, I didn't reboot my machine though. However this problem happens very rarely to me and I don't have any reliable way to trigger it so it might have been just a fluke.
Comment by Rikard Johansson (RiJo) - Tuesday, 08 December 2009, 19:16 GMT
Confirmed here as well. I'm getting this once or twice a day while programming... Extremely annoying!

xorg-server 1.7.2-2
xf86-input-keyboard 1.4.0-1
hal 0.5-13-3
Comment by Xavier (shining) - Tuesday, 08 December 2009, 19:23 GMT
Can we get a few more confirmation please ? I don't think there is enough, let's try to reach 100 !

And please do not try to bisect to find the patch that caused the regression ! Make sure you only keep confirming the bug without providing any extra information. Otherwise it would be extremely annoying. Thanks :)
Comment by Alessandro Nakamuta (alessandro_ufms) - Tuesday, 08 December 2009, 19:23 GMT
I've tried downgrade xf86-input-evdev and the issue still happens.
Comment by Vitaliy (ngsupb) - Tuesday, 08 December 2009, 20:31 GMT
Could someone advise how to:

1) find the patches from 1.7.1 to 1.7.2?
2) compile to choose patches and exclude one by one?

so we can test it and move further :)

P.S. Looks like I found the changes

Now we need to compile one by one :D

P.P.S just tried to compile from abs by using the source from freedesktop.or and couldn't do it. It has some weird dependences in pkgbuild.
Why are there?
Comment by Benjamin Robin (benjarobin) - Tuesday, 08 December 2009, 22:42 GMT
I don't know if it's that but when I see the name of the fix (contain event...) : I find how I can compile without this commit...

So now I am running 1.7.3 without this commit... And it's not this one, it's just fail one minute ago...

Try again without:
And it's fail twice...

@Matthew (pyther) Your are kidding...
Comment by Xavier (shining) - Tuesday, 08 December 2009, 23:11 GMT
google is your friend :
man git-bisect

Just pick any links you want. If it is not enough, try the next one :)

You should also use the information here :
You can see the branch (in the url and in the green box) that you need to checkout : server-1.7-branch
And you see the tags in yellow that you can use as commit id with git bisect : xorg-server-1.7.3 and xorg-server-

If you can temporarily avoid to use abs/makepkg/whatever, it can make your life easier when testing. But you have to know how to clean up the mess when you are done.
Comment by Matthew Gyurgyik (pyther) - Wednesday, 09 December 2009, 01:06 GMT
Just want to say I get the issue with 1.7.3-1 mainly when I'm playing games (ut2004, half-life 2 (wine) ). As others have stated pressing another key resolves the issue.
Comment by majiq (majiq) - Wednesday, 09 December 2009, 03:14 GMT
I'm just here to add my confirmation...just kidding. I have the same issue, but I think it's fairly obvious that doing a git-bisect will be slightly irritating without a reliable way to trip the bug. I cannot imagine the similarities, between the different times it trips, but is anyone yet able to reliably reproduce the bug? If someone can give me a method to trip it, I can gladly bisect it, but otherwise I won't know if a version is bad until (possibly/eventually) it trips the bug by accident.

Edit: Given that we have so many people and not too many patches, we could all just take a build and try it...
Comment by Vitaliy (ngsupb) - Wednesday, 09 December 2009, 10:55 GMT
>>Edit: Given that we have so many people and not too many patches, we could all just take a build and try it...
I would test a build if someone can create builds

I am afraid to go with git and mess my pc :D it is a laptop at work.
Comment by Babets (Babets) - Wednesday, 09 December 2009, 14:47 GMT
I confirm this bug :P
Comment by Xavier (shining) - Wednesday, 09 December 2009, 16:03 GMT
I read all the comments again, twice, and I don't even see clear indication whether the 902 package works or not.
Though rulex made that clear on bbs :

By the way, you can find all the packages you want there :
And probably on other mirrors found on :

To Vitaliy : thanks for reporting upstream, though it would have been even better to give a link to the archives rather than copy/paste.
Peter just gave good instructions about how to bisect :

So we know that 901-2 is good, but 902-1 is bad.
However, the difference between these two packages is not a simple revision bump. 5 patches were added too :[]=%2Fxorg-server%2Ftrunk%2F%4059194&compare[]=%2Fxorg-server%2Ftrunk%2F%4058470&comparesubmit=Compare+Revisions&op=comp

I think that should not be neglected, as the upstream differences between 901 and 902 look pretty harmless and/or irrelevant :

So what someone could try is to checkout the 902-1 pkgbuild and rebuild it to confirm it does not work.
svn update -r59246 xorg-server

Then remove the 5 xserver-1.7.1-* patches, rebuild, and see if that works better.

If it is not broken, follow Peter instructions for the git bisect. You can start by checking 901 works and 902 does not, and after that there will be very few.
You can probably skip all the xquartz commits which seem completely irrelevant, so its just 8 patches (and its a bisect so it will be less than 8 steps).
Of course each step will take long since the bug is not easy to reproduce. But that's fine, just do one test per day.
Comment by Benjamin Robin (benjarobin) - Wednesday, 09 December 2009, 17:44 GMT
@Xavier I have already start to do stat, but it's take so many time to test...
And sorry to forget to say explicitly that doesn't work. The only update that I made of xorg-server was:
[2009-11-22 01:25] upgraded xorg-server ( ->
Comment by Xavier (shining) - Wednesday, 09 December 2009, 17:50 GMT
Did you try vanilla , without any patches ?
I would start with that.
Comment by Vitaliy (ngsupb) - Wednesday, 09 December 2009, 18:21 GMT
Benjamin&Xavier please create a list of patches you are testing, so other know what is left to do.

I will try to build from svn if it works for me (for some reason abs didn't because of weird dependences )
and will test tomorrow too.
Comment by Pierre Chapuis (catwell) - Wednesday, 09 December 2009, 22:32 GMT
The most suspect patch I can see is the sigaction one, it's the only one that affects evdev. I will try to rebuild without it but I have already a lot of difficulties to trigger the bug so my results won't really be conclusive...
Comment by Benjamin Robin (benjarobin) - Thursday, 10 December 2009, 06:09 GMT
Hum interesting, I have compile without the patch 'sigaction' after one hour of testing: no problem... Will see tomorrow ^^
Comment by Benjamin Robin (benjarobin) - Thursday, 10 December 2009, 23:49 GMT
I am going to compile the version 1.7.3 without the patch 'sigaction', because I don't have any bug without the patch 'sigaction' in the last 2 days for the version
Comment by Vitaliy (ngsupb) - Friday, 11 December 2009, 09:55 GMT
nothing worked for me. I can't build unfortunately. Some issue with gl nvidia library while compiling
rensize.c:222: error: ‘GL_DEPTH_STENCIL_MESA’ undeclared (first use in this function)
even the beta nvidia version didn't work

Benjamin, just send me the builds that needs to be tested. I would like to test 1.7.3 too without this patch.
Comment by Massimiliano Torromeo (mtorromeo) - Friday, 11 December 2009, 14:08 GMT
@Benjamin: which is the sigaction patch you are talking about? I am willing to test it too.
Comment by Massimiliano Torromeo (mtorromeo) - Friday, 11 December 2009, 14:12 GMT
Nevermind, I tought it was an upstream commit but I just found it is applied by the PKGBUILD.
I'll report back my results.
Comment by Benjamin Robin (benjarobin) - Friday, 11 December 2009, 23:10 GMT
I am currently running 1.7.3 without the sigaction patch and everything it's working fine, and because the title of the path is: "Microoptimization to SIGIO handling" I vote to remove this patch to 1.7.3 and create a new release version (2) for the xorg-server
Comment by Pierre Chapuis (catwell) - Saturday, 12 December 2009, 02:31 GMT
Same here, although I know the bugtracker is not a poll, but we probably tend to say that we "vote for" something because we're both French ;)

This patch brings very little performance improvement and looks like it is the source of this bug, so I think it should be removed. Moreover, the fewer patches, the better...
Comment by Vitaliy (ngsupb) - Saturday, 12 December 2009, 08:13 GMT
Benjamin's build of worked fine for me. I am going to test the 1.7.3 version without this patch today.

Is that patch intended for performance only?
Comment by Martin Sandsmark (sandsmark) - Saturday, 09 January 2010, 23:16 GMT
Still happens here, with
Comment by Xavier (shining) - Saturday, 09 January 2010, 23:29 GMT
The problem was quite rare for me, but did happen from time to time. It is definitely gone now.
Is it gone for everyone but sandsmark ? That would be.. strange and suspicious :)
Comment by Jan de Groot (JGC) - Saturday, 09 January 2010, 23:45 GMT
Some hardware can be buggy, or maybe it's just a kernel issue. I'm facing this problem on my laptop also, but that's either a kernel or hardware bug. My dmesg is full with this:
atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known.

Which is the keyboard driver that scans only half of the keycode of the key I released, resulting in a stuck key. This is usually the case with the arrow keys, I don't have problems with other keys. If sandsmark is having problems like this, it's not related to this bug and it should get closed again.
Comment by majiq (majiq) - Sunday, 10 January 2010, 00:42 GMT
I confirm that this is still happening for me as well. The frequency is not the same as before, but it does occur, with no information in any of my logs. I'm also on a laptop.
Comment by Martin Sandsmark (sandsmark) - Sunday, 10 January 2010, 14:08 GMT
Much more seldom, and I don't think it has been anything other than key combos (like cltr+{w,q} and the like).
And still only under heavy load.
Comment by Xavier (shining) - Wednesday, 27 January 2010, 01:35 GMT
By the way, ajax explained the problem with his sigaction patch, and explained that there is still an issue with the old code, and that a race condition can still be triggered causing repeating keystrokes. It is just much less likely but the bug can still happen :

There seems to be a different issue in the kernel, which seems to be the one JGC mentioned, when you see : atkbd.c: Unknown key released

And not sure where this one fits :