Hid DataHasExtraByte 64 byte Buffer Vs. 65 Byte Buffer

Hid users may have noticed that WindowsHidDevice, and UWPHidDevice have a property called DataHasExtraByte. This is set to true by default. This is because many devices accept and send buffers of size 65 instead of 64. In two of the three devices I've been working with recently, a 0 is required in the first index of the buffer. The rest of the array (64 bytes) is for normal transfer.

If you have had trouble with Hid transfer, this might be why. Your device may be expecting 64 bytes, but you may be giving it 65 without knowing. This is more or less a bug, and I'm working on fixing this in a way that won't break existing code. Ultimately, I'd like to remove DataHasExtraByte, but I don't want to remove it at the expense of forcing the user to guess when to use 64, and when to use 65.

This bug report seems to be related to the issue. I am calling on anyone who can help to write your findings there. Or, if you have this problem, please let me know.

Here is an article on Hid that might help to clear things up. https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/sending-hid-reports-by-user-mode-applications

From the article:

Before it calls the HidD_SetOutputReport routine, the caller must do the following: If the top-level collection includes report IDs, the caller must set the first byte of the ReportBuffer parameter to a nonzero report ID. If the top-level collection does not include report IDs, the caller must set the first byte of the ReportBuffer parameter to zero. The output report is referenced by the ReportBuffer parameter. Depending on the report ID, the caller prepares the report by calling one of the following functions: HidP_SetData HidP_SetScaledUsageValue HidP_SetUsages HidP_SetUsageValue HidP_SetUsageValueArray