Expose split lighting frame and replica observability - #9
Merged
colonelpanic8 merged 4 commits intoAug 7, 2026
Conversation
The engine could report what it holds but never what the LEDs show. On a split renderer replica those are different questions: the replica renders from a snapshot that can go stale, and nothing observable distinguished a stale replica from a correct one. Record each render's revision and lighting context, promote it when the output acknowledges the write, and page the committed frame back through `ReadFrame`. The committed frame is post-`OutputTransform`, so what comes back is what the driver was handed rather than the pre-brightness composition.
Two new lighting endpoints for diagnosing a split renderer replica from the host: `GetLightingFrame` pages back what one node last presented, and `GetLightingReplicaStatus` returns both sides of the replication handshake in one read. `LightingFeatureFlags` is out of bits, so these are discovered by probing — firmware without them answers `UnknownCmd`, which is the documented downstream path anyway. Existing layouts and the upstream protocol version are untouched. A remote frame page has to be reassembled from split application packets, whose queues are shallow and lossy, so the page holds 24 cells rather than the ~80 the payload budget would allow. Availability is encoded explicitly: `Option` for never-observed values, and two appended `LightingError` variants separating "no such node" from "that node could not answer".
Wires GetLightingFrame and GetLightingReplicaStatus through the host service: the local half answers from its own engine, the peripheral through the board-provided remote-frame and replication-status ports, and the loopback integration tests drive both endpoints end to end. Native rmk-types and rynk_lighting suites pass; the cross-feature matrix and no_std target checks have not run yet.
colonelpanic8
force-pushed
the
work/lighting-observability
branch
from
August 7, 2026 06:00
57c7019 to
da04121
Compare
Owner
Author
|
Verification update: this topic is now rebased onto upstream |
colonelpanic8
force-pushed
the
glove80-rmk/lighting-v2
branch
from
August 7, 2026 19:58
dfdafb1 to
f5202f3
Compare
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.
Adds the generic RMK surface needed to diagnose split-lighting replication without blocking the host path.
Validated with:
cargo nextest run -p rmk --features rynk,storage,lighting(629 passed during candidate verification)cargo test -p rmk-types --features host(95 passed)cargo check --manifest-path rynk/Cargo.toml -p rynk --lib