device filtering support

[Pete Batard]

On 2012.02.03 14:48, Travis wrote:
> This is a bad idea because then there will be no way to disable hot
> plug;

Why should there be? Or should we also make WinUSB, libusb-win32 and 
libusbK support optional?

> I assume you will be creating a background thread and top-level
> window at startup for this.

Background process. Definitely nothing visible in any UI (but might be a 
hidden window if needed)

> This will make the enumeration situation
> significantly worse. e.g. This "permanent" list will update whether the
> user needs it or not.

It will update on hotplug. I think you'll find that the performance 
issue of updating the list itself is minimal, especially compared to the 
time it takes to do bus accesses. Also, it only updates when somebody 
plugs or unplug a device, which is a super low frequency event.

> The real problem with enumeration is how it works in general. It request
> descriptor information which is already cached at the driver

Only for the drivers that were written specifically to cache them. HID, 
WinUSB don't for descriptors such as strings (and we can't query 
Input/Output report descriptors directly with HID, even with a bus 
transfer, instead we rebuild an approximation from OS data). And, if 
this is the root of the matter, I think we should continue with what 
libusb currently does, and not cache every single descriptor we can get, 
but instead let the apps query them themselves (with a bus transfer).

But even if we think otherwise, we can also cache them with the approach 
I propose, without incurring disturbing bus transfers, so it shouldn't 
matter anyway.

> (for every
> device, for each process, 1 device request, 2 config requests) Imagine
> if all USB applications did that.. lol.. Our USB devices would spend all
> of their time returning descriptors.

I don't think you understand the situation:

Firs of all, there would be only one process on the whole OS doing the 
querying, no matter how many libusbx based apps are running (multiuser 
is a different issue, but I think one we can dismiss, as 2 users trying 
to access the same hardware at the same time is usually bad news).
And the first app to run will get libusbx to start that common process 
and do the initial querying _before_ it actually can access its device 
=> no perturbation there, it's as if the enum list always existed.

So, the ONLY time we *may* query a device is if a new one is inserted. 
If another libusbx apps is started, there's no querying. If no new 
device is inserted, no querying, even if you happen to open/close your 
device as fast as you can. And if a device is removed there's of course 
no bus querying (expect perhaps for hubs, by the OS, and not something 
we can control).

So, the only matter is the querying that occurs on device insertion.
Well, the OS will always query (some of) these descriptors whenever you 
insert a device, regardless of whether your driver caches them, because 
it needs them to be able to determine the driver to use (from VID:PID + 
strings/serial), the config, etc.

So you can't avoid plugging an USB device and not have any descriptor 
queries. And, IIRC, it actually caches some of those (so we don't 
actually need to produce a bus query to cache them in libusb), but not 
others such as hub and composite => even the queries that we cannot 
avoid issuing and have to duplicate are expected to be minimal. We also 
have no need for string descriptors during enum (we don't cache them in 
libusb), so there's even part of the queries that the OS does that we 
don't do.

But even if we needed to duplicate this querying, so what? We'll repeat 
something one time only, from a super low frequency event, and very 
shortly after a similar occurrence from the OS, that already produced 
some unavoidable perturbation on the bus. A stone will have been thrown 
in the pond right before we through ours. And these are very short 
control transfers => the idea that someone can not afford the one-time 
duplication of a control transfer, right after similar control transfer 
occured seems absurd.

> Unfortunately, this type of enumeration will have to go entirely if
> libusb-1.0 is to be anything more than a diagnostic tool on windows.

I don't see it that way at all, for the reasons above.

> You idea of spawning additional processes

1 process, unique for all libusbx apps.

> is a bit absurd considering
> the performance problems you already have,

On the contrary, it eliminates performance issues due to enum, since 
after that one time complete enum, where NO libusbx app is yet able to 
access a device, enum only needs to be concerned about devices plugged 
in or removed.

> but again none of this solves
> the real problem. Applications cannot enumerate every USB device using
> direct I/O requests; I hope I'm not alone on this one.

We're not doing any of that.If I recall correctly, the OS provides a lot 
of what we need already cached, and only a few devices such as hubs or 
composite require bus access. But even if the OS did not provide cached 
data, the way I anticipate is it doesn't matter, because we can achieve 
exactly what you want (bar perhaps a duplicated query here and there).

Or am I missing something?

Regards,

/Pete