Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows vs Mac differences in device.write() #191

Closed
gniezen opened this issue Mar 21, 2017 · 2 comments
Closed

Windows vs Mac differences in device.write() #191

gniezen opened this issue Mar 21, 2017 · 2 comments

Comments

@gniezen
Copy link

gniezen commented Mar 21, 2017

I've now spent a couple of days trying to figure out why my Windows build was not working when my Mac build was working fine. Turns out that for device.write() the first byte must be the report ID on Windows, while this is not the case for Mac.

The upstream HIDAPI docs state that:

The first byte of data[] must contain the Report ID. For devices which only support a single report, this must be set to 0x0.

I'm not sure why the behavior is different on Mac. It seems to be related to a still unresolved issue in HIDAPI.

To ensure that the Windows and Mac builds work the same, can we maybe have report ID as an optional parameter for device.write(), that defaults to 0x00 for the first byte on Windows if not present?

Alternatively, can we change the current line in the README that says

Some devices use reportIds for OUTPUT reports. If that is the case, the first byte of the array to write() should be the reportId.

to be more specific?

@todbot
Copy link
Contributor

todbot commented Mar 21, 2017

Hi,
Yes, we're trying to find a good solution to this problem with hidapi. See issue #187 for some previous discussion.

What device are you communicating with?

At this point I'm thinking we should do platform-dependent special-casing to bandage the hidapi issue. It's very frustrating.

todbot added a commit that referenced this issue Mar 21, 2017
@gniezen
Copy link
Author

gniezen commented Mar 22, 2017

Hi Tod,
Thanks for the quick response! Apologies for creating a duplicate issue - it looks like #187 is indeed the same hidapi bug.

At Tidepool we're talking to a bunch of Bayer blood glucose meters (Contour Next, Contour USB, Contour Next Link and Contour Next USB) using node-hid as we're in the process of switching our Chrome app over to Electron (I'm guessing you'll have even more people start to use node-hid now that Chrome apps are end-of-life). Our open-source Uploader app allows people with Type 1 diabetes to upload all their devices so that they can see all their data in one place.

I'll close this issue and continue the discussion in the other thread.

@gniezen gniezen closed this as completed Mar 22, 2017
todbot added a commit that referenced this issue Jan 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants