From: "Éric Piel" <eric.piel@tremplin-utc.net> To: Dmitry Torokhov <dmitry.torokhov@gmail.com> 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 11:21:10 +0200 [thread overview] Message-ID: <4AE17586.9020009@tremplin-utc.net> (raw) In-Reply-To: <20091023085824.GA7199@core.coreip.homeip.net> 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
WARNING: multiple messages have this Message-ID (diff)
From: "Éric Piel" <eric.piel@tremplin-utc.net> To: Dmitry Torokhov <dmitry.torokhov@gmail.com> 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 11:21:10 +0200 [thread overview] Message-ID: <4AE17586.9020009@tremplin-utc.net> (raw) In-Reply-To: <20091023085824.GA7199@core.coreip.homeip.net> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-10-23 9:21 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 [this message] 2009-10-23 9:21 ` Éric Piel 2009-10-23 16:31 ` Dmitry Torokhov 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=4AE17586.9020009@tremplin-utc.net \ --to=eric.piel@tremplin-utc.net \ --cc=dmitry.torokhov@gmail.com \ --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.