4

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

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

谢谢。

4

1 回答 1

8

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 承担，守护程序几乎不需要自定义即可在所有操作系统版本上运行。

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

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

于 2020-05-07T09:46:02.940 回答