[libhid-discuss] retrieving large HID descriptor bytes

[Peter Stuge]

Hi Mike,

mike stone wrote:
> > Hm, can you clarify how you use the device on Windows?
> 
>   I use the usbhidio VC6 on http://www.lvr.com/hidpage.htm to test
> the device under Windows.

Thanks! That suggests to me that you do not actually want the device
to communicate with the Input subsystem in the operating system, but
that you wish to communicate with the device from you application,
and from your application only. Ie. your device is not a keyboard,
mouse or joystick that the operating system could be expected to
handle with it's standard HID driver.

If this is true, then I very strongly recommend that you do *not*
make the device a HID class device, unless ease of programming in
Windows is your only concern. (Which I doubt, since I guess you
wouldn't be looking at the portable libraries in that case. :)

I would instead recommend that the device is made to expose a vendor
specific interface. This might sound like it would be a second class
citizen in the USB world, but in fact it is by far the best way to
let the device tell the host that the operating system should never
bother with the device. On every operating system other than Windows
the device will then be easier to communicate with from applications.


> May be it is better to solve libhid problem later. I tried using
> libusb to read data from the device and send data to it.

Good idea!


> usb_interrupt_read worked. usb_control_msg failed.

How does the control transfer fail?


> (the device do not have output endpoint, it use ep0 instead)

That's fine, control transfers to ep0 are always allowed.


> /* if usb_control_msg success then usb_interrupt_read will read
>    different type of data */
> 
>     tmp[0] = 'S'; tmp[1] = 'c'; tmp[2] = 0x0; tmp[1] = 0x0; tmp[4] = '\n';
>     if(usb_control_msg(dev_handle, 0x22, 0x9, 0x200, 0x0, &tmp[0], 24, 1000) < 0)
>              printf("usb_control_msg failed***\n");

This is a class specific request, request 9 to the endpoint, since
this is a HID class device it means that this is a SET_REPORT
request, with 24 bytes of data being sent from the host, report
type=2 and report id=0.

(Note that tmp[1] is overwritten before the call to usb_control_msg().
Maybe that's a typo?)


This function call is perfectly legitimate, so the problem you are
seeing must come from the firmware.

Again, I would urge you to consider moving away from (ab)using the
HID class for the device, unless it will in fact be used for a human
interface, in which case hopefully you can let the operating system
drive the device with the standard HID class driver.

By far the simplest way to create an arbitrary USB device is to make
it vendor specific. (But by all means, first check to see if there is
an existing device class specification that fits your device. Again,
if there is, then you can let the operating system's class specific
driver take care of your device and you do not have to develop any
driver.)


//Peter