Option to open hid device with exclusive access

[c1728p9]

When hidapi opens a device it does so with shared access. This means another process could also send and receive commands from the hid device at the same time. Would it be possible to add an exclusive access mode? I think this should be possible if the FILE_SHARE_READ|FILE_SHARE_WRITE attributes are removed from the call to CreateFile.

[amadsen]

This actually varies by OS right now. On OS X hidapi does open the device exclusively (which is the subject of a different pull request.) I'd love to see this become an option.

[michrag]

I'm resuming this thread because I think I've "done my homework" but I've not found a definitive answer to my doubts.

TL;DR question: is it possible, in any way, to get exclusive acces to a HID device under Windows 10, using hidapi? By exclusive access I mean that only my hidapi based application should be able to receive inputs from the device.

Full description below.

What I have:

1. Windows 10 Home 64 bit latest version (1703 at this moment)
2. an USB pedal (two states button: pressed / not pressed, if pressed it keeps sending the signal, just like a keyboard key).

In general a pedal is a HID device ("Less common HIDs: Driving simulator devices and flight simulator devices have HIDs such as gear sticks, steering wheels and pedals").
This particular pedal is seen by libusb as a class 0 device with two class 3 interfaces, so it is functionally equivalent, as my understanding, to a class 3 (HID) device.
So, since in its own FAQ libusb itself reccomends using hidapi for a HID device ("HIDAPI is recommended for HID device than libusb Windows" - "In general, you may find HIDAPI a better library for HID device"), here I am.

I've tried both the latest official release 0.7.0 and the latest commit in master at the moment.

For my problem, the main difference is in the function open_device in hid.c: while the 0.7.0 version tried to open the device with exclusive access (share mode set to 0) and then, on fail, would open it with a shared access, the latest version open it directly in shared mode.

I've found the followind threads about this change over time:

1. Windows: hid_enumerate() skips devices that have already been opened #23 (Windows: hid_enumerate() skips devices that have already been opened)
2. Update hid.c #189 (Update hid.c)
3. HID open fail in Window 10  #231 (HID open fail in Window 10)
4. windows: Some devices still require being opened with Windows write sharing #260 (windows: Some devices still require being opened with Windows write sharing)

However, I don't understand why it couldn't keep at least trying to open it in exclusive mode instead of open the device directly in shared mode.

For my particular situation, I've verified that with the 0.7.0 version the device is successfully opened in exclusive mode, but sadly this does not prevent other running applications to receive inputs from the device.

Hence, I'm still searching an answer to my original question stated in bold at the beginning ot this post.

@c1728p9 @signal11 any ideas?

Thank you very much.

[michrag]

Update: in my particular case (class 0 device with two class 3 (HID) interfaces), it looks like it is possible to get exclusive access by changing the drivers of both interfaces to WinUSB with Zadig and using libusb, as explained in the issue linked above.

Note: after changing to WinUSB the drivers, hidapi does not see the device anymore (weel, I guess it is the expected behaviour).