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.


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

Reply via email to