Problem Mac OSX with Digitizer + Bulk report ID

[bestel74]

Hi,
I have a problem using an USB HID graphic tablet (which succeed with the compliance USB Software) with multiple report ID :
1 is HID Mouse, 2 HID Digitizer, 3 and 4 are IN/OUT Bulk.

On windows, no problems.

On Mac, when I'm connected, the digitizer won't have any effect on my cursor, it just stop working.
When I disconnect, it's ok.

What's is the problem ?
I want to be able to use IN/OUT Bulk reports ID, but continue to use the Digitizer.

[bestel74]

On Windows, when I scan for devices with VID/PID I got 2 results.
If I connect to both, I get the same problem.

So on Windows for now I get :

• ?\hid#vid_2c87&pid_0001&mi_00&col03#7&38477...
• ?\hid#vid_2c87&pid_0001&mi_00&col01#7&38477...

And I choose to only connect to :

• ?\hid#vid_2c87&pid_0001&mi_00&col01#7&38477...

But on MAC I didn't get 2 results, so is there any workaround ?

[signal11]

Make sure you're using the latest from git (git clone).

I don't know the answer for your device. See what stepping through the code with a debugger can tell you.

[bestel74]

Thank you for your response.

I've made some printf, on Windows :
usage: 1
usage_page: 13
interface_number: 0
next: 5810840
usage: 0
usage_page: 65280
interface_number: 0
next: 0

On mac :
usage: 0
usage_page: 65280
interface_number: -1
next: 0

Maybe it can help you a little, maybe I have a problem with my device :(

[signal11]

What is that supposed to tell me? Those look like two different devices.

[bestel74]

Yeah but it's not.

I don't know, do you ever see a device with an interface not recognized on MAC (and maybe Linux) ?
This is the exact same device.

What you will look after ?

[signal11]

I haven't seen anything that behaves like that, but you've given me very little information.

[signal11]

You might just be running into an issue with this use case on the mac. From what you're saying, either you can talk to the digitizer or the system can talk to the digitizer. This kind of thing is not really what HIDAPI is designed for. It's designed to communicate with custom devices, not intercept information from standard input/output devices. The fact that this works as a side effect on some devices on some platforms doesn't mean results are guaranteed. For example, you can't open keyboards and mice on windows, and there's nothing I can do about it. It's an edge case that varies by platform.

[bestel74]

I have 4 report ID on my device :

• 1 HID Mouse
• 2 HID Digitizer
• 3 & 4 are IN/OUT Bulk buffer

On Windows I see 3 HID usb device :

• col01 -> my bulk interfaces
• col02 -> my HID Mouse
• col03 -> my HID Digitizer

So I understand now why I can only see 2 interfaces on Windows (no mouse = col2).
But, for what I understand, on MAC, I only see the HID interface.

Maybe the "vendor defined" interface is not available with hidapi?
This is what you're saying?
What can I do?

[signal11]

Vendor defined is what HIDAPI is designed for. Report ID's are not HID devices or interfaces. It's a different concept. See the HID specification.

[SlySven]

This might be wildly off-topic but don't some devices have the ability to change the device numbers they respond to depending on whether they have been "initialised" by some usually system driver - which in one of your cases could be happening in the "back-ground" before you get to see the device?

[bestel74]

Ok now I think I see the problem.

I have only one interface, which contain 3 logical devices, with 4 report ID.

• Windows create "one handler" per reported logicial HID applications, so no problems here.
• Linux create "one handler" for the entire HID device, so I receive the Digitizer report at the same place I use my bulk in/out. BUT Linux don't "stop"/"block" Digitizer messages, so I can continue to use the Digitizer while I'm connected and use my bulk in/out logicial interface.
• Mac has the same behavior than Linux, but once I'm connected to my device, Digitizer message get "blocked" and are not received by the OS.

[bestel74]

And I think I found my problem, line 706 of hid.c for Mac :
/* Open the IOHIDDevice */
IOReturn ret = IOHIDDeviceOpen(dev->device_handle, kIOHIDOptionsTypeSeizeDevice);

This establishes a link between the client's task and the actual device. To establish an exclusive link use the kIOHIDOptionsTypeSeizeDevice option.

Why this option is set by default ? To avoid some conflicts ?

[bestel74]

Here the pull request for this issue : #297

[signal11]

Why this option is set by default ? To avoid some conflicts ?

To prevent a device from being opened twice.

[mattsains]

Since there has been no update on pull request #297 from the submitter, I opened a new one, #453 to try and get this fixed.