Thank you Peter and Xiaofan for your replies. I'm encouraged to wade into the vendor-specific class jungle!
[Now that I'm getting off the HID topic, would you prefer that I continue this discussion in some other venue?] > 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. > ... > 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. Good. I'm into easy. I don't mind digging into USB details, but given that we're a Ma & Pa shop, and Ma and I both have day jobs, I need to spend my time carefully. I've had a look at http://sourceforge.net/projects/libusb-win32 (thank you, Xiaofan) and am ready to give it a try. I've never written a windows app, so we'll see how it goes. > 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? Thanks. This device is a dual proximity sensor, it senses the presence or absence of objects at two locations. It reports to the host the presence/absence status of the two sensors, plus some timing and device configuration data. All this fits in 6 bytes. Currently communication is done via the interrupt end point. The device also accepts 8 configuration commands from the host. One of the commands is to return the above status info, which currently (HID) is done by returning a 64-byte packet. Thanks again, John -- -- http://www.fastmail.fm - The way an email service should be _______________________________________________ libhid-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss http://libhid.alioth.debian.org/
