Skip to content

Add tools for the GP2040-CE Host Lighting add-on - #12

Open
djGLiTCH wants to merge 3 commits into
OpenStickCommunity:mainfrom
djGLiTCH:20260811-host-lighting-tools
Open

Add tools for the GP2040-CE Host Lighting add-on#12
djGLiTCH wants to merge 3 commits into
OpenStickCommunity:mainfrom
djGLiTCH:20260811-host-lighting-tools

Conversation

@djGLiTCH

Copy link
Copy Markdown

Companion to OpenStickCommunity/GP2040-CE#1691, which adds
the Host Lighting add-on: a vendor HID interface for driving a board's RGB
LEDs from host software. These tools talk to that interface:

  • hlp-ping verifies the protocol handshake and measures the command
    round-trip
  • hlp-caps decodes the board's self-reported capabilities page by page
    (identity, runtime state, the LED map, animations, per-light positions)
  • hlp-fill runs a quick visual test and hands control back to the
    board's animations
  • hlp-input-mode, hlp-reboot-webconfig, hlp-reboot-bootsel manage
    the board over the same interface

Discovery is by usage page (0xFF47), never VID:PID, and multiple connected
boards are selected between with --board-id (the factory-unique ID from
the capability pages). The HID transport uses hidapi (new dependency) so
the tools work cross-platform; unit tests cover the framing and
reply-matching helpers, and everything was validated against two boards
(Haute42 COSMOX and COSMOX M-Ultra).

Depends on the firmware PR; opened alongside it for review, can sit
until it lands.

New hlp-* console tools talking to the add-on's vendor HID interface
(usage page 0xFF47) over hidapi: hlp-ping (handshake and round-trip),
hlp-caps (decode the board's self-reported LED capabilities), hlp-fill
(visual test), hlp-input-mode, hlp-reboot-webconfig and
hlp-reboot-bootsel. Multiple connected boards are selected between with
--board-id. Adds the hidapi dependency.

Signed-off-by: Jacob Simpson <28767380+djGLiTCH@users.noreply.github.com>
Reboot-style commands execute before their reply is sent, so the board
often drops off the bus before the acknowledgement can be read; the
reboot tools previously surfaced that as a raw read error even though
the reboot had succeeded. A vanished device or missing reply is now
treated as the reboot proceeding, while a rejection reply (wrong guard
magic) still raises, via a distinct HostLightingRejected error.

Found by flashing a board with hlp-reboot-bootsel; the fix is verified
against a live reboot cycle and covered by unit tests.

Signed-off-by: Jacob Simpson <28767380+djGLiTCH@users.noreply.github.com>
Page 1 byte [5] is a step index into the board's brightness steps, not a
0-255 level. Page 2's brightness maximum is a separate 0-255 ceiling, so
printing byte [5] as plain "brightness" beside it implies one is a
fraction of the other: "brightness 5" against "brightness maximum 200"
reads as nearly off.

It is neither. HLP does not report the step count, and that count varies
by firmware - mainline defaults to 5 and the web configurator can set 1
to 10, while the LED refactor fixes it at 10 - so a step number means
nothing without the board's total. On a refactor board, step 5 is half
brightness.

The firmware and the protocol reference both call it a step; only these
tools were vague. Wording only, no behaviour change.

Signed-off-by: Jacob Simpson <28767380+djGLiTCH@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant