Create raw rust Windows backend (using hid.dll)

[ruabmbua]

• Remove dependency to signal11/hidapi
• Match previous windows backend features

Progress:

• [ ] Device enumeration
• [ ] Device meta data extraction
• [ ] Blocking HID IO
• [ ] Non-blocking HID IO
• [ ] CI (travis will not do it, maybe appveyor)

[jleni]

I would add appveyor CI. At least to confirm there are no build issues.

[wendivoid]

Just wanted to say, I would really love this too. 😄

[AlexCouch]

I started working on a windows backend since that is what I mainly use. The original code was working for linux but I moved it all into cfg_if's and added the windows backend module into a separate cfg_fi. Also changed up the error stuff and added some comments on what I think about different backends having their own error handling implementation. The windows backend module is using setupapi from winapi since its native to windows and that is what the signal11 hidapi was using. Figured we just continue the trend. Nothing wrong with using setupapi. Also added a lot of other comments about HidApi initialization, backend initialization, error handling, and backend specific device enumeration. Basically a lot of abstraction that gets implemented per backend.

My fork's branch with all my changes can be viewed here: https://github.com/AlexCouch/hidapi-rs/tree/remove-signal11-dependency

I don't think I will be making a pull request any time soon unless its desired in the main project's repo. But it's there for tracking. I'll make a pull request when I feel as though I have the windows backend working well enough.

Note: I have decided to take a break from rust programming so don't expect a whole lot of updates on my fork for a little while. I'll still be working on it but I just started a new job so I'm focusing on that. I will be active throughout the week.

[ruabmbua]

@AlexCouch is now working on this.

[eranrund]

Hi! Wondering if there have been any updates on this? Can this crate be used on Windows? Thanks :)

[ruabmbua]

Nope no updates unfortunately. But if you want to use the crate on windows, it already works perfectly fine. The backend for windows uses the hidapi C library currently. This ticket is just about getting rid of the dependency.

[eranrund]

Ah gotcha, nice. Thanks!

[micolous]

Of possible interest to folks here, I've got an implementation of the UWP API (HidDevice) in webauthn-rs, where I was able to remove its dependency on hidapi.

That's an MPL-2.0 licensed crate, and not designed for use outside of that particular library. Having somewhere to upstream that would be nice – but it has a lot of FIDO-specific bits in there which would need to be pulled back out, and hidapi-rs would also need to move to an async-first API (#51).

The UWP APIs are pretty nice to use, they're available on Windows 10[^1] and later, and windows-rs bridges the COM async stuff across fairly nicely.

However, in using it for another project, I noticed that the UWP API has a couple of limitations versus the Windows 2000-era APIs which hidapi uses (HidD_* / HidP_* / hid.dll).

• the UWP APIs can construct AQS queries to select HID devices (eg: HidDevice::GetDeviceSelector), but you can't select by VID + PID alone, nor matching multiple device IDs (like macOS can).

  You can work around this by constructing the AQS by hand, but it feels a bit janky:

  format!("(
  System.Devices.InterfaceClassGUID:=\"{{{:?}}}\" AND
  System.Devices.InterfaceEnabled:=System.StructuredQueryType.Boolean#True AND
  System.DeviceInterface.Hid.VendorId:={vid} AND
  System.DeviceInterface.Hid.ProductId:={pid}
  )", GUID_DEVINTERFACE_HID)

• devices with the Consumer Usage Page are entirely unavailable: HidDevice::FromIdAsync returns "success" and a NULL pointer, even as an Administrator, and even when building as a Windows Store app with the appropriate entitlements.

  You can access Consumer Page Usage devices with hid.dll just fine – even as non-Administrator. So it's an arbitrary restriction on these APIs[^2].

  This is a deal-breaker for the UWP APIs if you don't have liberty (firmware access) to change a device's descriptors.

Both of these are very much platform issues, but there's no obvious way to give this sort of feedback to Microsoft.

Because hid.dll uses fairly ordinary Windows I/O for input and output reports, it's possible to make that asynchronous (ReadFile / WriteFile with OVERLAPPED). hidapi uses those asynchronous APIs, but appears to have some pretty serious thread safety problems.

The OVERLAPPED bindings in windows-rs don't have any Rust-side async integration, so they're not great to use right now. But it's still possible to largely eliminate the thread-safety problems hidapi has today and go with a more async-friendly design.

[^1]: Possibly also available on Windows 8.1. [^2]: There are similar restrictions for keyboards and non-Administrator access to USB HID FIDO authenticators, but those restrictions are consistently applied across all Windows HID APIs.

[ruabmbua]

@micolous actually, we can already close this ticket. The master branch already has a native windows backend, which one can enable via cargo features. Its not yet released to crates.io, because I did not find time yet for doing some more tests to verify its working.

[ruabmbua]

Regarding a more async friendly API: We can eventually do some changes to the public API surface, but it would only make sense to do that, once all our currently supported platforms get a backend not depending on hidapi, where we can implement everything with async in mind.