Composite hid device that's also a keyboard on Mac OS X

dnaq commented

2021-10-13 13:22:58 -05:00

(Migrated from github.com)

I have an issue with implementing a HID-based protocol for a BLE device that is also a keyboard an getting it to work under Mac OS X. My guess is that the operating system refuses to give us access to the hid device due to the fact of it also being a keyboard. When using USB the solution is pretty simple, just use a different endpoint for the custom protocol, but for BLE we can only have a single HOG endpoint. I'm wondering if there is, or if it would be possible to implement, a way for hidapi to not try to grab the whole device, but instead just grab the reports of the usages we're interested in.

Youw commented

2021-10-13 15:19:53 -05:00

(Migrated from github.com)

the operating system refuses to give us access to the hid device due to the fact of it also being a keyboard

That is true. No workaround is possible on SW/HIDAPI side. The way HID driver is implemented on macOS, a device with multiple usage_pages/usages is represented as a single undividable device.

When using USB the solution is pretty simple, just use a different endpoint for the custom protocol

Agree, that's what I'd do.

but for BLE we can only have a single HOG endpoint

This is a bit suprising, I've imagined that something similar should be possible.
But I have never worked with BLE devices so I cannot be sure or give any hints.

> the operating system refuses to give us access to the hid device due to the fact of it also being a keyboard That is true. No workaround is possible on SW/HIDAPI side. The way HID driver is implemented on macOS, a device with multiple usage_pages/usages is represented as a single undividable device. > When using USB the solution is pretty simple, just use a different endpoint for the custom protocol Agree, that's what I'd do. > but for BLE we can only have a single HOG endpoint This is a bit suprising, I've imagined that something similar should be possible. But I have never worked with BLE devices so I cannot be sure or give any hints.

dnaq commented

2021-10-14 02:11:23 -05:00

(Migrated from github.com)

Looking into the issue a bit more it seems like we can grab the device if we run the application under sudo and if we allow "Input Monitoring" for the application under Privacy/Input Monitoring in the security & privacy settings.

The next issue is that this causes the keypresses of the device to not be handled by the operating system. I think this might be because of the kIOHIDOptionsTypeSeizeDevice flag when opening the device. I haven't been able to investigate that further for now, but I'm planning to see what happens without that flag set.

Looking into the issue a bit more it seems like we can grab the device if we run the application under sudo and if we allow "Input Monitoring" for the application under Privacy/Input Monitoring in the security & privacy settings. The next issue is that this causes the keypresses of the device to not be handled by the operating system. I think this might be because of the `kIOHIDOptionsTypeSeizeDevice` flag when opening the device. I haven't been able to investigate that further for now, but I'm planning to see what happens without that flag set.

👍 1

dnaq commented

2021-10-14 07:50:55 -05:00

(Migrated from github.com)

And this seems to work beautifully and not need root permissions anymore. So just changing that flag to zero makes us able to open those devices from normal user applications if the Input Monitoring setting is enabled for our application.

👍 1

Youw commented

2021-10-14 08:24:53 -05:00

(Migrated from github.com)

That is something that has been on our place for some time. If we remove that flag by default with a new update - that will break backward compatibility for programs that may rely on it. I'm currently thinking on the alternative approach.

dnaq commented

2021-10-14 08:40:30 -05:00

(Migrated from github.com)

Would it break backwards compatibility though? The hidraw backend on Linux doesn't allow exclusive access afaik. I don't know how the situation is on windows, but shouldn't hidapi cater to the "lowest common denominator"?.

If that is an issue another option is to expose an open_nonexclusive() function, but I'm not sure that would be needed.

Would it break backwards compatibility though? The hidraw backend on Linux doesn't allow exclusive access afaik. I don't know how the situation is on windows, but shouldn't hidapi cater to the "lowest common denominator"?. If that is an issue another option is to expose an `open_nonexclusive()` function, but I'm not sure that would be needed.

Youw commented

2021-10-14 08:57:19 -05:00

(Migrated from github.com)

It is not about what it should or shouldn't do. HIDAPI has been opening the device on macOS exclusively since the very first version. And even if it is beeter not to do this way by default, by changing the default, we break the backward compativility of the programs that are already using HIDAPI on macOS and rely on such behavior explicitly or implicitly.

It is not about what it should or shouldn't do. HIDAPI has been opening the device on macOS exclusively since the very first version. And even if it is beeter not to do this way by default, by changing the default, we break the backward compativility of the programs that are _already using HIDAPI on macOS_ and _rely on such behavior_ explicitly or implicitly.

dnaq commented

2021-10-14 09:10:20 -05:00

(Migrated from github.com)

I understand what you mean, I’m just saying that since other platforms hidapi support do not open the devices with exclusive access the probability of a Mac OS X application using hidapi depending on that behaviour would be pretty low. The reason being that the main reason of using hidapi on Mac OS X would be portability.

That being said I’m not advocating for changing the default, you surely know a lot more about hidapis users than I do, but I would be grateful for being able to open the device in non-exclusive access mode (without having to resort to patching hidapi).

I understand what you mean, I’m just saying that since other platforms hidapi support do not open the devices with exclusive access the probability of a Mac OS X application using hidapi depending on that behaviour would be pretty low. The reason being that the main reason of using hidapi on Mac OS X would be portability. That being said I’m not advocating for changing the default, you surely know a lot more about hidapis users than I do, but I would be grateful for being able to open the device in non-exclusive access mode (without having to resort to patching hidapi).

Youw commented

2021-10-15 05:09:01 -05:00

(Migrated from github.com)

but I would be grateful for being able to open the device in non-exclusive access mode

You're not the only one:

I'm currently thinking on the alternative approach.

> but I would be grateful for being able to open the device in non-exclusive access mode You're not the only one: > I'm currently thinking on the alternative approach.

mcuee commented

2021-10-18 20:41:02 -05:00

(Migrated from github.com)

Is it possible to add a new API (or new API option) to open in non-exclusive access mode?

Youw commented

2021-10-20 18:51:51 -05:00

(Migrated from github.com)

@mcuee please check my suggestion from some time ago: https://github.com/orgs/libusb/teams/hidapi/discussions/4 (this link is available only for HIDAPI team members).

👍 1

Rows
Columns

Composite hid device that's also a keyboard on Mac OS X #344