报告描述符中 HID 使用的基本要求是什么?

What are the bare requirements for HID usages in a report descriptor?

我目前正在规划低功耗蓝牙 (BLE) 设备的代码,该设备将在蓝牙规范中的 HID over GATT 配置文件上运行。我已经阅读了 HID 规范 1.11 和用法表 1.12,但我找不到任何关于 Usage_pages 和用法的最低要求使用的信息。

由于我们同时实现了主机和设备,计划是为我们的报告描述符使用供应商定义的使用页面,但由于我们的目标是快速连接和低功耗,我不希望在 HID over GATT 的报告定义阶段发送比我必须发送的字节更多的字节。因此,我正在考虑删除所有通常会标记 input/output 的用法,因为它们看起来只是语义。

这是我正在考虑的示例:

    Usage_Page( Vendor Defined)
    Usage( Vendor 1)
    Collection(Application)
         Collection(Logical)               ; First Collection and Report
         Report_ID(1)
         Usage_Page(Button)                ; This is what the specification seems to encourage
         Usage_Minimum(Button 1)
         Usage_Maximum(Button 3)
         Logical_Minimum(0)                ; Logical limits
         Logical_Maximum(1)
         Report_Size(3)                    ; Three bits corresponding to the buttons
         Report_Count(1)                   ; One of the three bit sets
         Input( Data, Variable, Absolute)  ; Make it an input
         Report_Size(5)
         Report_Count(1)
         Input(Constant)                   ; Pad the transmitted byte
         Collection End
    Collection End

当我查看 this 时,我看到很多额外的字节什么都不做,因为我没有使用本机解析器。这些范围从用法到甚至逻辑 minimums/maximums。如果我只使用顶级用法而不使用诸如逻辑最大值之类的东西来定义我的报告描述符,会有什么后果?

兼容的解析器应该接受以下优化的描述符:

 0x85, 0x01,                    // ReportID (1)
 0x05, 0xff,                    // UsagePage (255)
 0x09, 0x01,                    // Usage (1)
 0xa1, 0x01,                    // Collection (Application)
 0x25, 0x01,                    //     LogicalMaximum (1)
 0x75, 0x01,                    //     ReportSize (1)
 0x05, 0x09,                    //     UsagePage (Button)
 0x19, 0x01,                    //     UsageMinimum (Button(1))
 0x29, 0x03,                    //     UsageMaximum (Button(3))
 0x95, 0x03,                    //     ReportCount (3)
 0x81, 0x02,                    //     Input (Variable)
 0xc0,                          // EndCollection
  • 逻辑最小值默认为 0,
  • 最后一个字节末尾的填充是免费的。

另请注意,HoG 的所有中央端实现(Win、Bluez、CoreBluetooth 和 Bluedroid)实际上会在配对发生时缓存报告描述符,以最大程度地减少重新连接时间。因此,报告描述符的实际大小并不那么重要:它只会在配对时花费一次时间,而且可能再也不会(当然,直到设备再次配对)。

还要考虑报告描述符读取表示中央和外围设备之间交换的几个数据包(每 20 个字节一个,默认 MTU),每次往返花费两个时间间隔(如果两个堆栈实现都不是太糟糕),这将在 60 毫秒左右(大多数中央连接的默认间隔为 ~30 毫秒)。因此,当您的报告描述符长 60 个字节时,实际发现延迟将少于 200 毫秒...对于在设备生命周期中只发生一次的事情来说,这不是什么大问题。

最后,附注:您可能不应该使用特定于供应商的集合类型,而应尝试坚持使用标准集合类型。在大多数情况下,它将允许您的设备进行无人驾驶操作。

不要忘记,即使您只预见到硬件的特定应用用途,有些人实际上可能很乐意将其重新用于其他用途。如果是这样,无人驾驶更好,除非你想完全禁止第三方使用,但首先使用 HID 是没有意义的。 (HID 是为无人驾驶设计的,我仍然很困惑看到鼠标和游戏手柄、遥控器和按钮的驱动程序只是因为制造商的懒惰。)