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

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Sat, 15 Dec 2007 02:22:03 +1100

Martin Ling wrote:
The usual reason for drivers having a compiled-in list of devices is
that these are the ones which that version of the driver supports and
should attempt to use.

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.

The current HID driver is unable to correctly drive a Huey, so it is
quite right for it to identify one and leave it alone.

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.

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.
The kernel driver shouldn't be making decisions about things
it doesn't have enough information about. In this case, it's the
application that has the necessary information.

What I think the application should do is to check whether a driver is
bound, and if not go through libusb. If there is a driver bound and it
provides the access it needs, it can use it.

It may not want to use it. There can be various reasons for this,
from portability (libusb provides a more uniform interface
than the various HID API's for instance), to access extra features not
available through a class driver, or to work around bugs in the class
driver (ie. the Linux communication class driver timing out when driving
the HCFR device.)

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.

Graeme Gill.


Other related posts: