[libhid-discuss] HID vs. vendor specific class

[Peter Stuge]

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