On Tue, 2010-03-30 at 15:32 +0000, Alan Stern wrote:
> > Apparently, this is because the vendor is stupid and has re-used the USB
> > ID and descriptor for all kinds of scanner interfaces, not all of which
> > behave like a keyboard.
> What difference does that make? The ID doesn't matter; only the HID
> descriptor and report descriptors matter.
>
Presumably, some of these devices do not implement any kind of HID
interface despite claiming otherwise.
… the blacklist entry is there for a reason, after all … even if the
patch doesn't say why, or even if, just unbinding the thing via udev or
whatever won't fix the problem they've fixed with that blacklist entry.
commit d1d3a5f6eaee337d793ab9ac28e696f0262c3c8a
Author: Remi Cattiau <remi@xxxxxxxxxxx>
Date: Tue Sep 9 01:39:33 2008 +0200
HID: ignore iBuddy devices
iBuddy devices claim to be HID devices, but they are not.
Add them to the blacklist.
Signed-off-by: Remi Cattiau <remi@xxxxxxxxxxx>
Signed-off-by: Jiri Kosina <jkosina@xxxxxxx>
> There is no way to tell what triggered a probe.
>
There probably should be, IMHO.
Would anybody have a problem with a patch that implements something like
that?
> What happens if you simply remove the backlist entry?
>
The thing works. But that isn't the problem; I won't start playing the
"yes blacklist"/"no blacklist" patch game, and we're supposed to be past
the 'compile your own kernel to fix a problem' days. :-P
-- Matthias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
