feat(blocks): add LUMI key lighting to the blocksd bridge - #263
Merged
Conversation
LUMI advertises key colors rather than a Lightpad grid. Select the lighting surface from advertised capabilities and send exact key frames with validated acknowledgements while preserving legacy grid transport. Cover mixed transports, malformed replies, retry and reconnect behavior. Include a native rainbow example for isolated bridge acceptance checks.
Describe the daemon capability required for LUMI and the existing Lightpad binary path. Replace false shared-grid claims and distinguish historical design sketches from the supported implementation contract. Document the native effect probe and keep physical compositor and musical input acceptance separate from queued frame acknowledgements.
|
Warning Review limit reached
On-demand reviews are free for the next 13 days. After that, they cost $0.25 per reviewed file. Or wait 12 minutes for your next included review. View limit detailsLimit details: You’ve used the included review currently available. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (12)
Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
LUMI Keys now appears as a 24-color strip in Hypercolor's blocksd bridge. Lightpad and Lightpad M retain their 225-pixel matrices and binary transport. Discovery rejects unsupported models and inconsistent dimensions instead of publishing unusable surfaces.
Keyboard frames use blocksd's JSON
key_frameAPI with exactly 72 RGB888 bytes. Replies must match the message type and full 64-bit device UID and carry a boolean acceptance result. A rejected frame remains retryable; malformed replies trigger the existing disconnect path. Older Lightpad discovery responses remain compatible whenkey_countis absent.Why
The bridge previously treated every ROLI device as a grid and sent Lightpad binary frames. LUMI advertises zero grid dimensions, so Hypercolor exposed zero LEDs and had no keyboard transport. The Python daemon already owns MIDI and the device renderer; this change gives Hypercolor the corresponding discovery and output path.
LUMI requires the daemon capability introduced in blocksd #7. The hardware guide documents setup and the historical backend spec now distinguishes current support from earlier architecture sketches.
Verification
just verifypasses locally (Rust fmt + lint + test)just denypasses (required for dependency or license changes)just ui-testandjust ui-buildpass (required forcrates/hypercolor-ui/)just sdk-lint,just sdk-check, andjust sdk-buildpass (required forsdk/)just python-verifypasses (required forpython/)just compat-checkpasses (required fordata/drivers/vendors/*.toml)just docs-buildpasses (required for docs or README changes)cd docs && zola checkpasses (required for docs link/content changes)scripts/orpackaging/)just e2e-buildpasses with the normal Servo stack (required for daemon/UI/effect integration changes)just e2e-build-cpupasses when validating the CPU smoke fallbackjust e2epasses against the Servo stack (required for end-to-end behavior changes; starts daemon/browser)The six bridge integration tests pass, covering mixed JSON/binary writes, full-width UIDs, invalid geometry, rejected frames, malformed acknowledgements, and reconnects. Independent review also executed the native Rainbow example against an isolated Unix daemon and verified changing 24-key and 225-pixel frames.
Local validation passes workspace
just check, Clippy, formatting, 6,479 workspace tests (27 ignored), allocation contracts, documentation build, and documentation link checks. The aggregatejust verifyencountered an intermittent unchanged build-wrapper fixture failure; its isolated diagnostic rerun passed, and the remaining component gates were run separately. Workspace checks reused the existing frontend distribution from identical UI source because the fresh worktree lacked generated frontend assets.Linux and Windows checks, UI, and both normal Servo and CPU smoke e2e paths pass in CI. Apple Silicon checks also pass. Intel macOS exceeded its two-hour job limit during deployment-fixture compilation after workspace checks, Clippy, interop/capture/input/ownership fixtures, and status API fixtures passed; the remaining deployment checks did not run. Unchecked local recipe boxes for those e2e paths are covered by the CI equivalents; gates for unchanged surfaces are not applicable.
The live native example accepted 376 frames per device over 15 seconds. Lightpad acknowledged 113 complete repaints, about 7.53 repaints/sec between its first and last acknowledgement. Hardware testing exposed daemon-side snapshot starvation, single-buffer tearing, and a 200 ms receive-loop delay; their fixes are included in blocksd #7. The hardware owner confirmed whole-pad animation after the snapshot fix. The hardware owner subsequently confirmed the full compositor animation looks correct.
Notes for reviewers
The LUMI strip follows key index, without modeling black and white key heights. API acceptance confirms queuing; device presentation acknowledgements establish logical repaint completion, not physical LED scan timing or musical MIDI/MPE behavior.
A second hardware run exercised the real CPU SparkleFlinger compositor through the public daemon library in an isolated ROLI-only harness. A custom scene zone retained both surfaces and mapped them onto one canvas. Device output delivered about 25 frames/sec to blocksd without errors; the Lightpad returned 114 complete repaint acknowledgements in 15 seconds (7.59 logical repaints/sec). The existing live daemon and its case scene were unchanged. The hardware owner confirmed the full compositor animation looks correct. GPU composition and HTML effects were not exercised on the ROLI outputs.