From: Dmitry Torokhov <dmitry.torokhov@gmail.com> To: "Éric Piel" <eric.piel@tremplin-utc.net> Cc: Greg KH <gregkh@suse.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "linux-input@vger.kernel.org" <linux-input@vger.kernel.org> Subject: Re: [REGRESSION] "bind" a device to a driver doesn't not work anymore Date: Fri, 23 Oct 2009 09:31:13 -0700 [thread overview] Message-ID: <20091023163113.GA7707@core.coreip.homeip.net> (raw) In-Reply-To: <4AE17586.9020009@tremplin-utc.net> 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
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Torokhov <dmitry.torokhov@gmail.com> To: "Éric Piel" <eric.piel@tremplin-utc.net> Cc: Greg KH <gregkh@suse.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "linux-input@vger.kernel.org" <linux-input@vger.kernel.org> Subject: Re: [REGRESSION] "bind" a device to a driver doesn't not work anymore Date: Fri, 23 Oct 2009 09:31:13 -0700 [thread overview] Message-ID: <20091023163113.GA7707@core.coreip.homeip.net> (raw) In-Reply-To: <4AE17586.9020009@tremplin-utc.net> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-10-23 16:31 UTC|newest] Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-10-14 2:05 [REGRESSION] "bind" a device to a driver doesn't not work anymore Dmitry Torokhov 2009-10-14 2:05 ` Dmitry Torokhov 2009-10-15 17:24 ` Éric Piel 2009-10-15 18:13 ` Dmitry Torokhov 2009-10-15 18:13 ` Dmitry Torokhov 2009-10-15 18:27 ` Dmitry Torokhov 2009-10-15 18:27 ` Dmitry Torokhov 2009-10-15 19:32 ` Éric Piel 2009-10-15 19:51 ` Dmitry Torokhov 2009-10-15 19:51 ` Dmitry Torokhov 2009-10-15 21:33 ` Éric Piel 2009-10-15 21:59 ` Dmitry Torokhov 2009-10-15 21:59 ` Dmitry Torokhov 2009-10-15 22:44 ` Éric Piel 2009-10-21 19:34 ` Éric Piel 2009-10-21 20:20 ` Dmitry Torokhov 2009-10-21 20:20 ` Dmitry Torokhov 2009-10-22 16:10 ` Éric Piel 2009-10-22 16:22 ` Dmitry Torokhov 2009-10-22 16:22 ` Dmitry Torokhov 2009-10-22 17:48 ` Éric Piel 2009-10-22 17:48 ` Éric Piel 2009-10-22 18:19 ` Dmitry Torokhov 2009-10-22 18:19 ` Dmitry Torokhov 2009-10-22 18:32 ` Dmitry Torokhov 2009-10-22 18:32 ` Dmitry Torokhov 2009-10-23 8:08 ` Éric Piel 2009-10-23 8:58 ` Dmitry Torokhov 2009-10-23 8:58 ` Dmitry Torokhov 2009-10-23 9:21 ` Éric Piel 2009-10-23 9:21 ` Éric Piel 2009-10-23 16:31 ` Dmitry Torokhov [this message] 2009-10-23 16:31 ` Dmitry Torokhov 2009-10-25 11:47 ` Éric Piel 2009-10-25 19:07 ` Dmitry Torokhov 2009-10-25 19:07 ` Dmitry Torokhov -- strict thread matches above, loose matches on Subject: below -- 2009-10-11 0:04 Éric Piel 2009-10-11 3:00 ` Greg KH 2009-10-12 4:35 ` Dmitry Torokhov 2009-10-12 11:46 ` Éric Piel 2009-10-12 14:44 ` Greg KH 2009-10-12 14:44 ` Greg KH 2009-10-12 15:45 ` Dmitry Torokhov 2009-10-12 15:45 ` Dmitry Torokhov 2009-10-12 17:37 ` Greg KH 2009-10-12 17:37 ` Greg KH 2009-10-12 15:48 ` Dmitry Torokhov 2009-10-12 16:48 ` Éric Piel 2009-10-12 16:48 ` Éric Piel 2009-10-12 17:35 ` Greg KH 2009-10-12 18:33 ` Dmitry Torokhov 2009-10-12 18:54 ` Greg KH 2009-10-12 19:20 ` Dmitry Torokhov 2009-10-12 19:58 ` Greg KH 2009-10-13 3:17 ` Dmitry Torokhov 2009-10-18 7:51 ` Dmitry Torokhov 2009-10-18 8:02 ` Greg KH 2009-10-23 2:01 ` Dmitry Torokhov 2009-10-26 20:59 ` Greg KH 2009-10-26 21:34 ` Dmitry Torokhov 2009-10-26 23:59 ` Greg KH 2009-10-27 16:16 ` Dmitry Torokhov 2009-10-13 9:52 ` Éric Piel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20091023163113.GA7707@core.coreip.homeip.net \ --to=dmitry.torokhov@gmail.com \ --cc=eric.piel@tremplin-utc.net \ --cc=gregkh@suse.de \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.