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 _______________________________________________ libhid-discuss mailing list libhid-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss http://libhid.alioth.debian.org/