Re: [REGRESSION] "bind" a device to a driver doesn't not workanymore

[Dmitry Torokhov]

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