Closed jleni closed 6 years ago
It seems this is a known issue in signal11 hidapi https://github.com/signal11/hidapi/issues/385
Would you mind telling me what platform you are using?
Linux. I guess I need to enable a different feature in my cargo.toml
https://github.com/ruabmbua/hidapi-rs/blob/17f73a4599b829040a478d815b17ee94ec1e29dc/Cargo.toml#L21
Because hidapi explicitly does not support usage page querying for some backends. However I am not sure which backends are affected (can`t remember)
How do I change the backend? I am doing the following:
[dependencies.hidapi]
version = "0.5"
features = ["linux-static-hidraw"]
but I get the following:
Compiling hidapi v0.5.0
error: failed to run custom build command for `hidapi v0.5.0`
process didn't exit successfully: `/home/user/test/target/debug/build/hidapi-1db141914f340e4a/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Exactly one linux hidapi backend must be selected.', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/hidapi-0.5.0/build.rs:92:9
You have to disable default features. Look it up in the Cargo docs
Thanks!
I include the solution in case someone has the same issue. Adding the following to my Cargo.toml solved the problem with usage_page
[dependencies.hidapi]
version = "0.5"
default-features = false
features=["linux-static-hidraw"]
I am considering switching the default Backend on linux, when more people have the same issue.
Hi @ruabmbua
I am reopening the issue as usage_page seems to be invalid in Linux. While switching to hidraw returns something, the value is not valid.
I've done a bit of research and it seems that signal11 is not even filling the values. There is an old PR that has been left behind, etc. https://github.com/signal11/hidapi/issues/385
The whole signal11 project has been unmaintained for several years. That makes me a bit uncomfortable. :(
What do you think of progressively moving to a full native implementation? It would be possible to start with Linux only and recreate the ioctl calls.
I already thought about the option before moving to 0.5
Would be an interesting project in my opinion, but t I don`t really have much time on hand right now, so I won't start the effort anytime soon.
Maybe I will think about it again next month.
Btw. for what reason do you need the usage page? You could use feature reports to query the device yourself. A rust library for hid record parsing would be great. Maybe I will work on that soon (I am currently experimenting with stm32f0 based USB microcontroller)
I need to solve this in the following days. Forking or creating another crate does not make sense to me. I will probably submit you a PR once I have something. I will probably start with a simple record parsing but I like the idea of removing all dependencies from signal11 over time. Do you think you will have time to review a small PR?
Of course. I will be available the day after tomorrow. Currently I am in the mountains with a very suboptimal Internet Connection (Loadding GitHub takes several minutes)
The more I think of it, removing the dependency to signal11 hidapi is probably the way to go. I have to dig into its internals, to understand all the platform details. Starting with linux however should be a no brainer.
I will create a branch, for work on a rust based hidraw backend. You are welcome to submit a PR against it.
Yes, signal11 is not well maintained and a native crate would be ideal. I can help with that, however, in the meantime I will need to provide a faster workaround just to get the usage_page.
http://www.usb.org/developers/hidpage/ should be of help.
Closed in favor of #26.
When enumerating devices, I have noticed that usage_page is always zero. However, this is not the case when using other libraries.