Open debris opened 6 years ago
Sadly, looks like the answer is "no". @signal11 isn't doing much on GitHub, 128 open issues, 49 PRs and no commits since 2016.
If we don't hear from author within reasonable time - it could mean, that this repo is abandoned. And it is not good, since there is more and more forks and no true, well maintained library.
On the other hand, there is a comment from author on 15 Nov 2017. At least he's still here.
I find this one to work best. I really wish the author would still check in from time to time.
This library is sort of a thankless task. I wouldn't mind if more active collaborators were present. I notice this library has a lot of forks with changes. Perhaps some of those people could help out?
I asked single11 to come back and he did for a few question. So I'd expect he may come back yet again. Though I agree we just need more activity. This is why I deiced to answer am many questions as I could. I didn't write any of this code but I sure have used it for a long while in a straight run. IMO it is one of the best for c#.
Yes, this library is still active. todbot is right.
I've connected with Alan and will be doing my best to join in and help him where I can as another contributor.
There are a lot of branches. One thing to note is that many of them added fixes for their specific situation without doing due diligence for every scenario, kernel, hardware version. But I hope to make this less of an issue as time goes on.
@jdk Great, thanks for this commitment. It would be a shame to see this library unmaintained, since there are hardly any other cross-platform alternatives.
@signal11, maybe you could give @jdk write access to this repository?
If write access was given to someone (@jdk?) and a plan was put in place to begin resolving issues, I would be interested in helping. I need a cross platform HID (mac/win) layer for a work project, so I'll probably be forking this to fix any issues I encounter during that process. I would like to submit contributions/fixes, but it doesn't look like PRs have been merged or rejected in a while. If I'm gonna go through the pain of fixing stuff, I would rather share it on this repo rather than having it live forever on my own fork.
I'd also be willing to perform reviews of the existing PRs and to help manage merging known fixes (or rejecting erroneous ones).
@jdswensen unfortunately, I haven't heard from Alan in a while. = (
@jdk Let me try to contact Alan as well. HIDAPI is a great library and we at libusb project recommends HIDAPI over libusb for HID device.
Ref: https://github.com/libusb/libusb/wiki/FAQ#Does_libusb_support_USB_HID_devices
@mcuee, If you can't get a hold of Alan, would it be possible for libusb to host a fork? I think the biggest issue for maintaining the library is to have a rally point for discussion and development. If someone can't get access to this one, the community will need something else. libusb seems like a natural choice given that the project already has an established reputation and are actively recommending libusb users to consider using hidapi.
@jdswensen I do not see a problem using libusb mailing list for discussions related to HIDAPI. In fact, there were quite some HIDAPI related discussions there.
However, I am not so sure about hosting a fork under libusb. I will wait for Alan's response and then check with other libusb admins.
BTW, I've seen the fork with many activities here. Maybe people can start to use this fork to see if it helps. https://github.com/supercollider/hidapi
On the other hand the intention is a bit different. https://github.com/supercollider/supercollider/issues/3559
The extensions for SC on the hidapi library are quite substantial, involving the parsing of the hid descriptor. The purpose of the original hidapi library was more toward custom-made devices for which people would write their own software to read, so our extensions are also unlikely to fit into the purpose of the hidapi library.
Hi Contributors. It is 2019, if there is no chance to get write access from @signal11 maybe it's time to host the library on libusb and start integrating fixes for known issues? What do you think @mcuee?
This is a great cross-platform library used by a lot of people and it would be good to clean up the situation of many forks fixing different issues.
I'm also willing to help in fixing/reviews.
Here is contact info if someone wants to give him a call: http://www.signal11.us/contact.html
@Qbicz You may want to ask in libusb-devel mailing list to see how others look at this.
Hello again! I have asked on libusb mailing list if libusb can host this project. We received positive response from @LudovicRousseau.
Now we need a list of volunteers who would like to help in maintaining the library. @mcuee @jdk @jdswensen @jonathancross @todbot @ulao @debris @Youw, please confirm if you would like to volunteer.
Also if you know about other contributors who would like to join maintainers, please tell.
I don't mind helping out from time to time.
@Qbicz Confirm I would like to volunteer on maintaining hidapi
. I'm a maintainer of node-hid
(a dependent of hidapi
) and have a product that uses hidapi
. So I'm motivated to make hidapi
work. Just this weekend I was considering forking and adding all the PRs just to see what would happen.
I have a small collection of USB HID devices I currently test against. If there are specific ones that are a concern to the community (and they're not prohibitively expensive), I'd be happy to expand that collection.
Just to add my 2 cents: I consider these PRs top-priority once a new tree emerges :) : #335 #380 #219
Thanks in advance!
Maybe someone commenting here can clone repo and start maintain fork?
Done. See https://github.com/libusb/hidapi
Thank you very much @LudovicRousseau. We have already started reviewing important fixes, thanks for PRs @z3ntu.
@jdk @jdswensen and others, you can still volunteer if you want to help.
Good job, let's move on. But I would like to kindly ask @signal11 (or someone else) to put note in README that project moved, and to archive signal11/hidapi repo to prevent new PRs.
I am afraid only @signal11 can update the README on this project.
I have created an issue https://github.com/signal11/hidapi/issues/431 that can be a sign for contributors as long as it is on top. Also I want to update links in https://github.com/apmorton/pyhidapi
Over time, the new maintained project should rise in search results. I also fully agree with https://github.com/libusb/hidapi/issues/5
I’d very much like to contribute as much as I can.
Thank you for doing this Filip.
Very Sincerely, Jason
On Jun 5, 2019, at 3:07 AM, Filip Kubicz notifications@github.com wrote:
I have created an issue #431 that can be a sign for contributors as long as it is on top. Also I want to update links in https://github.com/apmorton/pyhidapi
Over time, the new maintained project should rise in search results. I also fully agree with libusb/hidapi#5
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I’d very much like to contribute as much as I can.
@LudovicRousseau can you add @jdk as a team member?
I invited @jdk to the hidapi team.
@Qbicz you should be able to add "Collaborators " yourself using https://github.com/libusb/hidapi/settings/collaboration If not tell me and I will review your access rights.
Thank you! No, it's not possible. In the "Team" tab only you have "Maintainer" status that can add and remove members.
In the "Collaborators & Teams" you should be able to add new collaborators. See screen copy
Just popping up this one. This repo is not longer maintained. Please use the new one. Thanks. https://github.com/libusb/hidapi
OK thx.
Latest commit to master was almost 2 years ago, and latest release was over 4 years ago. Is anyone looking after this library? If not, can push access be granted to some volunteers?