Where Is The Pure Rust Impl?

[AlexCouch]

I was just curious about the pure rust impl project and what the status on it is. I am also curious about getting involved in the project cause I would greatly like a pure rust hidapi.

[ruabmbua]

Hi Alex!

Currently I am not actively working on the project. I have some other stuff going on, and I am not sure if I will ever pick up work on hidapi again.

If you want to contribute, I can try to find my initial work, and push it to a branch. I remember it was far from complete, but some parts of the Linux backend are already done.

[AlexCouch]

Ah that's okay. I got stuff going on as well but I got more time on my hands. I have a project that requires hidapi and its not working at all cause I'm still learning rust (not because of hidapi). However perhaps when I do get things working I'll pick up the pure hidapi impl and split my project from the C hidapi. But the thing I'm worried about with making a pure rust hidapi is that it would still be relying on C libraries. But who knows maybe a pure rust impl would be safer and faster than it is now right?

[jleni]

I had to hack a few things due to inconsistencies in the C libs https://github.com/ruabmbua/hidapi-rs/issues/26#issuecomment-415171160 Ideally, I would like to have a clear pure rust implementation that works in Win/OSX/Linux. I would be happy to help too.. I think this crate is an excellent starting point

[AlexCouch]

I agree. Like I mentioned I'm still learning rust. When I first started my project I wrote some shitty code so now I'm thinking about starting over cause its completely broken and hard to read. Part of it is trying to share a reference to a device handle with multiple threads and that's not really possible because c_void isnt safe to share between threads. I would like a possibly more thread safe version of hidapi and I think that may be possible with a pure rust hidapi since the point of using rust is to be safe from data races.

[ruabmbua]

At least on linux we can easily share access to the same hid device over multiple threads, as long as the backend is based on hidraw. I dont know enough about libusb so I cant comment on that one.

By the way: What`s your use case for using a hid device from multiple threads. I kind of struggle coming up with one. Of course it is convenient to have, but when you access the same device with multiple thready, you need some kind of external synchronization anyway. E.g. to not mess up the protocol implemented atop of the hid stack.

[ruabmbua]

I pushed my current progress. Its state is a little bit underwhelming. I just introduced a abstraction layer over multiple backends, and made the old hidapi code one of the backends.

The pure rust linux API based on udev and hidraw is completely `unimplemented!()

I will put some work into it this weekend to get device enumeration via udev working.

[ruabmbua]

I am tracking progress here: https://github.com/ruabmbua/hidapi-rs/projects/1

If anyone is interested in picking up the MacOS backend, or giving me a free Mac, please comment on the IOHidManager ticket :P.

[AlexCouch]

I have a macbook i can check things out later tonight pacific time when I get home.

To answer your question, my use case is two sister threads managed my a struct in which one sister handles and parses input reports into usable objects and the other sister thread handles the construction and writing of output reports. You can see more here.

[ruabmbua]

Very cool and interesting project!

[AlexCouch]

Is there a discord where we can discuss things further?

[ruabmbua]

I created one: https://discord.gg/3ahhJGN