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
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
|
Details
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: http://bbs.archlinux.org/viewtopic.php?id=86026 French forums thread: http://forums.archlinux.fr/topic5021.html 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
Tuesday, 07 June 2011, 10:23 GMT
Reason for closing: None
Additional comments about closing: old. re-open if necessary
(x86, 2.6.31-ARCH)
xf86-input-keyboard 1.4.0-1
xorg-server 1.7.2-2
gnome-desktop 2.28.1-1
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!
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 :)
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!
I don't have such an option set.
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).
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.
Mine of 2009-11-23 and 11-24 is attached for comparison as I still do not see this problem.
[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 (0.8.4.1-1 -> 0.8.4.2-1)
[2009-11-21 19:27] warning: directory permissions differ on etc/X11/
filesystem: 775 package: 755
[2009-11-21 19:27] upgraded xorg-server (1.7.1.901-2 -> 1.7.1.902-1)
[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)
I have the same problem. It makes me crazy.
# /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.
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 (1.7.1.901-2 -> 1.7.1.902-1)
[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...)
Haven't seen this bug in this version yet.
Could someone test it with this version too?
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
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?
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.
I noticed that the copy of evdev I have installed was compiled for xorg 1.7.1.901. I don't know if might be the cause of the problem.
At final of Xorg.0.log on 1.7.1.902-1 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.
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.
Cheers,
Peter
------------------------------------------------------------------
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.
No, because I just switched back to xorg-server 1.7.1.901-2 and haven't had this problem since then. So my thought is that it's an xorg issue and not an evdev issue.
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
kernel26 2.6.31.6-1
xorg-server 1.7.2-2
xf86-input-keyboard 1.4.0-1
hal 0.5-13-3
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 :)
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
http://cgit.freedesktop.org/xorg/xserver/log/?h=server-1.7-branch
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?
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:
http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.7-branch&id=dfb0c502946853a5a4b39a3e9814e8d576749d69
http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.7-branch&id=71f4b404c0c5b4e8f41d779687e026efd580a988
And it's fail twice...
@Matthew (pyther) Your are kidding...
man git-bisect
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
http://kernel.org/pub/software/scm/git/docs/user-manual.html#using-bisect
http://www.winehq.org/docs/winedev-guide/x1348
http://www.freedesktop.org/wiki/Infrastructure/git/Users
http://www.x.org/wiki/radeonhd#head-21026d3aec5e838d5692e50e28dc304567b274c9
http://kerneltrap.org/node/11753
Just pick any links you want. If it is not enough, try the next one :)
You should also use the information here : http://cgit.freedesktop.org/xorg/xserver/log/?h=server-1.7-branch
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-1.7.1.902
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.
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.
Though rulex made that clear on bbs :
http://bbs.archlinux.org/viewtopic.php?pid=668688#p668688
By the way, you can find all the packages you want there : http://www.schlunix.org/archlinux/extra/os/
And probably on other mirrors found on : http://wiki.archlinux.org/index.php/Downgrading_Packages
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 :
http://lists.freedesktop.org/archives/xorg/2009-December/048354.html
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 :
http://repos.archlinux.org/wsvn/packages/?compare[]=%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 :
http://cgit.freedesktop.org/xorg/xserver/log/?h=server-1.7-branch
So what someone could try is to checkout the 902-1 pkgbuild and rebuild it to confirm it does not work.
http://wiki.archlinux.org/index.php/Getting_PKGBUILDS_From_SVN
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.
And sorry to forget to say explicitly that 1.7.1.902-1 doesn't work. The only update that I made of xorg-server was:
[2009-11-22 01:25] upgraded xorg-server (1.7.1.901-2 -> 1.7.1.902-1)
I would start with that.
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.
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.
I'll report back my results.
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...
Is that patch intended for performance only?
Is it gone for everyone but sandsmark ? That would be.. strange and suspicious :)
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.
And still only under heavy load.
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
http://bugzilla.kernel.org/show_bug.cgi?id=9147
And not sure where this one fits : http://bugzilla.kernel.org/show_bug.cgi?id=9448