现象：Direct 模式显示了，灯光却没有响应#

在使用 AVerMedia Live Gamer ULTRA 2.1（GC553G2）时，OpenRGB 能识别采集卡的 RGB 设备，但启动后直接在 Direct 模式调整颜色，灯光没有按预期变化。后来发现，先切换到 Autonomous，再切回 Direct，就能正常控制灯光。

更关键的是，无论 AVerMedia 官方软件中是否启用第三方灯光软件控制，这台设备都表现出相同的切换需求。我因此怀疑采集卡内部存在一个与第三方控制有关的状态，必须通过模式切换才能更新。这个解释与现象相符，但本次没有读取到能够直接证明该状态的设备字段，也没有足够证据将责任单独归给硬件、固件或 OpenRGB。

排查最初走了较大的弯路：一度认为 Linux 不支持这张卡，编写了设备专用的回退和范围更新，甚至准备提交一个改动范围较大的 PR。后来用原版 OpenRGB 对照，发现问题的范围比最初判断窄得多，最终放弃了那份 PR。

环境与结论边界#

• 采集卡：AVerMedia GC553G2，HID 设备 ID 为 07CA:D553，本次读到的固件版本为 0103。
• Linux：laptop 使用 Omarchy Linux，实测运行的系统软件包为 Arch Linux 的 openrgb 1.1-1；另外构建过包含实验性修改的 OpenRGB。
• Windows：同一台机器也用于 Windows 11 对照测试，系统中已有原版 OpenRGB。
• 设备灯珠：Windows 和 Linux 的一次成功读取都得到 10 颗灯，设备报告的最小更新间隔为 20 毫秒。

这些结果只描述本次设备和环境。Linux 属性读取的失败原因、采集卡内部状态的实际实现，以及实验性修复是否足以替代手动切换，都没有完成严格的因果验证。

最初的 Linux 实验与错误方向#

早期通过 Linux 的 hidraw 路径读取 LampArray 属性时，曾遇到 EINVAL。当时根据这个结果推测，OpenRGB 无法从设备获取属性，因而可能无法初始化采集卡灯光。

为验证这个假设，实验分支针对设备 ID、固件版本和描述符增加了窄范围回退，并尝试使用 LampArray 的 RangeUpdate 报告。自编译版本在 Linux 实机上经过人工确认：所有灯变红，以及红、蓝各 5 颗灯，均能显示。

但这个成功只能证明当时的组合能够控制灯光，不能单独证明属性回退或 RangeUpdate 是必要条件。实验过程中设备状态、控制命令和运行程序同时发生了变化，缺少逐项对照。

切回 Autonomous 后，设备显示纯蓝色。参考脚本发送同样的自主控制命令后也是纯蓝色；当时曾误以为这表示没有恢复自主灯效。后来确认，采集卡的自主灯光由官方软件配置，纯蓝色本身并不能判断切换失败，也不能把自主模式简单等同于熄灯或动态效果。

原版 OpenRGB 对照：推翻“Linux 不支持”#

后来直接检查 laptop 上正在运行的程序，发现它是系统安装的 /usr/bin/openrgb，由 Arch Linux 软件包 openrgb 1.1-1 提供，不是此前的自编译程序。包完整性检查没有发现文件被修改。

设备检测和程序状态有以下证据：

/usr/bin/openrgb is owned by openrgb 1.1-1
Bus 003 Device 006: ID 07ca:d553 AVerMedia Technologies, Inc. Live Gamer Ultra Pro-RGB
Registering RGB controller Live Gamer Ultra 2.1-RGB

该进程打开的 hidraw 接口也对应 07CA:D553。重新读取属性时，报告 ID 1 返回了 23 字节，并得到 10 颗灯：

GET report 1: result=23, lamps=10

原版 OpenRGB 在模式切换后可以控制设备，这推翻了“Linux 上的原版 OpenRGB 完全无法控制 GC553G2”的判断。早期的 EINVAL 与后来的读取成功确实不同，但其触发条件尚未查明；不能据此认定是 Linux、驱动或采集卡固件存在固定缺陷。

观察 OpenRGB 的 HID 报文#

单看命令行程序退出码为 0，无法确认设备真的应用了灯色，也不能确认它使用了哪种协议。为此，在 Linux 上使用临时 HIDAPI 跟踪库，观察系统版 OpenRGB 发出的 Feature 报告。测试结束后临时工具已删除。

关键记录如下；路径、时间戳和机器身份信息已省略：

GET  report 1: requested 23 bytes, returned 23
SET  report 2: requested 3 bytes,  returned 3
GET  report 3: requested 65 bytes, returned 29  （重复读取 10 次）
SET  report 6: 06 00, requested 2 bytes, returned 2
SET  report 4: requested 51 bytes, returned 51  （更新前 8 颗灯）
SET  report 4: requested 51 bytes, returned 51  （更新后 2 颗灯）
SET  report 6: 06 01, requested 2 bytes, returned 2

这里的报告属于标准 HID LampArray：报告 6 控制自主模式，报告 4 是 MultiUpdate。早期实验分支使用的报告 5 是同一标准中的 RangeUpdate，并不能因为编号不同就认定它是 AVerMedia 专用软件协议。

完整长度的返回值只能说明 HID 层接受了写入，不能证明设备已经应用颜色；灯是否实际变化仍需观察。本次 Linux 上红蓝分区的显示结果来自人工确认，而不是从写入返回值推断出来的。

Direct 与 Autonomous 的控制权#

USB HID Lighting and Illumination 规范说明，支持自主模式的设备可以在自主模式启用时自行决定灯光状态，并可以忽略主机的灯光更新。主机关闭自主模式后，需要等待设备报告的最小更新间隔，再发送首次灯光更新。

上游 OpenRGB 的代码路径中，切换模式时会发送控制报告；初始界面显示 Direct，并不必然代表设备已经收到关闭自主模式的报告。这与“先切 Autonomous 再切回 Direct 才生效”的观察一致，但仅靠这一点还不能证明采集卡内部状态或硬件缺陷的具体机制。

AVerMedia Gaming Utility 手册也列出了第三方灯光软件控制选项，并提醒避免多个灯控软件冲突。本次实际观察中，不论该选项是否启用，都需要做一次 OpenRGB 模式往返。因此，不能把这个选项作为已确认的根因。

缩小修复范围后的验证#

根据新的观察，后来试做了更小的通用 LampArray 修复：在首次 Direct 更新前发送主机控制报告，等待设备声明的间隔，失败时不继续发送颜色并允许后续重试；在 Autonomous 模式下不覆盖设备灯光。修改范围集中于现有 LampArray 控制器，没有再引入 GC553G2 专用描述符解析器。

模拟 HID 回归覆盖了首次控制、写入失败重试、模式切换和等待期间关闭。Linux 真机通信跟踪中，控制报告之后约 22 毫秒发出了颜色报告，HID 写入返回完整长度，随后又发送了 Autonomous 控制报告。这个结果验证了报文顺序，不等于确认用户实际看到了预期颜色。

还分别构建了 Linux 和 Windows 测试版。Windows 完整构建使用 MinGW，在临时副本中处理了上游构建配置及少量 Windows API 兼容问题；程序通过独立启动检查，但没有完成该版本的视觉灯效验证。不能把这些实验构建当作已验证、适合提交的最终修复。

为什么最终放弃这份 PR#

原计划中的 PR 为一个尚未确认的 Linux 专属问题引入了较大范围的通用 HID 解析和设备回退逻辑。原版程序的实机对照证明，问题并不是“Linux 原版完全无法控制”；实际可重复的现象是需要进行模式切换。继续提交原方案会让维护者审查大量并非已证明必要的代码，也可能影响其他 LampArray 设备。

因此，本次清理实验分支和构建产物，只保留这份排障记录。后续若要重新提出修复，应先在相同设备状态下验证：启动后直接改色、显式发送 Direct 控制命令后改色，以及完整 Autonomous → Direct 切换后改色是否分别生效；还要区分 HID 写入成功与灯光实际变化。

经验小结#

这次最有用的发现不是某条特殊报文，而是先确认正在运行的二进制，再对照模式切换和真实设备状态。原版和自编译版本、设备识别和颜色应用、命令成功返回和视觉结果，都是不同的证据。

当一个看似需要大量代码的修复已经出现时，先拿未修改版本复现，并只改变一个条件；如果对照推翻了前提，及时撤回 PR 比保留一份难以证明必要性的补丁更有价值。