On Fri, Oct 23, 2009 at 11:21:10AM +0200, Éric Piel wrote: > 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 :-) Yes, it would - "rescan" causes input device teardown and creationa new one. This causes a hotplug event that is processed by X and it adds a new device in place of the old one that it decided to disable (due to keys change). > Even more > interestingly, the key bitmap has changed. > Right, your init scripts/UDEV/HAL whatever adjust keymap to match your laptop. > 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: Hadlers=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 Yep, note that the previous instance had rfkill bound, that means the device had KEY_WLAN or KEY_BLUETOOTH in it's keymap but this one does not. None of these key codes are in in-kernel keymaps for atkbd; they were added afterwards. Now, all depends on when this adjustment happens... In your case it looks like X server starts before the keymap is adjusted, so on first resume the keymaps are different and it disables the device. > B: EV=120013 > B: KEY=20000 20000000020 0 0 500f02100003 3803078f900d401 > feffffdfffefffff ffffffffffffffff > B: MSC=10 > B: LED=7 > > Was this expected? So yes, kind of expected for laptops. > > > 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). I can see them not wanting to use the same device if it changed form keyboard to a mouse (think USB) but differnces in keymaps should be left alone I think. As for duplicates, they could just check sysfs path to see if they are dealing with the same device or not. Input code does not re-use 'inputX', X will be monotonically increasing. -- Dmitry -- 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
