[Libusbx-devel] Linux patches for 1.0.9 release

[Hans de Goede]

Hi,

On 03/29/2012 05:46 PM, Pete Batard wrote:
> 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

Well if you detach the driver, and it is not something like a microcontroller board, but a mouse/keyboard with
extra features, then you will loose the mouse / keyboard under Linux too. Note that for at least one such keyboard
which I've seen this problem was fixed at the hardware level (likely to avoid similar issues on other platforms) by
simply having 2 hid interfaces, one the actual keyboard and one for just the extras.

So in the Linux case one could argue for having a HID backend too...

My personal opinion on this is that if people need to talk to a HID device and only
send HID requests (which is all which is supported with the windows HID backend, right?)
they would be better of just using HIDAPI.

With that said I'm not against having HID backends if people want them. Crazy idea, maybe
we can have a HID backend on top of HIDAPI, then we can have one HID backend for all
platforms ...

Regards,

Hans