You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed while implementing the NetBSD backend that each platform has different defaults. hidraw has no locking by default. uhid has mandatory locking in most implementations. I don't know what the situation is for the Mac and Win32 backends.
Would there be any value in adding an API for locking the device in the hidapi backend? For most unix platforms, flock can be used to achieve advisory locking for cooperating applications so it isn't without its merits but this would only be effective where the platform doesn't already enforce its own locks beyond the control of the application.
I could see there being value in the application having a way to get a lock on the device as well as knowing the type of lock that is in effect because sharing access between applications may be a problem depending on the device being used. I have seen devices that use vendor HID protocols that are stateful and therefore should not be interrupted by another application. One example is a HID device that implemented ymodem protocol by treating the HID transport as a packet system in order to upload firmware updates.
The text was updated successfully, but these errors were encountered:
The thing is that there is no uniform to this approach. Depending on the platform - not everything is possible (e.g. libusb doesn't allow shared access to the device at all).
I've described this somewhere in comments to other tickets and can find my full answer at the moment.
Long story short: you may add something backend-specific if you think that makes sense.
I noticed while implementing the NetBSD backend that each platform has different defaults.
hidraw
has no locking by default.uhid
has mandatory locking in most implementations. I don't know what the situation is for the Mac and Win32 backends.Would there be any value in adding an API for locking the device in the
hidapi
backend? For most unix platforms,flock
can be used to achieve advisory locking for cooperating applications so it isn't without its merits but this would only be effective where the platform doesn't already enforce its own locks beyond the control of the application.I could see there being value in the application having a way to get a lock on the device as well as knowing the type of lock that is in effect because sharing access between applications may be a problem depending on the device being used. I have seen devices that use vendor HID protocols that are stateful and therefore should not be interrupted by another application. One example is a HID device that implemented
ymodem
protocol by treating the HID transport as a packet system in order to upload firmware updates.The text was updated successfully, but these errors were encountered: