[Nut-upsdev] [nut-commits] svn commit r1073 - in trunk: .

[Arjen de Korte]

>>> Well, almost. There is a theoretical possibility that a device, which
>>> is not the same as the original device disconnected, matches all the
>>> data in reopen_matcher, but doesn't match subdriver_matcher for some,
>>> yet unimplemented, reason.
>> I don't know how much of this will affect tripplite_usb, which uses
>> some of these files, but some of the Tripplite rackmount UPSes have ID
>> numbers that you have to retrieve through the protocol (i.e. not
>> available through the standard descriptors). So all of the units would
>> have the same PID/VID data, but you would have to connect to each one
>> to see what its ID is.
> We might solve this by choosing to run subdriver matcher function first.

[ more nonsense deleted ]

Apparently, it was too late when I wrote that message. This doesn't fly.
At the time you run the matchers, you don't have the (parsed) report
descriptor of the device yet, so effectively all you can retrieve are
probably indexed strings. That's not what we need.

I have a cunning plan however. :-)

If we provide a callback function from libusb_open (and as a consequence,
from libshut_open) with an (allocated) buffer which contains the raw
report descriptor, the driver itself could parse it and decide whether
this device matches or not. If the driver doesn't like it (for whatever
reason, all options are open at that time) we report that back and can
then try the next device. Applications not requiring this (or want to
reopen an existing device, ie like MODE_REOPEN), simply pass a NULL
pointer for this function and libusb_open would return as usual.

Best regards, Arjen