是否应该使用IOKit或DriverKIt(或HIDDriverKit)在macOS中为USB或蓝牙多点触控设备编写驱动程序?

xbing6

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

这个想法是所有macOS应用程序都可以使用此多点触控设备。由于新引入的DriverKit(或HIDDriverKit)将与应用程序捆绑在一起,我是否仍应使用IOKit还是应该使用DriverKit?

谢谢。

pmdj

DriverKit基于IOKit构建-它只是它的另一个接口。所以我想您的问题确实是您的驱动程序是否应实现为:

  • DriverKit系统扩展(dext)
  • 内核扩展(kext)
  • 还有别的

您不会以任何方式逃避IOKit,因为USB设备只能通过IOKit进行访问,并且HID堆栈也是基于IOKit构建的。

蓝牙

据我所知,目前还没有用于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产生的事件将守护程序放入HID堆栈。如果需要支持较早的OS版本,则kext可以由dext负责此方法,而守护进程实际上不需要自定义即可在所有OS版本上运行。

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

要说出哪种方法最好,我真的需要对设备有更多的了解(这可能超出堆栈溢出问题的范围……)。

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章