Hi Philip, philip.jos...@microchip.com wrote: > the incentive to uncomplicated the user's experience has driven > many implementers to HID on Windows.
Yes, this is easy to understand. I think by far the best solution to communicate with HID class devices "manually" is to use HIDAPI. > Even with our driver pre-installer, we still run into problems on > some Windows machines (especially those controlled by an IS > department). Do you already have some information about how those machines will react to USB devices which use the Microsoft string descriptor and control request to specify e.g. WinUSB as driver, on Windows 8? > We had hoped that libusb would solve this by providing a generic > way of accessing a device (simply through using control, interrupt, > and bulk pipes without regard to device "type") and without the > need for a driver installation procedure (INF) on Windows. I think HIDAPI is a much better fit for HID class devices than libusb can ever be. With HIDAPI you get the excellent user experience also on Windows, while keeping portability across many operating systems. Non-HID-class devices will be able to offer the same user experience on Windows 8 by using the Microsoft extensions to USB, which load WinUSB for a device without a driver installation procedure and without an INF file, and then the application can of course use libusb easily. > Other than lacking hot-plug, the libusb has served us well on Linux > for both our bulk and HID devices. I hope it continues to do so in the future too, at least for the non-HID-class devices. I really do recommend HIDAPI for taking care of HID class. Making a thin transport abstraction of libusb vs. HIDAPI depending on device interface is probably very easy, and allows each of the three components (your application, libusb, and HIDAPI) to keep the sematics which are most relevant in respective context. > Windows however was another problem (we resorted to providing our > own generic interface that under the covers uses WinUSB for bulk > and the native HID system calls for HID -- and unfortunately, we > have INF files to contend with). I think this was a very wise solution. For the future HIDAPI for HID class and libusb for vendor specific would allow to consolidate your code across platforms, leaving only the distinction between bulk and HID class communication. > On the Mac, we use libusb for bulk and implemented our own back end > for HID (providing a very simplified pipe-oriented read and write > capability with hot-plug). It sounds like HIDAPI would allow for significant simplication of your code, since it works without driver installation procedure across Linux, Windows, and Mac OS X. > having a common way of accessing devices across platforms would be > very good for us (including HID support). Of course. I think a libusb+HIDAPI combination offers just that. I would also encourage you to publish such a thin libusb+HIDAPI abstraction if you decide to take that approach, and if you think that others could benefit from the same code. //Peter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
