Tod Kurt

usagePage 12 (0x0C) is "Consumer Control", normally a part of keyboards and thus owned by the OS. `node-hid` has restricted to no ability to communicate with these devices since the...

Unfortunately `node-gyp-build` and `prebuildify` do not support multiple `.node` files, as needed by the Linux build of `node-hid`. For more details see: https://github.com/prebuild/prebuildify/issues/57 Leaving this issue open for now as...

Hi @Youw, I believe I'm in agreement with you now, after researching things a bit more and doing some tests. Thank you @FrogTheFrog for helping me understand `node-hid` and `hidapi`...

Agreed, I think I was getting lucky (or at least the underlying system calls on MacOS and hidraw are more tolerant to bad usage). And I might put in that...

HI! You are doing everything right. It sounds like the device is getting sent a "send data" command from the support software. This is pretty common in a lot of...

What kind of HID device is this? What `usagePage` and `usage` are you connecting to? If you're not `open()`-ing on a specific usagePage/usage pair, and the device presents multiple usages...

Could you give a link to your code?

Yes, it's the EventEmitter inside node-hid keeping the process. Isn't this expected behavior? To cancel the pending read, you should call `hid.close()`.

Hmm. Yes, I can kill the Node process by doing Ctrl-C in the terminal. I've not tried `kill`ing it though on the commandline though. Maybe Node doesn't respond to SIGINT,...

I just verified a simple `hid.on('data',...)` example does respond to SIGINT and SIGTERM on my Macbook Pro running OS X 10.11.6, Node v6.9.1, node-hid from github (e.g. `npm install github:node-hid/node-hid`)...