mac: Option to open device in non-exclusive mode

[z3ntu]

Example: If you open a mouse currently (on macOS), the mouse input doesn't reach the OS, so you can't move the cursor with the mouse anymore while the device is opened in hidapi. That can be solved by not opening the device in exclusive mode, so z3ntu@fc9077c / signal11/hidapi#297

For my specific use case I have to look if it's possible to open a different usb device interface from the same device that doesn't block mouse input, but it seems that this feature is wanted by at least one other person too.

[Youw]

I think signal11/hidapi#335 refers to the same general issue, but on Windows
we need to consider an API that would allow specifying access mode

or not?

[z3ntu]

a.k.a #1

On Windows it seems it's not possible to open some devices in exclusive mode. On Mac both is possible, so no fallback is possible on the hidapi side. About Linux, I don't know :).

[Youw]

hmm, yes, it is different
would be nice to find out what possible regressions could z3ntu@fc9077c possibly cause, if there is any
after going thru documentation - I'd say, that there shouldn't be any (direct) issues, but theoretically, some project, might rely on the fact, that if a device is opened - it is opened in exclusive mode

on the other hand, we could add something like:
hid_open_path_opt(char* path, int bit_options) and define different options for different platforms (like OPEN_EXCLUSIVE for mac), to allow those projects restore their behavior

[z3ntu]

signal11/hidapi#295 (comment)

[mattsains]

I opened PR #148 to solve this

[Youw]

So I give this problem some thinking, and here what I suggest:

• accept Mac: hid_open_path in non exclusive mode #148 as is;
• add new API: hid_open<_path>_exclusive to cover current behavior;

Motivation:

1. On Windows hid_open/_path is non-exclusive in any case, so Mac: hid_open_path in non exclusive mode #148 will make the behavior consistent, which is great;

   • still need to check how hidraw/libusb behaves - don't really know yet;

   It will be very convenient for many users who find exclusive mode on macOS inconvenient/unusable;

2. hid_open<_path>_exclusive will make possible to preserve the old behavior for users which may rely on it;

3. Such approach won't break anything on both API/ABI levels for users who don't care how the device is open on macOS.

We still have 2 options for hid_open<_path>_exclusive:

1. Make it conditionally available (under ifdef for macOS-only (or other backend(s) that support it);
2. Make it available for all backends with fallback to non-exclusive mode, in case if backend doesn't support it (e.g. on Windows);

@z3ntu @libusb/hidapi thoughts?

[z3ntu]

add new API: hid_open<_path>_exclusive to cover current behavior;

I think adding an api like hid_open_opts (or if we follow Linux kernel naming hid_open2 😉) is a better choice. That way we can add options that control the behavior extensible & backwards-compatible (applications using these flags can use #ifdef if they want to support older hidapi versions).

We could add a flag OPEN_EXCLUSIVE where the documentation states the behavior on the different platforms which applications can request and we'll open the device non-exclusively or exclusively on macOS for example - and on other platforms where this isn't supported, ignore it.

Not sure if there are other "options" we could implement (or are already implemented somehow)

If possible I wouldn't change the behavior of existing APIs (so I don't think hid_open should be non-exclusive on macOS all of a sudden)

Make it conditionally available (under ifdef for macOS-only (or other backend(s) that support it);

Sounds horrible, as an application developer I don't want to add extra ifdefs for platform support (which probably differs between different hidapi versions). That's why we have hidapi and don't ifdef support for all platforms manually.

[Youw]

hid_open_opts

Yep, I like this way better too. (Hello from WINAPI world: hid_open_ex 😄)

If possible I wouldn't change the behavior of existing APIs

I'll try & give it additional thinking. On the plate right now:

• some projects are /already broken because of it/using custom forks/;
• new API will allow the old behavior;
• current default behavior is inconsistent with at least Windows (I will check libusb and hidraw too);
• some users might rely on current behavior (this one may count for more then one item);
• can't make up an example to strongly support current behavior, where exclusive access is mandatory (but not on all platforms);
• when I checked macOS implementation for the very first time, I was confused: it wasn't obvious why the exclusive access is required (would hidapi break, if it is not?);
• one more time - there might be projects in release (in some package manager) that rely on exclusive access;

[nikitalita]

Any movement on this? There are a lot of projects who have macOS support blocked by this.