USB HID Enumeration

[aandrew]

I have no idea. I would strongly suggest to use Linux for debugging USB devices. Linux is way more descriptive with what's wrong with the device.

Not to mention it has a *great* built-in USB traffic logging and debugging system: https://www.kernel.org/doc/Documentation/usb/usbmon.txt (Wireshare also works with this interface, although I've not used it myself.)

[Bambur]

H-m, we might take our words back on bidirectional data endpoints:

Data endpoints are optional and used for transferring data. They are unidirectional, has a type (control, interrupt, bulk, isochronous) and other properties.

https://msdn.microsoft.com/en-us/library/windows/hardware/dn303353(v=vs.85).aspx

[ataradov]

H-m, we might take our words back on bidirectional data endpoints:
Data endpoints are optional and used for transferring data. They are unidirectional, has a type (control, interrupt, bulk, isochronous) and other properties.

I think they just used the wrong words. Technically, for endpoint 5, IN direction will have address 0x85, and OUT direction will be just 0x05, so they are unique in a way.

Otherwise, I see no reason to not support the same index for IN and OUT endpoints.

[Bambur]

Alex, thanks again! I see your point.

Next I would like to ask about the considerations on a protocol over interrupt IN and OUT endpoints.

I have understood host polls an IN endpoint periodically and has an internal ring buffer where it stores fetched HID reports. Hence, there is HidD_SetNumInputBuffers on Windows, for instance. Nevertheless, there is no guarantee no report(s) will be lost.

Have you thought about that? Any solution?

[ataradov]

Have you thought about that? Any solution?

Not really. PCs are much faster than any USB device out there. Just organize your program in a way that reads the data fast enough.

With USB FS it is not a problem at all, since your maximum throughput is 65 KB/s. With USB HS I was getting something like 6 MB/s, which is also close to theoretical maximum, ans I had no problems with that.

[janoc]

BTW, careful with the HID descriptors - the Windows HID parser is notorious for crashing and randomly barfing on otherwise perfectly valid descriptors that Linux or Mac will work fine with (for example). The best way that I have found to avoid this issue is to "steal" a descriptor from a device implementing similar functionality to what you are after and adapt it - that will give you a known working starting point.

If you don't have an USB analyzer, then Wireshark (https://www.wireshark.org/) can capture and analyze USB transactions too if you install the USBCap drivers during installation. That is a huge timesaver for debugging problems like this.

For interfacing with HID devices in a portable way without having to deal with the messy Win32 APIs I have found the HIDAPI lib (http://www.signal11.us/oss/hidapi/) indispensable. That makes talking to a HID device a lot easier.

[janoc]

I have no idea. I would strongly suggest to use Linux for debugging USB devices. Linux is way more descriptive with what's wrong with the device.

I second this. Even if you put Linux in a VirtualBox image, it will save you a ton of headaches.