USB HID Consumer Volume相对输入在Win10中自动重复异常问题

我用旋转编码器实现了一个HID设备，用于控制主机PC的音量，对应的报告描述符如下：

0x05, 0x0C, /* Usage Page (Consumer). */
0x09, 0x01, /* Usage (Consumer Control). */
0xA1, 0x01, /* Collection (Application). */
0x85, 0x03,   /* Report ID (3). */
0x05, 0x0C,   /* Usage Page (Consumer). */
0x95, 0x02,   /* Report Count (2). */
0x75, 0x01,   /* Report Size (1). */
0x15, 0x00,   /* Logical Minimum (0). */
0x25, 0x01,   /* Logical Maximum (1). */
0x09, 0xE9,   /* USAGE (Volume Increment). */
0x09, 0xEa,   /* USAGE (Volume Decrement). */
0x81, 0x26,   /* Input (Data,Var,Rel,No Wrap,Linear,No Preferred State,No Null Position). */
0xC0,       /* End Collection. */

该设备在Linux上运行完全正常，但在Windows 10中表现出异常的不一致行为：

• 旋转旋钮多格时，功能完全正常；
• 沿上次相同方向旋转旋钮一格时，功能完全正常；
• 沿与上次相反方向旋转旋钮一格时，Windows会自动重复该指令，直至音量调到0%或100%才停止。

我已将数据指定为Relative类型，且设置了No Preferred State和No Null Position，为何设备停止发送报告后，Win10仍会在特定场景下自动重复操作？

补充说明（11月28日11:14）：若设备在每个非空报告之后发送NULL报告，可解决该问题，但疑问仍存——为何Windows会对明确配置为非重复类型的输入执行自动重复？

问题解答 #

这是因为Windows的HID消费者类驱动与Linux的处理逻辑存在差异。尽管你在报告描述符中标记了Rel（相对输入）和No Null Position，但Windows驱动在处理单步反向操作时，会误将单次触发的相对输入判定为持续输入状态。

本质原因是Windows消费者控制驱动对这类单bit的相对输入，默认依赖“空报告”来确认输入已终止。当你仅发送一次反向单格的报告却不跟进空报告时，驱动无法及时感知输入停止，进而触发系统的自动重复机制——这是Windows驱动为兼容部分老旧HID设备设计的 fallback 逻辑，这类设备可能不会主动发送输入停止的信号。

而Linux的HID驱动在处理相对输入时，无需额外空报告来终止状态，它会将每个单独的报告视为独立的单次操作，因此不会出现重复触发的问题。

内容的提问来源于stack exchange，提问作者DarkFranX