All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.