Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stabilize path for libusb devices #406

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

derekatkins
Copy link

This path helps deal with certain HID devices that don't have serial numbers (e.g. the Sainsmart HID 16 relay). This uses the libusb physical path to stabilize the PATH so that unplugged and replugging the device does not change the path -- and boot order does not affect it, either. Unfortunately the get_address() API is not stable across plug-ins.

@khilman
Copy link

khilman commented Dec 8, 2018

FWIW, I tested this on debian linux, with the crelay tool, and it works like a charm!

TheOnlyJoey added a commit to OpenHMD/hidapi that referenced this pull request Apr 9, 2019
@jonathancross
Copy link

Please consider making this PR to https://github.com/libusb/hidapi
See #373

@derekatkins
Copy link
Author

derekatkins commented Jul 11, 2019

@jonathancross

Please consider making this PR to https://github.com/libusb/hidapi
See #373

Sorry, while I know git pretty well, I'm not a github expert, so I'm not sure how to tell github to let me submit this to libusb/hidapi. The straightforward way seems to not recognize my branch as a fork. It looks like libusb/hidapi is not a fork of this repo, which implies I'd need to manually rebuild this change? Or is there a better way?

@Youw
Copy link

Youw commented Jul 11, 2019

You definitely need to make another fork of a new repository, and apply your changes on top of it in any feasible way.

@derekatkins
Copy link
Author

@Youw -- I figured that. I don't think my system is actually using libusb/hidapi, so I have no way to actually test that the change would work. I can certainly apply it blindly, and ensure it builds, but I'm not sure that helps anyone if I can't actually test it. Someone else is certainly welcome to copy my code and build a PR against libusb/hidapi.

@Youw
Copy link

Youw commented Jul 11, 2019

Do you mind sharing what "your system" is?

@derekatkins
Copy link
Author

@Youw

Do you mind sharing what "your system" is?

Fedora 29 (although it was FC25 when I did the work). The libhid they provide is the signal11 version, not the one from libusb. Specifically:

# rpm -qf /usr/lib64/libhidapi-libusb.so.0.0.0 
hidapi-0.8.0-0.10.d17db57.fc29.x86_64

@Youw
Copy link

Youw commented Jul 12, 2019

Well. Alan is not answering last couple of years, and he is the only maintainer of this repository, so, technically, it is abandoned.

See discussion here: #373 (comment)

We hope, that all dists, that consider them up-to-date will switch to https://github.com/libusb/hidapi eventually, but there still a lot of hard work to do, before that can happen.

@derekatkins
Copy link
Author

@Youw -- Yes, I saw #373 and will try to migrate my PR over there, but like I said above, someone else is welcome to port my changes over if I don't get to it. Frankly I did it because I needed the functionality. Until my distro does migrate I don't have a high need to port the change (but you're right, I should make sure the change gets ported before my distro updates...)

erikolofsson pushed a commit to Malterlib/hidapi that referenced this pull request May 14, 2022
`kIOMasterPortDefault` is deprecated since macOS 12.0.
One alternative is to use named constant `kIOMainPortDefault` which is not available before macOS 12.0.

Both named constants are just an alias for `NULL`, so it is simpler to use it directly instead.

Fixes: signal11#377
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants