Use hid blacklist in usbmouse/usbkbd

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(-)

index a255285..50e4165 100644
@@ -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.

index 775a1ef..a9cca6e 100644
@@ -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));
 

index f8ad691..c403ce9 100644
@@ -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

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

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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.

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

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