[Libusbx-devel] Linux patches for 1.0.9 release

[Pete Batard]

On 2012.03.29 15:09, Ludovic Rousseau wrote:
> Note that I have no idea of the Windows situation regarding HID and libusb.

The situation of Windows/HID is as follows:

1. The HID driver is very attractive to use, because Microsoft does 
provide a public API for it and it doesn't require any manual 
installation from end users. People who aren't familiar with the Windows 
microcosm may see this as a minor point, but it is actually a decisive 
plus. For instance, it's the reason some companies like Microchip, 
decided to go HID with some of their devices even as they had little to 
do with HID. From a support's perspective alone, it makes an awful lot 
of sense to use a driver that doesn't require manual user intervention. 
Windows 8's WCID may be able to take people there with regards to 
WinUSB, but it'll still leave 7 and earlier users out.

2. We had actual requests for it (and continue to have some), so we 
spent quite some time implementing libusb/HID support in Windows, which 
seemed to do a good enough job. Therefore, it's quite different from 
other platforms where libusb/HID support, if achievable, may have to be 
devised from scratch. In other words, all the code we need is pretty 
much already there.

3. The HID driver/API on Windows does have a few limitations as it is 
not generic. For what is worth, it's a bit as if we implemented the 
libusb on top of HIDAPI, so of course we're going to lose some of the 
features one would get with direct generic driver access. Some people 
(Peter) went with an approach of "if you're not going to provide close 
to 100% of the features one would expect from a generic library due to 
driver/API limitations, then that driver should not be used".
Others, such as myself, prefer the approach of "if a limited driver/API 
can still cover the (expected) vast majority of usage scenarios, we 
should go for it and instead notify users of these limitations".


Now, leaving Windows aside, my general view on HID is that if libusb(x) 
aims at being a generic USB library, then our course of action should be 
fairly well defined.

Providing a generic library is, to me, our most important mission 
statement. It basically means neither expecting nor assuming anything in 
terms of usage of the library or the target device. More specifically, 
this means that if a user wants to use the library in a way that we 
never anticipated or that we would prefer them not to do, it's not our 
business to prevent them to do so. Even more specifically it means that 
if a user wants to access their HID device through libusb rather than 
HIDAPI, and there doesn't exist a technical issue with providing such 
access (albeit with possible limitations), then we should aim at trying 
to provide such access.

Or, to put it more simply: "If it's USB and libusb(x) could talk to it, 
then libusb(x) should talk to it".

Realistically then, what I'd say we we need to find out for each 
platform to answer the HID question is:
1. Can libusbx talk to an HID device there?
2. If the above is possible, what are the constraints? Obviously, if 
someone is going to lose their USB mice and keyboard in the process, 
it's not going to be very helpful...
3. How much work would be involved to do so?

For Linux, since we can detach the driver, and since it's already 
implemented anyway, the answers are pretty straightforward

For Windows, the answers would be as follows:
1. Yes, there is an API for that
2. As far as driver installation goes, Windows makes it very easy for 
us. As far as the API is concerned, this is a bit more problematic, as 
for instance we have to reconstruct HID report descriptors in a manner 
that will most likely be different from the one provided by the device, 
and of course, there are quite a few limitations with regards to how 
much of the libusbx API we can carry out
3. (Hopefully) not that much, since we had it and it "just" needs to be 
reinstated.

For other platforms, it looks like it may be a little more tricky...

Regards,

/Pete