[argyllcms] Re: [PATCH] usb/hid: Blacklist the Gretag-Macbeth Huey display colorimeter

  • From: Martin Ling <martin-argyll@xxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Fri, 14 Dec 2007 15:52:34 +0000

On Sat, Dec 15, 2007 at 02:22:03AM +1100, Graeme Gill wrote:
> 
> Right, but for an application to work, both the application and
> the driver it is working though have to be compatible with each
> other and the device, so the driver doesn't have enough information
> to make the decision about whether it should be used with the
> device, or whether some other driver should be used instead.
> It should be able to disqualify itself, but it shouldn't be
> able to force itself to be the only possible driver.

Right. And in this case the HID driver should clearly disqualify itself.

> The HID driver cannot necessarily know whether it can be used
> to drive the Huey successfully, since it is only a facilitator
> not the end user of the device.

Of course it can't know in all cases, however in this case it is getting
in the way so should be told that it can't.

This said, on other bus types (e.g. PCI) where devices are known by
specific VID/PID only without generic classes like HID, drivers *did*
always know exactly which devices they were known to work with. This is
one of the things has led us into the current paradigm of driver
assignment.

And really, the case where a device claims to be of a class which it
really isn't is never going to be that tidy.

> >If someone later modifies the HID driver to provide the direct access
> >needed, they can then undo that as Nicolas says.
> 
> And the application that is driving the device though libusb
> will immediately stop working, whereas, if it was up to the application
> as to which driver to use, there wouldn't be this problem,
> since it could continue to use libusb.

Sorry, the added implication of that was that Argyll would need to be
updated at the same time to use the new mechanism. But I don't actually
advocate adding such a mechanism - it's not needed for real HID devices
and the functionality needed is already available through libusb
directly without the HID driver getting in the way.

> >As a last resort it can try unbinding the current driver but really,
> >this should never be necessary let alone considered routine. If a driver
> >cannot drive a device it should never be bound to it in the first
> >place.
> 
> Right, but a driver shouldn't be making decisions on behalf of
> the application, since it doesn't have full knowledge about the
> nature of the device, nor does it know the full nature of the
> application.

No, but really an user application shouldn't be making decisions about
what driver should be loaded for a given device, either. Everything in
current Linux systems is based around the principle that the system
(kernel plus privileged core software) chooses what driver to load for a
given device at the time that it is connected, and applications then
have to live with that. The way to make sure Argyll gets what it needs
is to make sure those core components are doing the right thing.


Martin

Other related posts: