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.