[PATCH] Use hid blacklist in usbmouse/usbkbd

[PATCH] Use hid blacklist in usbmouse/usbkbd

[Pascal Terjan]

Hi,
Some devices are blacklisted in hid-quirks, but still get handled by
usbmouse/usbkbd.

That means that if usbmouse is already loaded when a wacom tablet gets
plugged it, it will take it.

This patch fixes this behaviour by using hid's blacklist in usbmouse
and usbkbd, but I don't know much about interactions between hid and
usbmouse/usbkbd so I'm not sure this is the correct way to do it.

So, please voice you opinion :)

(It has been tested to fix wacom support)

---
 drivers/hid/usbhid/hid-quirks.c |    2 ++
 drivers/hid/usbhid/usbkbd.c     |    6 ++++++
 drivers/hid/usbhid/usbmouse.c   |    6 ++++++
 3 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index a255285..50e4165 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -884,6 +884,8 @@ u32 usbhid_lookup_quirk(const u16 idVendor, const u16 idProduct)
 	return quirks;
 }
 
+EXPORT_SYMBOL_GPL(usbhid_lookup_quirk);
+
 /*
  * Cherry Cymotion keyboard have an invalid HID report descriptor,
  * that needs fixing before we can parse it.
diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
index 775a1ef..a9cca6e 100644
--- a/drivers/hid/usbhid/usbkbd.c
+++ b/drivers/hid/usbhid/usbkbd.c
@@ -235,6 +235,12 @@ static int usb_kbd_probe(struct usb_interface *iface,
 	if (!usb_endpoint_is_int_in(endpoint))
 		return -ENODEV;
 
+	if (usbhid_lookup_quirk(le16_to_cpu(dev->descriptor.idVendor),
+				le16_to_cpu(dev->descriptor.idProduct))
+     			& HID_QUIRK_IGNORE) {
+		return -ENODEV;
+	}
+
 	pipe = usb_rcvintpipe(dev, endpoint->bEndpointAddress);
 	maxp = usb_maxpacket(dev, pipe, usb_pipeout(pipe));
 
diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c
index f8ad691..c403ce9 100644
--- a/drivers/hid/usbhid/usbmouse.c
+++ b/drivers/hid/usbhid/usbmouse.c
@@ -131,6 +131,12 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
 	if (!usb_endpoint_is_int_in(endpoint))
 		return -ENODEV;
 
+	if (usbhid_lookup_quirk(le16_to_cpu(dev->descriptor.idVendor),
+				le16_to_cpu(dev->descriptor.idProduct))
+     			& (HID_QUIRK_IGNORE|HID_QUIRK_IGNORE_MOUSE)) {
+		return -ENODEV;
+	}
+
 	pipe = usb_rcvintpipe(dev, endpoint->bEndpointAddress);
 	maxp = usb_maxpacket(dev, pipe, usb_pipeout(pipe));
 
-- 
1.5.3.5

Re: [Linuxwacom-devel] [PATCH] Use hid blacklist in usbmouse/usbkbd

[Ron]

Hi Pascal,

There is a less intrusive way to handle this for any reasonably modern
2.6 kernel...  see the check_driver script in the Debian package.

It's called from udev when the device is plugged and if it is a wacom
tablet, it will repossess it from any other driver and bind it to the
wacom one.

We had a more brutal hack that did this for 2.4 too, but this method
is I believe the recommended one now (or at least supported without
further kernel patching since about 2.6.13-ish).

hth!
Ron


On Mon, Nov 26, 2007 at 11:58:08AM +0100, Pascal Terjan wrote:
> Hi,
> Some devices are blacklisted in hid-quirks, but still get handled by
> usbmouse/usbkbd.
> 
> That means that if usbmouse is already loaded when a wacom tablet gets
> plugged it, it will take it.
> 
> This patch fixes this behaviour by using hid's blacklist in usbmouse
> and usbkbd, but I don't know much about interactions between hid and
> usbmouse/usbkbd so I'm not sure this is the correct way to do it.
> 
> So, please voice you opinion :)

Re: [Linuxwacom-devel] [PATCH] Use hid blacklist in usbmouse/usbkbd

[Pascal Terjan]

On lun, 2007-11-26 at 21:43 +1030, Ron wrote:
> Hi Pascal,
> 
> There is a less intrusive way to handle this for any reasonably modern
> 2.6 kernel...  see the check_driver script in the Debian package.
> 
> It's called from udev when the device is plugged and if it is a wacom
> tablet, it will repossess it from any other driver and bind it to the
> wacom one.
> 
> We had a more brutal hack that did this for 2.4 too, but this method
> is I believe the recommended one now (or at least supported without
> further kernel patching since about 2.6.13-ish).

Yes this can be workarounded in userspace, but why having a blacklist in
HID if the individual usbhid drivers still take the device ? And why
having a driver to handle a device when a better one exists ?

-- 
Pascal Terjan
Ingénieur Conseil
Mandriva (ex Mandrakesoft)
Tel +33 (0) 1 40 41 17 51 - Fax +33 (0) 1 40 41 92 00

-
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

Re: [PATCH] Use hid blacklist in usbmouse/usbkbd

[Jiri Kosina]

On Mon, 26 Nov 2007, Pascal Terjan wrote:

> That means that if usbmouse is already loaded when a wacom tablet gets 
> plugged it, it will take it. This patch fixes this behaviour by using 
> hid's blacklist in usbmouse and usbkbd, but I don't know much about 
> interactions between hid and usbmouse/usbkbd so I'm not sure this is the 
> correct way to do it.

Hi Pascal,

usbmouse and usbkbd shouldn't be loaded at all on a standard system. These 
modules are pretty non-standard and should be used only in really extreme 
cases.

On the other hand you are right that making them honor the 
HID_QUIRK_IGNORE* blacklist entries makes sense.

Could you please add your Signed-off-by to your patch, so that I can take 
it through my tree?

Thanks,

-- 
Jiri Kosina

Re: [Linuxwacom-devel] [PATCH] Use hid blacklist in usbmouse/usbkbd

[Ron]

On Mon, Nov 26, 2007 at 01:46:14PM +0100, Pascal Terjan wrote:
> On lun, 2007-11-26 at 21:43 +1030, Ron wrote:
> > There is a less intrusive way to handle this for any reasonably modern
> > 2.6 kernel...  see the check_driver script in the Debian package.
> 
> Yes this can be workarounded in userspace, but why having a blacklist in
> HID if the individual usbhid drivers still take the device ?

I do agree the other drivers should respect the blacklist, but in the
case of the wacom device, I'm less sure that it should still be in it ...

It was the _only_ answer before we gained the ability to dynamically
rebind devices though.

> And why having a driver to handle a device when a better one exists ?

Internally the device probing doesn't really have any sense of 'better'
at this stage, so the first driver probed that accepts the device will
get it.  The tablet can however work perfectly well with the mouse or
generic evdev driver, so in the _absence_ of a better one, I don't
really see why we should blindly prohibit such degraded operating modes.

(a clear example of the value in that: for the last few weeks we have
not had a working tablet driver for the new XOrg 7.3 ABI -- if the
tablet was not blacklisted, people would still have been able to use
it as a 'mouse-like' device, but right now it's either a useless brick to
them, or they need to hand hack their kernel to remove the blacklisting)

If drivers that support extended features are available, the choice of
which to use really is a policy decision, so it seems appropriate that
this should be under user-space control.  That's what this script does,
it gives the choice of what is 'better' to the local admin without
requiring them to patch/rebuild their kernel to exercise it.

Cheers,
Ron