device filtering support

[Pete Batard]

On 2012.02.03 13:03, Xiaofan Chen wrote:
>> Xiaofan and Travis, as well as possibly Tim, seem to think that our only
>> option on Windows then is not to list everything during enum  (ignore hubs,
>> and other components that require queries, such as composite parent devices
>> as well, if I'm not mistaken), but I very much disagree with that.
>
> We think that is the easiest solution and it is the one method used
> in libusb-win32 and libusbK. It serves the user quite well so far.

Yes, filtering is definitely the easiest, and if I only wanted to reduce 
my enumeration troubles on Windows, this is actually what I'd pick.
But what is easiest for us may not always be the best for everybody. In 
a generic library, I think it is reasonable to expect that some app 
developers will be interested in listing more than the devices they know.

> This is not a convincing reason at all.
>
> I believe most of the use cases of libusb only cares about one or a few
> particular device, with known VID/PIDs. Therefore I do not see the need
> of enumerating all device.

Yes, "most". But not all. I can actually add code to libusb/Windows that 
returns some more details about hub (I played with that at one stage), 
and I'd venture to say that there's probably someone who one day may ask 
for such a feature, even we don't exactly see why anyone would want to 
do that. If we go with restricting to known VID/PID, they're going to be 
out of luck.

As usual, my problem is with assuming that we "know" what our users will 
do. We don't - it just takes way too much foresight!
And the price of being wrong in whatever we assume equates disappointed 
users.

Therefore I think we need to leave the door as open as possible for uses 
which we never anticipated, and provide as many generic features as we 
can. Enumerating all devices regardless of whether most users require it 
happens to be one such generic feature.

> Just another example, for hot plug event, do most users only
> want to listen to the hot-plug event of interested device? Or do
> they want to listen to all the hot-plug event of all USB device?

We don't know, and we shouldn't assume, therefore I'd say we should go 
with all events, and let the users themselves filter the ones they don't 
want. Better provide too much than not enough.

> You still need to tell the user to install supported driver (e.g.: WinUSB)
> even if they can find the device.

Agreed. And I'm still trying to devise a good solution for that. Driver 
related error codes on open is the approach I saw not so long ago, but 
there might be others.

> And in the case of Mac OS X, you
> still need to tell them that they may need to write a code-less kext
> in order to really talk to the device.

The difference here is that this is an OS restriction, i.e. not 
something we can avoid, whereas I believe filtering is something we can.

> On the other hand, I kind of understand that the current implementation
> is based on the Linux behavior and that was what Daniel/Peter wanted.
> So it is really difficult to change (not to be in libusb 1.0.10 anyway). That
> is why I think that filter might help if we do not change the basic
> implementation.

If the constraint is we should not change the current core 
implementation, then yes we won't have much of a choice. But I'm hoping 
that libusbx will not forbid changing features that help improve one 
platforms, even if new untested code adds risk for the others.
As our goal is to be cross platforms, each platform is likely to have to 
make sacrifices to achieve it.

> If that is the case (enumeration is only a one-time job during the startup,
> subsequently only changes are monitored), then probably this is a solution
> as well.
>
> Does that mean filter is no longer really required in this case?

That's how I see it, yes, and the reason why I think we can still have a 
full enum that does not result in extra pollution on the bus.

> The strategy makes sense if your solution indeed can really remove the
> un-necessary renumeration.

In the abstract, I think it should. But the devil is in the details, so 
the only way we'll have firm evidence is once we get to doing it... 
which will require some form of finalized hotplug.

Regards,

/Pete