When using the X.org X server, the keyboard of my PC stops working after a short while. Applications still run, the mouse pointer follows and still operates the applications. Apparent "keyboard" functions such as toggling NumLock doesn't make the NumLock LED change state; same for Caps Lock. Also key combinations such as Ctrl-Alt-Fx to switch to another virtual console don't work any more. This happens both with the line Driver "kbd" and Driver "keyboard" in XF86Config. I'm running on Mandrake 10.0 with all patches until a couple of days ago installed, X from X.org CVS as of a couple of hours ago. Platform is a regular PC (built it myself), Pentium-4, 768MB RAM. Keyboard is PS/2 style, mouse is USB. Login is via KDM. I'm hoping I can attach XFConfig and Xorg.0.log to this report, if I don't find how to do that, find them at http://home.scarlet.be/~md032472/download/xorg-logs.tar.gz . In that file the Xorg.0.log.old is from a session with the problem. The Xorg.0.log is from a session in which I was fast enough to type the commands to switch back to my old configuration. So if there are messages relating to the problem, they may be in one file and not the other.
Created attachment 722 [details] files as described in the message Obviously the type of this attachment is a gzipped tar, containing 3 files.
In recent CVS "kbd" and "keyboard" both map to the new driver. Could you try to add #define UseDeprecatedKeyboardDriver YES to config/cf/host.def and recompile (you can just do "make Makefiles all" in programs/Xserver) and then set the keyboard driver to "keyboard" in your config file. This should set you up with the old driver, so we can see if it's an issue with the new driver.
Created attachment 737 [details] new logfile
Used your #define. Did "make world" (after some build error in lib/Xdmcp). Then the build went fine. The result was not better than before. How can I see whether there's a different driver in use ? Diffing the Xorg.0.log files doesn't appear to show that.
(In reply to comment #4) > Used your #define. > Did "make world" (after some build error in lib/Xdmcp). > Then the build went fine. > > The result was not better than before. Are you still using the "kbd" driver? That will always load the new driver. Make sure your keyboard InputDevice section is like this Section "InputDevice" Identifier "Keyboard1" Driver "keyboard" Option "XkbModel" "pc105" Option "XkbLayout" "en_US" Option "XkbOptions" "" EndSection I.e. make sure it has the 'Driver "keyboard"' line. > How can I see whether there's a different driver in use ? Diffing the > Xorg.0.log files doesn't appear to show that. There should be a warning in the log about using the old driver.
Created attachment 746 [details] logfile with old driver Changed the config file to use the old driver; this time the warning about using that is in the log file. Behaviour is unchanged : keyboard is dead either immediately (did I write that already? A KDE session takes a while to start up so the 'live period' of the keyboard may have passed already; I don't know.) or after a while.
On today's release wranglers call, we decided to set a deadline for patches of today at 6pm EDT. If patches are available by then, are small and self-contained, they can still be integreated into the release. Otherwise, we will move the remaining open bugs to the release notes bug 999 for documentation.
Moving to release notes bug 999 as noted earlier.
I may have found the real reason now; curing this is not something I can do, unfortunately - leaving that to more knowledgeable folks. The reason this is happening to me appears to be related to linux's boot. I am guessing that Xorg's keyboard dies when linux's /bin/login or so initialises the keyboard. (XFree86 never did this.) This originally happened to me, I think, because the linux RC scripts launched X before all other services were finished. One of the services starting later was - in my initial setup - sendmail with an invalid configuration file which caused it to pause for two minutes. After that, the end of the boot would kill my keyboard. This is now gone, and I've seen Xorg without ever responding to keyboard events. (Which is worse than initially.) I've now delayed X startup (/etc/inittab only brings me to level 3). Then I log in to the console and say "telinit 5" to start X. In this configuration, everything works. Modifying inittab again brings me back to the bad state. So I'm now thinking that Xorg and the bootup interfere with eachother, leaving Xorg in a bad state no matter in which order they pass by eachother. Does this help anyone ? Otherwise, I'm pleased to say that X11r6.8 appears to work nicely on my Mandrake 10.0 .
Confirmed on athlon-xp Gentoo Linux with both via and nforce2 chipsets. Switching to "evdev" protocol appears to be helping. still no idea what is causing this or why it is happening. interesting note? logging out via use of just the mouse, gdm loads up and the keyboard works again. repeatable, sort of. WTF?
Confirmed on a AMD Athlon 64. Running Gentoo 64 with 512 mb's ram. Xorg 6.8.0 with KDE 3.3.0 and Kernel 2.6.9-rc2. Keyboard stops responding, all applications work as if there were no problem, however the keyboard acts as if it has been unplugged. Video drivers are Nvidia, motherboard chipset is Via on a Abit KV8.
switched to evdev protocol for input devices (2 mouse devices, 2 keyboards). have not experienced problem since.
(In reply to comment #9) (Mandrake 9.2, P4-2.4, 1GB RAM, xorg 6.8.1) Same pb for me; the bug appears when starting X at boot (with kdm), and disappears if I log in on console and then startx.
(Mandrake 10.1, P4-3.0, 1GB RAM, xorg 6.8.1) I get the same reaction with 1 exception, my keyboard never works. I tried everything listed above with no luck.
I also see this, and like Russel can't do anything to get the keyboard working. I'm on a centrino notebook. The only way I can type anything is via an attached USB Keyboard, which before my update from 6.7.0 to 6.8.0/1 just worked in parallel with the internal keyboard. I just hope somebody has got a hint how to cure this?
Today I found that things go back to normal for me if I switch from my freshly installed 2.6.9 kernel back to 2.6.8.1. Hope that helps...
Update. If boot to level 3, wait 2 mins and then start X with "telinit 5" then my keyboard works. Just like danny backx in comment #9.
Hello All, Just another comment to confirmed this bug. My motherboard is an Asus A7N266-E with nforce2 integrated. The server X (6.7.0-3mdk: Mandrake10.1) freezes just after login. The keyboard is dead whereas the mouse still active but nothing can be done. There is no special error message within logs !!! I hope that someone will resolve this bug.
I hope someone is reading this old bugreport, because this describes exactly the behaviour of my keyboard with the modular Xorg. I'll attach xorgs.log, if this happens again.
Created attachment 4350 [details] xorgs log I think the problem only occurs, if there is some mouse and keyboard action...Never experience this bug during hacking text.
I'm also having this problem on x.org 6.9/slackware current. I boot into console and start X with startx. It sometimes takes hours and sometimes only half an hout till my keyboard stops responding. The Num key doesn't toggle the light. Everything is back to normal as soon as I exit X (keyboard works on console).
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
+1. I think bug 7270 is a duplicate of this. I'm running current xorg git, seeing the issue on an AMD64 (Ubuntu Gutsy pre-release based) laptop. I'm happy to do some work on diagnosing this if noone else has the time. It's annoying enough to make me want to! Not sure why this was put in the driver/via category. Changing to input/keyboard if bugzilla will let me.
(In reply to comment #23) > +1. I think bug 7270 is a duplicate of this. Person in 7270 seems to have basic functionality, just not VT switching or keyboard maps. What one of my F7 users is experiencing, like this report, is complete loss of keyboard responsiveness. It's not hardware as /dev/input/input1 does show keyboard activity.
Ok. I'm still seeing output from xev, but some higher level in the feeding chain seems to be throwing away some keystrokes. In my case, when it happens, modifiers stop working, and so do some other keys (Home, End etc), but a-z and backspace keep working. That's not what you're seing?
I also see this - a seemingly dead keyboard (num lock doesn't toggle light) but yet the /dev/input is seeing the input. I also see problems with the mouse too (hardly to repro). Both are USB and I'm running Debian etch on AMD64 with ii xorg 7.1.0-19 X.Org X Window System Thanks, Michael
(In reply to comment #25) > Ok. I'm still seeing output from xev, but some higher level in the feeding > chain seems to be throwing away some keystrokes. In my case, when it happens, > modifiers stop working, and so do some other keys (Home, End etc), but a-z and > backspace keep working. That's not what you're seing? If you have a second machine, you could figure out where the stuff disappears. Run X from gdb and put a breakpoint on xf86PostKeyboardEvent. If this breakpoint is hit (but nothing happens), the server loses the event. If not, then the driver does. Do you have a reproducable testcase?
I'm now convinced it's triggered by VMware; I don't see the issue anymore unless I use VMware and when I do see the issue it's fixed by going into system->preferences->keyboard (Gnome) and selecting a different "Keyboard model" in the Layouts tab. HTH
> --- Comment #28 from Nigel Cunningham <nigel@nigel.suspend2.net> 2008-07-16 16:02:52 PST --- > I'm now convinced it's triggered by VMware; I don't see the issue anymore > unless I use VMware and when I do see the issue it's fixed by going into > system->preferences->keyboard (Gnome) and selecting a different "Keyboard > model" in the Layouts tab. does this mean that it happens when you run _inside_ vmware or when you run vmware as a client?
When I run vmware as a client and switch focus from VMware to another app - that's when I have a chance of seeing it. I think it may be related to whether keys are being pressed in the VMware guest as I move the mouse out of the guest window, but am not completely sure of that. (I really should give it a test, but never seem to find the time).
No response in a few years and the previous assumption that this is a VMWare bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.