Bug 18622

Created attachment 20445 [details]
xorg.conf

Created attachment 20446 [details]
Xorg.0.log from Gentoo

Created attachment 20447 [details]
dmesg from Gentoo

Created attachment 20448 [details]
Xorg.0.log from Archlinux

Created attachment 20449 [details]
dmesg from Archlinux

Here are some logfiles.

The error messages at the end of Xorg.0.log from Archlinux only appear after the login into an X session. When only the graphical login manager, in my case slim, is loaded, these error messages are not there.

The error messages at the end of Xorg.0.log from Gentoo appear directly when the graphical login manager is loaded, but on both distributions the keyboard problems only occur after the login into an X session as described in my original bugreport.

On both distributions the error messages appear only since the last xorg update. With previous versions I didn't have these error messages. On both distributions the error messages are different, but the keyboard problem described in my original bugreport is the same on both distributions.

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.

(In reply to comment #6)
> 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.

As long as AutoAddDevices "false" is in the config, evdev won't load anyway.
Can you reproduce the problems without this option?

(In reply to comment #9)
> As long as AutoAddDevices "false" is in the config, evdev won't load anyway.
> Can you reproduce the problems without this option?

In the meantime I removed AutoAddDevice "false" and the keyboard and mouse sections from my xorg.conf, configured hal for my keyboard and mouse, and switched to evdev on both Gentoo and Archlinux and the problem still exists.

But I've found out that, when the problem first occurred on both distributions, on Gentoo I had installed xorg 5.2 and on Archlinux I had installed xorg 4.2.

So this probably doesn't have anything to do with new xorg features.

I also thought about fbsplash and fbcondecor to be in conflict with xorg, because they need the kernel parameter console=tty1. But I had to temporarily uninstall fbsplash and fbcondecor on Archlinux and the problem still exists. So fbsplash can't be the reason.

Maybe it's a conflict with another package, which was recently updated. Unfortunately I can't tell which packages I had updated. Maybe udev, dbus or hal? I can't imaging how this can affect the keyboard, but can this be a problem with the latest nvidia binary drivers?

uhm. xorg is on either 7.X or xserver 1.x. there's no 5.2 or 4.2 version.
what does the first line of your xorg.log say?

(In reply to comment #11)
> uhm. xorg is on either 7.X or xserver 1.x. there's no 5.2 or 4.2 version.
> what does the first line of your xorg.log say?

Sorry, forgot the 1. in the version.

It's xserver 1.5.2 and 1.4.2.
And it's xorg 7.4 and I guess 7.2.

This issue still exists with xserver 1.6.0.
Changed Hardware from x86 to All, because x86_64 systems are also affected by this bug.

It can be, that this bug is not a bug in xorg but in slim, because 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

I just installed ArchLinux, and noticed that when I'm in X, the console acts funny wrt keys pressed. I am *not* using Slim; I use Gnome and Xmonad. I haven't done full testing to know exactly what combination causes the problem.

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.