Hey there,
first of all thanks for the invested time. ❤️

I tested this PR locally on Linux Mint 22.1 with a Logitech G733 (046d:0afe).

What worked correctly on real hardware:

• build succeeded
• ctest --output-on-failure passed
• pure color setting in the static color path worked correctly when tested in isolation from an off state (255,0,0, 0,255,0, 0,0,255 showed as red, green, blue)
• --light-mode static, --light-mode breathing, and --light-mode wave all worked functionally
• legacy -l 0 / -l 1 still worked

However, I found a behavioral issue with combined lighting state:

• --light-brightness does not preserve the current color and falls back to cyan
• --light-mode also falls back to cyan instead of preserving the previously selected color
• --light-color appears to force brightness back to 100 instead of preserving a previously selected brightness

This also matches the current implementation in lib/devices/logitech_g633_g933_935.hpp:

• setLights(): hardcoded cyan defaults around lines 102-106
• setLightBrightness(): hardcoded cyan around lines 154-157
• setLightMode(): hardcoded cyan around lines 184-188
• setLightColor(): fixed brightness = 100 around line 130

So from my testing, isolated static color control looks good, and the animation modes themselves do work, but combined color/mode/brightness state is not fully preserved yet on 046d:0afe.

I think the underlying issue is state composition rather than the raw packet format itself.

A cleaner fix would probably be to store the current lighting state in the device instance (RGB, brightness, mode, speed, enabled) and have all of setLights(), setLightColor(), setLightBrightness(), setLightMode(), and setLightSpeed() update that state and then call a single helper that writes the full state to both zones.

Code review — 2 issues found

Issue 1: Color lost when combining --light-color with other light flags

File: lib/devices/logitech_g633_g933_935.hpp, lines 154–157

setLightBrightness, setLightMode, and setLightSpeed all hardcode RGB to (0x00, 0xff, 0xff) (cyan). The class stores light_mode_ and light_speed_ as members but has no light_color_ member, so when any of these runs after setLightColor, the device is reprogrammed to cyan and the user-supplied color is lost.

Reproducer: headsetcontrol --light-color purple --light-mode breathing ends up cyan-breathing because setLightMode runs second and calls sendZoneLighting with hardcoded cyan. The comment // Keep current color roughly cyan if we don't know previous color acknowledges the root cause. The same hardcoded pattern appears in setLightMode (lines 184–188) and setLightSpeed (lines 227–231).

Fix: Add mutable std::array<uint8_t, 3> light_color_ {0x00, 0xff, 0xff}; to the private section, persist it in setLightColor, and replace the three hardcoded r/g/b blocks with reads from light_color_.

Issue 2: C API enum renumbering is an ABI-breaking change

File: lib/headsetcontrol_c.h, lines 91–107

The four new HSC_CAP_LIGHT_* entries are inserted at positions 4–7, shifting every existing value by 4 (HSC_CAP_INACTIVE_TIME moves from 4 to 8, HSC_NUM_CAPABILITIES from 16 to 20). Any pre-compiled consumer of the public C library API (the GUI apps in README.md) that passes the old integer 4 for inactive time will silently query HSC_CAP_LIGHT_COLOR instead.

Fix: append the new entries to the end of the enum to preserve existing integer assignments:

    HSC_CAP_INACTIVE_TIME                  = 4,
    ...
    HSC_CAP_BT_CALL_VOLUME                 = 15,
    HSC_CAP_LIGHT_COLOR                    = 16,
    HSC_CAP_LIGHT_BRIGHTNESS               = 17,
    HSC_CAP_LIGHT_MODE                     = 18,
    HSC_CAP_LIGHT_SPEED                    = 19,
    HSC_NUM_CAPABILITIES                   = 20,

Note: the C++ capabilities enum in lib/device.hpp is used only by name (never by integer), so it is not affected.