我应该使用 IOKit 或 DriverKIt（或 HIDDriverKit）为 macOS 中的 USB 或蓝牙多点触控设备编写驱动程序吗？

Question

我打算为 USB 或蓝牙多点触控设备编写驱动程序，类似于 Mac 的 Apple Magic Trackpad 或 Logitech 触控板。

这个想法是所有 macOS 应用程序都可以使用这个多点触控设备。由于新推出的DriverKit（或HIDDriverKit）将与应用程序捆绑在一起，我应该继续使用IOKit还是应该使用DriverKit？

谢谢。

Answer 1

DriverKit 是围绕 IOKit 构建的——它只是它的另一个接口。所以我想你的问题真的是你的驱动程序是否应该实现为：

• DriverKit 系统扩展 (dext)
• 内核扩展 (kext)
• 别的东西

无论哪种方式，您都不会逃避 IOKit，因为 USB 设备只能通过 IOKit 访问，并且 HID 堆栈也构建在其上。

蓝牙

据我所知，还没有用于 DriverKit 的蓝牙 API，至少现在还没有。（从 macOS 10.15.4 开始）

因此，如果您的设备使用需要从头开始转换为 HID 事件源的自定义蓝牙协议，那么我认为您将无法使用 DriverKit，至少不是唯一的。

如果您的设备已经作为 HID 设备出现在系统中，但您的驱动程序需要重写 HID 报告，那么我认为可能可以使用 DriverKit 来实现 - 至少值得研究。

将它实现为 kext 肯定适用于所有情况，问题是任何新的 kext 在此阶段的保质期都非常有限。

USB

对于 USB，它更简单，有直接的 DriverKit USB API。USB HID 驱动程序是 DriverKit 支持的场景之一。因此，此时您绝对不应该使用 kext 来实现针对 macOS 10.15+ 的 USB HID 驱动程序。事实上，如果你确实开发了一个 USB HID kext，你的用户会定期看到一个可怕的警告弹出窗口。

“还有什么？”

这将我们带到了“其他”类别：您可以（几乎）完全在常规用户空间中将驱动程序编写为使用用户空间蓝牙和 USB API 的守护程序，然后将产生的 HID 事件注入系统。执行此操作的最佳方法可能最终是通过 DriverKit 驱动程序 - 因此您将拥有一个用户空间守护程序执行大部分驱动程序逻辑，以及一个小型 DriverKit 驱动程序创建一个“虚拟”HID 设备，该设备只传输由守护进程进入 HID 堆栈。如果您需要支持较旧的操作系统版本，这种方法中 dext 的责任可以由 kext 承担，守护进程几乎不需要任何自定义即可在所有操作系统版本上运行。

如果您的驱动程序将对原始输入数据进行大量复杂的处理，这可能是前进的方向，因为在 dex 或 kext 中实现此类逻辑并不理想。

要说哪种方法最好，我真的需要更多地了解设备（这可能超出了 Stack Overflow 问题的范围……）。