linux-kernel - Re: [REGRESSION] "bind" a device to a driver doesn't not work anymore

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AE17586.9020009@tremplin-utc.net>
Date:	Fri, 23 Oct 2009 11:21:10 +0200
From:	Éric Piel <eric.piel@...mplin-utc.net>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Greg KH <gregkh@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>
Subject: Re: [REGRESSION] "bind" a device to a driver doesn't not  work	anymore

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/