Can a third-party DriverKit HID dext seize raw HID reports from an external mouse via a top case–related path?

Question

Created 1w

Replies 2

Boosts 0

Participants 2

We are trying to determine whether a third-party DriverKit HID dext can seize or intercept raw HID input reports from an external mouse through any top case–related path in the HID stack.

Our dext is based on IOUserHIDEventDriver, and the goal is to receive raw input reports before they are translated into higher-level pointer events. Apple’s public HIDDriverKit documentation describes IOUserHIDEventDriver as the driver object responsible for dispatching pointer, digitizer, scrolling, and related HID-originated events, but it is not clear to us whether any “top case” path is actually exposed or supported for third-party matching in DriverKit.

What we want to clarify is specifically about external mouse devices, not the built-in trackpad itself.

Questions:

Is there any officially supported way for a third-party DriverKit HID dext to bind through a top case–related path and receive raw HID input reports from an external mouse?
Is “top case” something that third-party DriverKit drivers can meaningfully target for matching/attachment, or is it only an internal Apple implementation detail?
If such a path exists, can it be used to seize raw reports before they are converted into higher-level pointer events?
If not, what is the officially supported boundary for third-party DriverKit access to raw reports from external mouse-class HID devices?

To be clear, we are not asking about synthesizing pointer events. We are asking whether a third-party DriverKit dext can directly observe or seize the original HID input reports from an external mouse by attaching through any top case–related portion of the HID stack.

If “top case” is not a public DriverKit concept that third parties can target, confirmation of that would also be very helpful.

Boost

Answer 1

Skygreed OP

1w

To clarify our use case, this would be used strictly for academic research purposes.

0

Answer 2

DTS Engineer OP

Apple

2h

First off, as a general note, I've done my best to answer your questions below, but what I'd actually like to understand is what your larger product goal actually is, independent of any particular technology (like DriverKit).

My concern here is that you're focusing on DriverKit because it's one of our more "visible" technology layers and then asking how it can solve your problem... without ever realizing that there are other API options that would actually be a far better solution.

As a concrete example of this, I regularly see questions from developers trying to write DEXTs for vendor-specific USB devices who don't realize that the RIGHT way to work with a vendor-specific USB device on macOS is the IOUSBHost framework.

intercept raw HID input reports from an external mouse through any top case–related path in the HID stack.

This is the first time I've heard the term "top case," but from the general context, I'm going to guess that your goal is to intercept and modify the events 3rd-party HID devices are sending "to" the system, instead of matching and controlling a specific HID device. The rest of my response is focused on goal, but please let me know if I've misunderstood what you're trying to do.

Getting into things:

We are asking whether a third-party DriverKit dext can directly observe or seize the original HID input reports from an external mouse by attaching through any top case–related portion of the HID stack.

The key word here is "DriverKit". DriverKit is focused on supporting hardware drivers for specific devices, and part of that design is that we don't support the creation of drivers that match against "any" device[1]. So in that sense, no, DriverKit can't really be used for this.

However, there is a slightly different approach which might work. That approach is to:

Use CoreHID to seize the device, routing all HID activity to your process instead of the system.
Use a virtual HID device to send HID event back into the system for final processing.

I haven't tested this approach, so it's possible there are issues/edge cases that would prevent it from working, but in theory, it should work.

Finally on this point:

To clarify our use case, this would be used strictly for academic research purposes.

Is this something you’d be using on dedicated test machines or distributing to a broader user base? If this only needs to work on “your” dedicated hardware, then that opens up a broad range of options (like disabling SIP/AMFI or installing KEXTs) which wouldn’t really be an option in a shipping product.

[1] Strictly speaking, the Development Only entitlements DO allow very generic matching, but that's specifically about simplifying the development workflow, NOT about providing useful functionality.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0