Hi John, John Parsons wrote: > I've been reading the recent discussion here re HID vs. vendor specific > classes with great interest. Like Rene, I am primarily a hardware > designer. I plan to add USB connectivity to an existing product. BTW, > I am also the firmware developer, chief marketer and bean counter!
:) > initially planned to release this as a HID .. > Statements such as the following seemed to validate my reasoning: > "If you have the time and funds you can implement using “vendor > defined” interfaces which are included within the USB specification as > an option. But while you are moving along this difficult and > time-consuming path don’t be surprised if your competitor introduces a > similar product using a collection of standard drivers and captures most > of the available customer base. I am a STRONG advocate of OS-supplied > and vendor-supplied drivers and always recommend that everyone use this > route. I maintain that you need an extremely compelling reason to > embark on writing your own device driver; most people don’t." > -- John Hyde, _Embedded USB Design by Example_ p. 13. This is a great book, and I agree with the author that standard drivers are best - *if they fit the task*. The most important point about (ab)using the HID class for a device which should not really tie into the kernel's input subsystem, is just that - you're creating a device which announces to the world that it is a human interface device, when in fact it's a foam missile cannon, or a proximity interface. There is no device class for those things, and I don't think there should/could be. I don't care about the "abuse" per se, sometimes abusing a protocol can be a really neat hack, but with HID I think the disadvantages far outweigh the single advantage of trivial access on Windows systems. With vendor specific, libusb-1.0 and WinUSB, it's still very easy to access the device on Windows. libwdi can even be used to transparently and automatically bind the WinUSB.sys driver to the device. (The Hyde book is fairly old, WinUSB and userspace drivers in general are fairly new, on the most common systems.) > But I want Mac and Linux app writers to be able to use this product > with the same ease as Windows app writers. Peter Stuge makes a > strong case for vendor-specific class devices. Thank you! You just made my day. :) > I am willing to go that route, but could use some help getting > started. Pointers to resources would be appreciated... something > like "USB vendor specific classes for dummies!" One of the points I try to make about vendor specific is that it actually means *less* requirements than a standard device class. There's no kernel driver that will hog the device and there are no restrictions on how to write descriptors or how to transfer data. Everything on the USB smörgåsbord is available. The flip side is that firmware developers need to actually design the USB interfaces; choose endpoints and transfer types that the device should use, and this does indeed require more knowledge than copypasting a HID example and basically avoiding going into any depth about USB. (I'm not saying that this is the case for you, John.) When not being held back by a particular device class, it's also possible to consider making the device have multiple interfaces or even configurations. Sometimes this doesn't make sense, other times I think it's a significant advantage. I'm happy to help with suggestions about what endpoints to choose, as are several others. Please describe the major characteristics of the data flow between PC and your device? It's quite possible that you'll still use interrupt transfers, like HID does, but then it'll still be simpler because you don't have to deal with reports and can just use the transfers as the binary packets that they are. Xiaofan Chen wrote: > > For generic HID device, you do not really need libhid, rather > > generic libusb-1.0 will be easier. Yes, I agree with this. Although there is the report mess to deal with manually, for simple reports it might be OK. Still, no reports at all is easier still. :) > Another potential solution for cross-platform HID API. The Linux > support is based on hidraw which is quite new under Linux and > seems still not as mature. But the Windows and Mac codes are > based on native HID API. So this could be a good alternative > to libhid and libusb for generic HID device. > http://github.com/signal11/hidapi For the above reasons I don't really like HID for generic devices. It forces USB devices into the HID box which is rarely a good fit. That said, I also think there will be a HID layer in libusb, to better take advantage of the native HID APIs where they are available and easy to use. In general though, vendor specific all the way! :) //Peter _______________________________________________ libhid-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss http://libhid.alioth.debian.org/
