HID Entitlement Configuration Guide:
NOTE:The document assumes you're already familiar with the DEXT loading process, as described here.
Here are the three core kernel support drivers and their corresponding HID entitlements:
- AppleUserHIDDevice-> com.apple.developer.driverkit.family.hid.device
- AppleUserHIDEventService-> com.apple.developer.driverkit.family.hid.eventservice
- IOHIDInterface-> com.apple.developer.driverkit.transport.hid
When building a HID DEXT, you'll first determine your kernel support (IOClass) driver, then include that entitlement in your DEXT. Including any other HID entitlement is unnecessary.
Additional Entitlements
There are two other HID-related entitlements worth noting:
-
com.apple.developer.driverkit.family.hid.virtual.device -> This entitlement is a defunct entitlement that has no function on any of our platforms. It should not be included in any product and will be removed from the documentation in the future (r.184046926).
-
com.apple.developer.hid.virtual.device -> This entitlement controls access to the CoreHID virtual device API. This is NOT a DEXT entitlement and should never be included in a DEXT.
Note that the concept of "virtual" devices in DriverKit is somewhat misleading. A DEXT can publish a "virtual" device, but that’s because a DEXT is the ultimate arbitrator that controls what's visible to the system AT ALL. Putting that in more concrete terms, the system itself doesn't really differentiate between:
-
A standard USB HID device.
-
A software-only HID device.
-
A Thunderbolt mouse (hypothetical).
-
A Ethernet mouse (hypothetical).
Like most other IOKit families, the system makes no strong attempt to identify the transport bus[1], so, as far as the system is concerned, all of those are just "HID devices". Within that architecture, CoreHID virtual device API works by using an existing kernel driver to publish new HID devices to the system, duplicating exactly the same architecture a DEXT-based virtual HID driver would use. There's no reason to prefer a DEXT-based solution over CoreHID, as the DEXT simply requires more work without significant benefit.
[1] Many places in the system do include information about "where" a device is located. In most cases, this is nothing more than a string directly published by the corresponding driver as an IORegistry key/value. In other words, a device labeled "USB" could easily have been labeled "FireWire", "PCI", "Nowhere", or anything else the driver chose to label it.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware