RE of lghub_agent.arm64 (see HEADSET_RGB_HOSTMODE_WIRE_PROTOCOL.md) corrected the canonical protocol doc: FrameEnd byte 0 is a frame_type tag where 0x01 = transient commit and 0x02 = persistent/final flush. The firmware silently discards frames sent with byte 0 = 0x00 — the HID++ ACK succeeds but the staged color writes are never committed. This is why SetRgbZonesSingleValue appeared to succeed but LEDs never changed color on the tester's G522. The canonical doc's "For basic usage, all parameter bytes can be set to 0x00" is wrong. Change FrameEnd payload from `\x00\x00\x00\x00` to `\x01\x00\x00\x00`. Also worth noting (not fixed here): firmware auto-releases the host-mode claim if no Set+FrameEnd traffic arrives within a few seconds. HeadsetRGBColor already re-issues SetHostModeState(1) on every color change (the LGHUB "on-demand" model), so that covers the common case. HeadsetRGBHostMode toggle alone will still appear to "not stick" in GetHostModeState after the firmware release window — that's the firmware's behavior, not a bug. |
||
|---|---|---|
| .. | ||
| hid_parser | ||
| hidapi | ||
| keysyms | ||
| logitech_receiver | ||
| solaar | ||