On Mar 31, 2011, at 7:27 AM, Jacques Dirac wrote:
- Is there some routine in libhid (or libusb) that is fetching the reports from the IN-report-buffer of the device and saves them in a 'buffer' where hid_interrupt_read() is reading from? In my case it looks like that buffer is overwritten.
hid_interrupt_read() is simply a thin wrapper around libusb's usb_interrupt_read() function. It merely dereferences libhid's HIDInterface pointer to get the libusb handle, and prints a few error messages as necessary.
http://libhid.alioth.debian.org/doc/hid__exchange_8c-source.html#l00332
- If so, can this be disabled or influenced? - If not, what else can be going on here?
Is it possible that your code is expecting a certain length for the reply, and you are discarding the packet if the return code from hid_interrupt_read() is non-zero?
If not, you may have to look deeper in the stack. libusb 0.1 generally doesn't buffer things, either (although I admit I haven't looked at all the platform-specific code lately). There are often kernel-level debugging facilities available - with recent Linux 2.6 kernels and development versions of libpcap, you can even capture USB traffic to be displayed in Wireshark. Unfortunately, that might not pinpoint where the extra IN request is coming from.
FreeBSD prior to 8.0 seems to continuously poll interrupt endpoints at the interval specified in the USB descriptor, and it buffers the results with marginal success. (I wouldn't recommend developing for the pre-8.0 USB stack.)
_______________________________________________ libhid-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss http://libhid.alioth.debian.org/
