device filtering support

[Pete Batard]

On 2012.02.03 16:49, Travis wrote:
> On 2/3/2012 7:44 AM, Pete Batard wrote:
>>> 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.
>
> What happens if there is only one app? Then you have not solved
> anything.

How so? I very much think we did.

Creating a new process _once_ can hardly be considered as impacting the 
performance. Heck, we're already creating a thread for the timer on 
Windows, and we'll need to create another one for hotplug...which we'll 
actually be able to eliminate if we use a separate enum process.

So, if you think that we should not be creating a new process on the 
grounds of performance, especially when this process will only be active 
when:
- a device is inserted/removed
- a libusbx app asks for the current device list
I think you are misunderstanding the amount of overhead this will incur.

> In-fact, you have added a bunch of overhead to the most common
> scenario. This is a crazy idea. I hope you are not actually considering
> this.

I am, so you will have to do a better job at telling us why it should be 
dismissed than just say it's crazy.

We adopted a similar approach when we realized that multicore could 
wreck havoc on our timers, because the only way to get a reliable timer 
on Windows is if it comes from a thread that is associated to a specific 
core. So we implemented a separate thread for that, along with the 
communication mechanisms required, and it wasn't that difficult. I also 
implemented a new thread for hotplug on Windows. Creating a new 
thread/process is extrenely well supported (and efficient) on modern 
OSes, and there are lot of resources to help you there.

> ..And FYI, libusb-win32, WInUSB and libusbK cache device and config
> descriptors fi you fetch them with the GetDescriptor api.

Yes, and I think last time we checked, we found that the current enum 
does not produce an extra transfer for those. Only hubs and composite, 
with which, to the best of my knowledge, GetDescriptor will not help 
either. All the APIs we use seem to rely on the same thing behind the scene.

> The best option is to only list devices that you can use,

I think both Hans and I disagree on that one.

And I still do not see a major technical drawback with regards to the 
course of action I propose. So far it only seems to be a matter of 
personal preferences.

> For HID there may be no other way, but at-least you would not be
> punishing every device on the system with descriptor request.

If you re-read what I described, you should find out that we won't.

You appear to be overestimating the amount of descriptor requests both 
the current enum and, more crucially, the proposed new enum would incur, 
and this may prevent you from looking at the problem objectively.

If you see the new proposal "punishing every device on the system with 
descriptor request", then please explain where exactly this will be the 
case.

The only way I can remotely see an issue is if we want to consider that 
people may be using a non libusbx app with isochronous transfer (eg pure 
libusbK, or proprietary driver, since WinUSB is currently useless for 
ISO), and then start a libusbx app, and fear that our initial enum will 
make them drop data.

But the thing is, if anybody wants to do something like that, all they 
have to do is run a lsusb like app that just calls libusb_init() and 
then sleeps, and then they can run whatever libusbx app they want 
afterwards without having to worry about re-enumeration and added 
transfers (except a potential duplicate from what the OS will do if they 
plug in a new device) => non issue.

Regards,

/Pete