mac: fix behaviour of hid_get_feature_report

[rbarazzutti]

This fix is quite important for the Mac platform, since the behaviour of hid_get_feature_report was not following the specs.

[rbarazzutti]

Hello Alan,

I'm pretty happy to see that you're carefully checking patches submissions.

I agree Apple docs are kinda horrible. I double checked my fix and tested it on OSX 10.10.

Keep me posted,

Raphaël

[ilovezfs]

What is the status of this PR? It's currently being applied in the Homebrew formula, but it's not clear that upstream agrees with the change, in which case we would probably want to remove it from the formula.

[cboulay]

+1 on this. For psmoveapi and PSMoveService this is a problem. The number of bytes returned by hid_get_feature_report is different on Windows than it is on Mac. According to your API doc strings, the Windows version is returning the correct number of bytes but the Mac version returns one less.

However, it's not entirely so straightforward. The PSMove can be connected via bluetooth or USB. All of the BT feature reports behave as described above. At least one of the USB feature reports does not, where the first byte no longer contains the report id. I'll have to investigate this further.

[ilovezfs]

@signal11 ping on this PR

[bakercp]

Also confirming that on the current master branch does not match the documentation on macOS 10.12. The first byte returned is not the report id, even when the report id is requested and the length is off by one.

[micolous]

This behaviour in master on OSX 10.14 is still incorrect, and differs from the Linux version.

The work-around I have is to explicitly set a non-zero report ID (by setting the 0th byte in the buffer to something other than 0).

In this case the Linux and OSX APIs will return the same result, but it does mean that the commands sent to the device change. There don't appear to be any negative side-effects for the device I'm working with, but this may be problematic for others.

Update (2019-08-11):

• If you're running a version of hidapi from Homebrew since after 2016-08, your build has this patch.
• If you're running hidapi v0.9.0 or later from Homebrew, you're actually using the libusb fork (see Is this library maintained? #373), which has this patch.

[Youw]

@rbarazzutti do you happen to remember, have you been using numbered reports or not?

as far as I can tell from the original message of @micolous (9 Nov 2018) - Report ID is his case was zero (no numbered reports)