Field testing on G522 showed two problems:
1. GetRGBZoneInfo returned all zeros (count=0, all-zero body) when
queried BEFORE SetHostModeState(1). Protocol doc's recommended
order is: claim host mode first, then enumerate zones. Our code
was querying zones first.
2. The response format the G522 returns does NOT match the doc's
layout. Doc says [count, 3 reserved, 1 reserved, zone_ids...] but
the G522 seems to pack them tight as [count, zone_ids...] — the
SetRgbZonesSingleValue response "0801020304050607080000" decodes
cleanly as count=8, zones=[1..8] under the tight format.
Fixes:
- Call SetHostModeState(1) before GetRGBZoneInfo.
- Try tight format first, fall back to doc format. Only cache a
parsed result if it makes sense (non-zero zone IDs, count matches).
- Don't cache ambiguous results so subsequent writes retry.
This also incidentally suggests the G522 has 8 RGB zones (not the 2
left/right earcups we were guessing) — the red set we sent in the
previous test probably did set zones 0x01 and 0x02 correctly, but
those zones are only a fraction of the total lighting so the color
change wasn't visible.
256f2e556b