Op 23-10-09 10:58, Dmitry Torokhov schreef: > On Fri, Oct 23, 2009 at 10:08:41AM +0200, Éric Piel wrote: >> Op 22-10-09 20:19, Dmitry Torokhov schreef: >>> On Thu, Oct 22, 2009 at 07:48:47PM +0200, Éric Piel wrote: >>>> I don't think so: xorg 1.6.5, with xinput-evdev 2.2.5. They are both >>>> latest or second latest stable versions. >>>> >>>> In the log I see this: >>>> (--) 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. >>>> >>>> Quite a few people seem to have the same problem. >>> The bitmask should not be changing on it's own... Any chance you could >>> save contents or /proc/bus/input/devices before suspend and after resume >>> (when X decides to ditch the keyboard) and diff them? >>> >> Hello, >> I've just tried this: before and after is exactly the same (attached is >> a copy of it). >> > > What about before X starts? Can you please boot into console, kill > hal and udev to make sure they don't mess up with the keymap and, after > doing > > echo -n rescan > /sys/bus/serio/devices/serio0/drvctl > > which should completely reinitialize keyboard and compare > /proc/bus/input/devices again? If it is still the same then there must > be a silly bug in X's evdev... Ok, I'll reboot later and try. In the mean time, I've just tried this on my non-working keyboard, and it resurrected it :-) Even more interestingly, the key bitmap has changed. Before: 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 After: 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/input15 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 Was this expected? > But regardless, X policy of comparing > keybit is stupid - they don't kill the device if I change keymap while > in X, why do they do that on resume? Or when I change the limits on > absolute axis... Oh well. With respect to this bug, I have opened a bug report for xorg: https://bugs.freedesktop.org/show_bug.cgi?id=24687 Indeed, evdev tend to disable for plenty of different reason the keyboard (cf src/evdev.c: EvdevCacheCompare()). The source code is not very clear why they do this, but somehow I was under the impression that it was to avoid using twice the same device (with slightly different properties). See you, Eric -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
