When I resume from suspend-to-ram for the first time after a reboot, my ps2 keyboard does not work anymore. The only way to get it back without restarting the X server is to unbind/bind the i8042 device or to rmmod/modprobe the atkbd module. Passed the first resume, the other resumes never trigger this problem. The keyboard keeps working at the kernel level (eg, evtest shows all the keys pressed and released), but in Xorg it is gone. The Xorg log says: (--) SynPS/2 Synaptics TouchPad: touchpad found (II) PS/2 Generic Mouse: Device reopened after 1 attempts. (EE) AT Translated Set 2 keyboard: device key_bitmask has changed (EE) AT Translated Set 2 keyboard: Device has changed - disabling. This is happening on my 64 bit linux, with kernel 2.6.31 (but it happens with every other versions as well), xorg-server 1.6.5, and input-evdev 2.2.5. It affects only my ps2 keyboard, never the usb one. Another important point too note is that /proc/bus/input/devices is exactly identical before and after suspend (so the key_bitmask hasn't changed). An extract of this file: I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/devices/platform/i8042/serio0/input/input4 U: Uniq= H: Handlers=kbd event4 evbug rfkill B: EV=120013 B: KEY=20 0 0 30400f02100000 17803878f800d401 feffffdfffefffff ffffffffffffffff B: MSC=10 B: LED=7 It seems to be the same bug as those downstream ones: http://bugs.gentoo.org/show_bug.cgi?id=247543 http://bugs.gentoo.org/show_bug.cgi?id=273067 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/327175 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/437862
Actually I was wrong, when X starts the keymap is different, and looks like this: I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/devices/platform/i8042/serio0/input/input4 U: Uniq= H: Handlers=kbd event4 evbug B: EV=120013 B: KEY=20000 20000000020 0 0 500f02100003 3803078f900d401 feffffdfffefffff ffffffffffffffff B: MSC=10 B: LED=7 A few seconds later, an init script changes the keymap (using setkeycodes). All goes fine... until the laptop is suspended to ram. At resume suddenly evdev decides to rescan every device and the keymap being different, it disable the keyboard. So it seems the problem is that evdev thinks a different keymap should lead to disabling the device. What is the goal of this? Is it because evdev should detect it as a new device and reinitialize everything? Dmitry Torokhov (maintainer of the input subsystem in the Linux kernel) says that a new device will always have a different path name (inputX) so checking this path should be sufficient to detect if a device is new or not.
commit a0f7f34dc5effc5822c618bfbf3a0872669c30ad Author: Dmitry Torokhov <dmitry.torokhov@gmail.com> AuthorDate: Mon Nov 2 23:11:55 2009 -0800 Relax checks when reopening devices
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.