A few days ago I did the last `emerge -uDN @system @world` which also updated one or more parts of x11-base/xorg. Now when I log into an xorg session - doesn't matter if it's KDE or Xfce - the keyboard seems to work in X, but if I switch to the console by pressing Ctrl-Alt-F1, the keyboard doesn't work anymore. I have to press very often onto one key, before the keyboard and bash react. It's so extreme that I can't do anything on the console, when I'm logged in an X session. When I switch back to X by pressing Alt-F7, the keyboard is responding much better but not as fast as it did after the first X login. As soon as I log out and only see the graphical login manager, in my case slim, because kdm-3.5.9 also doesn't work anymore, the keyboard works correctly and reacts as fast as usual in slim as well as on the console. I don't get any error messages. And I think this is an upstream bug, because I've got the same problem on Archlinux, too. Please tell me, which informations you need.
Filed a bug report to upstream, too. https://bugs.freedesktop.org/show_bug.cgi?id=18622
Created attachment 172381 [details] xorg.conf
Created attachment 172382 [details] Xorg.0.log
Created attachment 172384 [details] dmesg.log
Created attachment 172386 [details] emerge --info
Created attachment 172388 [details] Xorg.0.log from Archlinux
Here are some logfiles. The error messages in Xorg.0.log appear only since the last xorg update. With previous versions I didn't have these error messages. They also seem to be Gentoo specific, because I don't have these error messages on Archlinux. On Archlinux I have some different error messages regarding the keyboard, after I've logged in into an X session. But on both distributions I've got the same keyboard problem, described in my original bugreport. I've also attached my Xorg.0.log from Archlinux, just in case. Maybe it helps. I'm using the same xorg.conf on both distributions and on both distributions I have installed hal and xf86-input-evdev. On Gentoo I've also tried to uninstall xf86-input-evdev, because I don't need it, but this didn't change anything.
After thinking about this problem and trying a bit more, I found out something very interesting. Because there's still only slim-1.3.0, which I can't use due to some bugs, in the official Archlinux repositories, I always logged into the text console (vt/1) and started X by running startx on Archlinux. If I needed the text console during the X session, I needed to switch to vt/2 (Ctrl-Alt-F2). The keyboard worked perfectly as usual. Now that I found an updated slim package in AUR (Arch User Repository) and updated to slim-1.3.1 on Archlinux, I start slim at boottime on Archlinux. When I now need the text console during an X session I switch to vt/1 (Ctrl-Alt-F1). And since then I have these problems. Now I've tried not to load X at boottime on Gentoo, logged into the text terminal (tty1), started X by running startx (I've hardly ever done this on Gentoo before) and switched to tty2 (Ctrl-Alt-F2). Lo and behold! The keyboard works perfectly again. Then I've started X on Gentoo at boottime again, logged into an X session, switched to tty2 (Ctrl-Alt-F2) and the keyboard works again. Then I've switched to tty1 (Alt-F1) and the keyboard problem appeared again, but only on tty1 not on tty2. So on both Gentoo and Archlinux this problem occurs only on the first text console (tty1 on Gentoo and vt/1 on Archlinux).
The keyboard problem on the first text console only appears, when an X session (KDE or Xfce) is running. When only slim is running or X is not running, the keyboard reacts perfectly also on the first console.
Just to make sure, you're using xorg-server 1.5.3, right ? Cause this looks like a configuration problem or a misunderstanding. I've never used 'start X at boot' option, but I suspect it's starting X at vt7, but from vt1, doesn't it (I'm asking about the tty, where the messages of xorg-server starting go) ?
I'm sure I have seen a similar bug before...
(In reply to comment #10) > Just to make sure, you're using xorg-server 1.5.3, right ? I'm using xorg-server 1.5.2 on Gentoo. But on Archlinux, where I have the same problem, I'm using xorg-server 1.4.2. > Cause this looks like a configuration problem or a misunderstanding. But neither on Gentoo nor on Archlinux I have changed anything at the xorg configuration. I've downgraded udev from 130 to 125. My first impression was, that now the keyboard reacts a bit faster again on vt1 with udev 125 but not so much. It's quite curious, but I can't say, what was updated during my `emerge -uDN world` last week. There have been 290 packages updated. > I've never used 'start X at boot' option, > but I suspect it's starting X at vt7, but from vt1, doesn't it > (I'm asking about the tty, where the messages of xorg-server starting > go) ? X is always starting at vt7 when started at boottime by /etc/init.d/xdm start and when started from vt1 by startx. Or can this something have to do with fbsplash and fbcondecor? But I don't think so, because both weren't updated before the keyboard problem occured. And on Archlinux I deactivated fbsplash and booted with the official Archlinux stock kernel, which doesn't include fbcondecor, but the problem was still there.
It can be, that this bug is not a bug in xorg but in slim, because on Arch Linux I now installed gdm in addition to slim and don't have this problem, when using gdm instead of slim. See my bug report for slim: http://developer.berlios.de/bugs/?func=detailbug&bug_id=15769&group_id=2663
Not sure what slim does exactly, but if you can't reproduce with gdm, then let's reassign this to slim's maintainer :) Thanks
Upstream slim is rather dead. I haven't seen any activity from them in ages. I wouldn't hold my breath for them to fix anything. As for your issue, sorry to say but I have no idea. I don't notice anything wrong in my installation. =/
I am having a similar problem: no keyboard after switching to vt and back to X, or doing suspend and resume, but if I restart the xdm (kdm) during the first switch to vt all works fine XServer: 1.5.3-r6 KDM: 3.5.10 HAL: 0.5.11-r9 it looks like the kdm is started to early in the boot process, or something similar, but the startDM.sh-line in /etc/inittab is present btw I am not the only one: http://forums.gentoo.org/viewtopic-t-767024-highlight-.html
Do any of you have xdm in the "boot" rc, instead of "default"? Thanks
no, sorry, xdm starts in runlevel 3 ( after hdparm, rsyslog, acpid, dbus, eth0, nscd, ahaaal and gpm ) but I have found a difference in the log files: [code] gms1 ~ # diff -U0 x1.log x2.log --- x1.log 2009-07-07 21:13:40.000000000 +0200 +++ x2.log 2009-07-07 21:14:10.000000000 +0200 @@ -14 +14 @@ -(==) Log file: "/var/log/Xorg.0.log", Time: Tue Jul 7 21:12:10 2009 +(==) Log file: "/var/log/Xorg.0.log", Time: Tue Jul 7 21:13:50 2009 @@ -296,2 +296 @@ -(EE) AT Translated Set 2 keyboard: device key_bitmask has changed -(EE) AT Translated Set 2 keyboard: Device has changed - disabling. +(II) AT Translated Set 2 keyboard: Device reopened after 1 attempts. [/code] x1.log: kdm started from rc -> vt1 -> kdm ( no keyboard ) -> vt1 ( using the 'console login' menu item ) x2.log: restarting kdm -> vt1 -> kdm ( working keyboard ) -> vt1
using goolge ( seaching for 'keyboard: device key_bitmask has changed' ) I have found the solution for my issue : http://bugs.gentoo.org/show_bug.cgi?id=273067 @Heiko sorry for hijacking this case
(In reply to comment #19) > using goolge ( seaching for 'keyboard: device key_bitmask has changed' ) I have > found the solution for my issue : > http://bugs.gentoo.org/show_bug.cgi?id=273067 This is a different issue, because I didn't have the error messages mentioned in this bug. And my keyboard problems don't occur in X after returning from the text console to X (Alt+F7). My keyboard problems appear on the first text console after switching from X (Ctrl+Alt+F1).
And this bug seems to be related to slim, because I don't have this problem with gdm.
This is an old bug, reopen if there is still issues with currently stable packages.
Still have this issue with xorg 1.10.2 and 0.9.5 . Looks like bug connected with evdev.
(In reply to comment #23) > Still have this issue with xorg 1.10.2 and 0.9.5 . Looks like bug connected > with evdev. 1.9.5 sorry
