USB HID Feature Report 调试：GET_REPORT、SET_REPORT、厂商命令与设备配置丢失

HID 设备不只有键盘鼠标。它还包括安全令牌、传感器、控制面板、厂商工具、工业设备、游戏手柄、UPS、自定义配置接口。很多这类设备用 HID Feature Report 做配置和状态读取。Feature Report 一出问题，用户就会搜 "HID Feature Report 不工作"、"GET_REPORT 失败"、"SET_REPORT 失败"、"HID Report ID 不匹配"、"USB HID 厂商命令超时"——因为普通输入还正常，就是配置那条路走不通。

Bus Scope 在这个场景下有用，因为 Feature Report 通常走端点 0 的 Control Transfer。实际的 Setup Packet、Report Type、Report ID、长度、响应状态都很关键。

什么是 Feature Report

HID 有几种 Report 类型：

• Input Report
• Output Report
• Feature Report

Input Report 通常走 Interrupt IN 端点。Feature Report 通常用 Control Transfer 通过 GET_REPORT 或 SET_REPORT 来访问。

设备按键正常但配置面板打不开，问题很可能就在 Feature Report 处理上。

Report ID 和长度不匹配

很多 HID 设备用 Report ID。如果主机发的是 Report ID 3，固件却以为 Report ID 0，请求就会失败或者回错数据。

常见 bug：

• 固件漏了 Report ID 字节
• 主机发的 Report 长度不对
• 描述符声明一个长度，固件返回另一个
• Feature Report 在固件里有，但描述符里没声明
• 描述符声明了 Report，但固件从没实现

HID Report Descriptor 和 Control Transfer 必须放在一起对比。

GET_REPORT / SET_REPORT 的证据

要查的：

• Setup Packet 的请求类型
• HID GET_REPORT 或 SET_REPORT
• Report Type = Feature
• Report ID
• wLength
• 数据阶段字节
• STALL 或超时

设备如果对自己描述符里声明的 Feature Report 返回 STALL，嫌疑就在固件或描述符的一致性。

通过 HID 做厂商配置

很多产品选 HID 是为了避开自定义内核驱动。厂商设置经常实现成 Feature Report。

例子：

• 修改采样率
• 读取固件版本
• 设置 LED 模式
• 配置传感器量程
• 进入 Bootloader
• 读校准数据

如果这些命令失败，设备看起来仍然是一个合法的 HID 设备。

排查清单

按这个流程：

1. 抓枚举和 HID Descriptor
2. 保存 HID Report Descriptor
3. 识别 Feature Report 定义
4. 抓失败的 GET_REPORT 或 SET_REPORT
5. 检查 Report ID
6. 检查请求的长度
7. 对比描述符长度和传输长度
8. 查 STALL、超时、短响应
9. 对比正常的 Input Report 和失败的 Feature Report
10. 描述符和控制传输一起留存

最终诊断

HID Feature Report 失败，根因往往在描述符、Report ID、长度、固件状态、或控制传输处理。Input 可以正常，但配置走不通。

Bus Scope 把 HID Report 契约和真实失败的控制传输都摊开来——Feature Report 的 bug 不再是神秘的厂商工具错误，而是可以诊断的。