Mac: hid_open_path in non exclusive mode #148

Closed
mattsains wants to merge 1 commit from master into master
mattsains commented 2020-02-21 20:39:01 -06:00 (Migrated from github.com)
Based on https://github.com/signal11/hidapi/pull/453
Youw commented 2020-02-22 05:37:22 -06:00 (Migrated from github.com)

The point is to be able to do it conditionally
The old behavior is might be required too

The point is to be able to do it conditionally The old behavior is might be required too
mattsains commented 2020-02-22 05:43:54 -06:00 (Migrated from github.com)

Can you do that with hidapi on Linux? My understand is that in Linux, hidapi does not use the device in exclusive mode. My intention with this PR is to make sure the behaviour on Mac is the same.

My motivation: I developed an application using this library on Linux, and it works great, but when I use the same application on Mac, it steals hid events from the rest of the environment. Essentially hidapi does not have consistency cross platform, and this impacts the functionality of cross platform applications using it

Can you do that with hidapi on Linux? My understand is that in Linux, hidapi does not use the device in exclusive mode. My intention with this PR is to make sure the behaviour on Mac is the same. My motivation: I developed an application using this library on Linux, and it works great, but when I use the same application on Mac, it steals hid events from the rest of the environment. Essentially hidapi does not have consistency cross platform, and this impacts the functionality of cross platform applications using it
Youw commented 2020-02-22 05:46:39 -06:00 (Migrated from github.com)

And you're not the first one :)
There're users, who are already using the library. They are relying on backward compatibility, when updating it.

And you're not the first one :) There're users, who are already using the library. They are relying on backward compatibility, when updating it.
mattsains commented 2020-02-22 05:51:13 -06:00 (Migrated from github.com)

Do you have examples of users who are expecting hidapi to work this way on Mac?

Do you have examples of users who are expecting hidapi to work this way on Mac?
Youw commented 2020-02-22 05:52:32 -06:00 (Migrated from github.com)

I don't

Do you have proof there is none?

I don't Do you have proof there is none?
mattsains commented 2020-02-22 05:56:02 -06:00 (Migrated from github.com)

No, but I do have a bunch who didn’t expect it to work the way it does, especially since the behaviour is different for different operating systems, and I don’t think this difference is documented.

I don’t really have the space to implement a new feature to specify which mode to use, so if you’re uncomfortable making the change proposed here then feel free to close this pr and I’ll just use my fork in my project and this bug will have to remain until someone else has time to fix it

No, but I do have a bunch who didn’t expect it to work the way it does, especially since the behaviour is different for different operating systems, and I don’t think this difference is documented. I don’t really have the space to implement a new feature to specify which mode to use, so if you’re uncomfortable making the change proposed here then feel free to close this pr and I’ll just use my fork in my project and this bug will have to remain until someone else has time to fix it
Youw commented 2020-02-22 06:10:42 -06:00 (Migrated from github.com)

"I don't have space/time" - is not a good excuse to fix something for some users, and potentially break something for others (we've been there)

I do believe we need to fix this, and yes, someone has to spend additional time to have this fix, AND allow the old behavior, AND don't break API/ABI compatibility for those who don't care

That "someone" is likely going to be myself

Since you came here and raised the issue one more time, I'll move it higher in my TODO list, but I strongly disagree to accept half measures

There'is other active maintainers/contributors, @libusb/hidapi @z3ntu, you'r opinion is welcome here too.

"I don't have space/time" - is not a good excuse to fix something for some users, and potentially break something for others (we've been there) I do believe we need to fix this, and yes, someone has to spend additional time to have _this_ fix, AND allow the old behavior, AND don't break API/ABI compatibility for those who don't care That "someone" is likely going to be myself Since you came here and raised the issue one more time, I'll move it higher in my TODO list, but I strongly disagree to accept _half measures_ There'is other active maintainers/contributors, @libusb/hidapi @z3ntu, you'r opinion is welcome here too.
mattsains commented 2020-02-22 06:14:29 -06:00 (Migrated from github.com)

Although I disagree, I understand your position. Good luck with the project. It would be nice to see this fixed.

Although I disagree, I understand your position. Good luck with the project. It would be nice to see this fixed.
Youw commented 2020-02-22 06:16:51 -06:00 (Migrated from github.com)

Thanks, we'll do our best

Thanks, we'll do our best

Pull request closed

Sign in to join this conversation.
No reviewers
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-libusb/hidapi!148
No description provided.