Bug 18622 - After the last xorg update the keyboard doesn't work on the console anymore
Summary: After the last xorg update the keyboard doesn't work on the console anymore
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/Keyboard (show other bugs)
Version: 7.4 (2008.09)
Hardware: All Linux (All)
: medium major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-18 21:29 UTC by Heiko Baums
Modified: 2018-06-12 19:09 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg.conf (6.65 KB, text/plain)
2008-11-19 08:14 UTC, Heiko Baums
no flags Details
Xorg.0.log from Gentoo (14.51 KB, text/plain)
2008-11-19 08:15 UTC, Heiko Baums
no flags Details
dmesg from Gentoo (15.09 KB, text/plain)
2008-11-19 08:16 UTC, Heiko Baums
no flags Details
Xorg.0.log from Archlinux (25.54 KB, text/plain)
2008-11-19 08:16 UTC, Heiko Baums
no flags Details
dmesg from Archlinux (20.30 KB, text/plain)
2008-11-19 08:17 UTC, Heiko Baums
no flags Details

Description Heiko Baums 2008-11-18 21:29:48 UTC
A few days ago I did the last system updates on Gentoo and on Archlinux which also updated one or more parts of 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, 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. This bug occurs on Gentoo as well as on Archlinux.

Please tell me, which informations you need.
Comment 1 Heiko Baums 2008-11-19 08:14:44 UTC
Created attachment 20445 [details]
xorg.conf
Comment 2 Heiko Baums 2008-11-19 08:15:36 UTC
Created attachment 20446 [details]
Xorg.0.log from Gentoo
Comment 3 Heiko Baums 2008-11-19 08:16:16 UTC
Created attachment 20447 [details]
dmesg from Gentoo
Comment 4 Heiko Baums 2008-11-19 08:16:44 UTC
Created attachment 20448 [details]
Xorg.0.log from Archlinux
Comment 5 Heiko Baums 2008-11-19 08:17:05 UTC
Created attachment 20449 [details]
dmesg from Archlinux
Comment 6 Heiko Baums 2008-11-19 08:23:48 UTC
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.
Comment 7 Heiko Baums 2008-11-19 18:02:29 UTC
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).
Comment 8 Heiko Baums 2008-11-19 18:08:12 UTC
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.
Comment 9 Peter Hutterer 2008-12-02 22:53:41 UTC
(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?
Comment 10 Heiko Baums 2008-12-03 07:33:12 UTC
(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?
Comment 11 Peter Hutterer 2008-12-03 20:14:18 UTC
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?
Comment 12 Heiko Baums 2008-12-04 03:31:31 UTC
(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.
Comment 13 Heiko Baums 2009-04-01 06:37:35 UTC
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.
Comment 14 Heiko Baums 2009-05-28 19:13:45 UTC
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
Comment 15 Michael Snoyman 2009-08-02 23:29:24 UTC
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.
Comment 16 Adam Jackson 2018-06-12 19:09:12 UTC
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.


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.