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.