Zero in first position of set_report/write data is skipped (Mac OS X)

[doc-hex]

I've found that calling hid_write() with a buffer that starts with a zero byte causes a truncated buffer to be written.

For some reason, this code, looks for a zero byte and if found in the first position of the buffer, skips it and shortens the report by one byte.

    if (data[0] == 0x0) {
        /* Not using numbered Reports.
           Don't send the report number. */
        data_to_send = data+1;
        length_to_send = length-1;
    } ...

The result is I can try to write a 64 byte report and depending on the value in the first byte, I will sometimes observe 63 bytes on the wire, and the leading zero is not sent.

Like many users of this library, I am speaking to a device which is not truly a HID device, and uses reports as general purpose pipes. From my point of view this is data-dependant corruption. I am calling hid_write() and not really sending a HID report.

Perhaps a good fix would be copy the call to IOHIDDeviceSetReport into hid_write() and make no assumptions about the data being written.

[swt2c]

This is the expected behavior. From the API documentation:

The first byte of data[] must contain the Report ID. For devices which only support a single report, this must be set to 0x0. The remaining bytes contain the report data. Since the Report ID is mandatory, calls to hid_write() will always contain one more byte than the report contains. For example, if a hid report is 16 bytes long, 17 bytes must be passed to hid_write(), the Report ID (or 0x0, for devices with a single report), followed by the report data (16 bytes). In this example, the length passed in would be 17.

See http://www.signal11.us/oss/hidapi/hidapi/doxygen/html/group__API.html#gad14ea48e440cf5066df87cc6488493af

[doc-hex]

Ok, I agree and will change my usage.