[SOLVED] repeatedly non-functioning keyboard after update
DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've got a very annoying problem with my system and I'm hoping someone reading this can help me. A few weeks ago I uninstalled the fglrx driver and replaced it with the open source drivers for ati graphic cards from the repositories.
After the next update and a reboot after a few days, my ps/2 keyboard stopped working.
Everything else works just fine, except for the keyboard.
To be more precise:
I run a Debian testing on my 64bit system.
The following is happening: When I boot the system and wait, I end up with the login from my login manager (gdm3). I can use the mouse but not the non-functional keyoard (Numlock works until gdm3 is started).
When I boot into recovery mode, su username and execute startx, everything is fine and shiny, i.e. keyboard works. But that's not the way I want to start my system regularly.
When I boot into recovery mode, su username and start gdm/gdm3/slim manually, the keyboard becomes non-functional.
I read all the posts in forums I could find about similar problems but nothing helped (restart udev, manipulate the xorg.conf, use no xorg.conf, etc.).
I'm not sure where exactly the problem is located since the keyboard itself is obviously working (recovery mode, see above). Is it udev (1.72-1, and no HAL), evdev, the transition from HAL to udev (/run issue) or is it something hidden in the different way of starting the x-server, either via startx or gdm/gdm3/slim?
It seems to me the problem is beyond my powers so I'm asking here for help.
Have you compared /var/log/Xorg.0.log when the keyboard is working to when it is not working. Debian now sees a PS/2 keyboard as a USB device so make sure HID is working correctly.
' dpkg-reconfigure -a ' should reconfigure everything on your system. dpkg-reconfigure will download and reinstall templates, see the man page for details.
Have you compared /var/log/Xorg.0.log when the keyboard is working to when it is not working. Debian now sees a PS/2 keyboard as a USB device so make sure HID is working correctly.
' dpkg-reconfigure -a ' should reconfigure everything on your system. dpkg-reconfigure will download and reinstall templates, see the man page for details.
Hi 62chevy,
no I haven't, but now I have compared the two logs. Interestingly, there is no difference between the two of them. Only when I boot via the recovery mode I log out from the session and I see the termination of the x-server in the log. But I think this should be okay.
I have done a little bit more research and I found something interesting. When I boot normally and I end up at the login screen, the keyboard is not responding. I log onto my system via ssh and I use 'evtest'. I see signals from my mouse but I do not see any signals from the keyboard. When I boot via the recovery mode, using evtest I see the mouse as well as the keyboard sending signals.
It seems to me that the keyboard is recognized properly in both cases but when gdm3 is involved something "related to the keyboard" is "messed up".
With regard to your information about "ps/2 keyboards are now seen as usb keyboards" I found the following in /dev/input/by-path:
platform-i8042-serio-0-event-kbd -> ../event0
I must confess I don't really know what this is about. But I do know that this should link the keyboard to the event0. However, "serio" and "kbd" confuse me as to their relevance to usb keyboards.
Does anyone know whether this makes sense and if not, can anyone tell me how to change it so that it will make sense?
When you are logged in on console the kernel handles the keyboard but when use a GUI (gdm etc.) then X handles the keyboard and mouse.
Quote:
DESCRIPTION
evdev is an Xorg input driver for Linux´s generic event devices. It therefore supports all input devices that the kernel knows about, including most mice, key‐
boards, tablets and touchscreens. evdev is the default driver on the major Linux distributions.
The evdev driver can serve as both a pointer and a keyboard input device. Multiple input devices are supported by multiple instances of this driver, with one Input‐
Device section of your xorg.conf for each input device that will use this driver.
It is recommended that evdev devices are configured through the InputClass directive (refer to xorg.conf(5)) instead of manual per-device configuration. Devices con‐
figured in the xorg.conf(5) are not hot-plug capable.
SUPPORTED HARDWARE
In general, any input device that the kernel has a driver for can be accessed through the evdev driver. See the Linux kernel documentation for a complete list.
I cannot really use the information of the evdev man page because I do not know how to check all the points mentioned there. I suppose the kernel was able to handle the keyboard - at least until before the update.
Nevertheless, thank you for your Xorg.0.log part relating to your keyboard. Here is the corresponding part of the log for my x-server:
Code:
[ 29723.328] (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event0)
[ 29723.328] (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall"
[ 29723.328] (**) AT Translated Set 2 keyboard: Applying InputClass "AT Translated Set 2 keyboard"
[ 29723.328] (II) Using input driver 'evdev' for 'AT Translated Set 2 keyboard'
[ 29723.328] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[ 29723.328] (**) AT Translated Set 2 keyboard: always reports core events
[ 29723.328] (**) AT Translated Set 2 keyboard: Device: "/dev/input/event0"
[ 29723.328] (--) AT Translated Set 2 keyboard: Found keys
[ 29723.328] (II) AT Translated Set 2 keyboard: Configuring as keyboard
[ 29723.328] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio0/input/input0/event0"
[ 29723.328] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD, id 9)
[ 29723.328] (**) Option "xkb_rules" "evdev"
[ 29723.329] (**) Option "xkb_model" "pc104"
[ 29723.329] (**) Option "xkb_layout" "de"
[ 29723.329] (**) Option "xkb_variant" "nodeadkeys"
The interesting point is that "Adding input device" happens before "Loading evdev_drv.so". This is contrary to your log file entries.
# This file lists modules which will not be loaded as the result of
# alias expansion, with the purpose of preventing the hotplug subsystem
# to load them. It does not affect autoloading of modules by the kernel.
# This file is provided by the udev package.
# evbug is a debug tool and should be loaded explicitly
blacklist evbug
# these drivers are very simple, the HID drivers are usually preferred
blacklist usbmouse
blacklist usbkbd
# replaced by e100
blacklist eepro100
# replaced by tulip
blacklist de4x5
# replaced by tmscsim
blacklist am53c974
# these watchdog drivers break some systems
blacklist iTCO_wdt
Make sure you have this file in /etc/modprobe.d
You may not need everything I have but make sure usbkbd is black listed.
my blacklist.conf reads exactly as yours. So, usbkbd is black listed.
It did not help.
But nevertheless, I can report a success. After some investigations triggered by offline communication with a friend of mine I changed the number of VTs in /etc/inittab.
This did the trick. It seems that the problem is some kind of race condition where getty is taking tty7 and thus kills the keyboard.
After this change I was able to boot and at the login screen the keyboard worked. I'm writing this from my main system.
my blacklist.conf reads exactly as yours. So, usbkbd is black listed.
It did not help.
But nevertheless, I can report a success. After some investigations triggered by offline communication with a friend of mine I changed the number of VTs in /etc/inittab.
This did the trick. It seems that the problem is some kind of race condition where getty is taking tty7 and thus kills the keyboard.
After this change I was able to boot and at the login screen the keyboard worked. I'm writing this from my main system.
So, thanks for your time anyway.
speedbob
Code:
# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
# <id>:<runlevels>:<action>:<process>
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6
I believe you are talking about this part of /etc/inittab.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
