fix(hidpp): tolerate unrecognised BacklightStatus codes from getBacklightInfo - #687
Open
charliecai01 wants to merge 1 commit into
Open
fix(hidpp): tolerate unrecognised BacklightStatus codes from getBacklightInfo#687charliecai01 wants to merge 1 commit into
charliecai01 wants to merge 1 commit into
Conversation
…ightInfo An Alto Keys K98M on 0x1982 (Backlight2) v4 answers getBacklightInfo with status byte 6, which none of the six named BacklightStatus variants cover. The strict TryFromPrimitive decode failed on that byte and errored the entire backlight read — status, level, and effect all lost to one unmodelled code. The consumer at hid/src/write/backlight.rs already has a catch-all mapping any "unmodelled future variant" back to AlsAutomatic, per its own doc comment — that branch was unreachable because the decoder failed first. Add BacklightStatus::Unknown(u8) so an unfamiliar status code is preserved instead of aborting the read, and let the existing fallback do what it was written to do. Verified against a physical Alto Keys K98M over a Logi Bolt receiver: `openlogi backlight status` previously errored with "HID++ unsupported response during ReadBacklight for feature 0x1982"; now reads `enabled=true mode=none status=on (following ambient light) level=2/8`.
Greptile SummaryThis PR makes HID++ backlight-status decoding forward-compatible so unknown firmware status bytes no longer fail the entire backlight read.
Confidence Score: 5/5The PR appears safe to merge because unknown status values are preserved during protocol decoding and handled by the existing application-level fallback. The changed query and event decoders accept all status bytes, known values retain their prior mappings, unknown values round-trip losslessly, and the sole current application consumer already handles unmodeled variants.
|
| Filename | Overview |
|---|---|
| crates/openlogi-hidpp/src/feature/backlight.rs | Adds lossless handling of unrecognized backlight-status bytes across both response parsers, with focused round-trip coverage and no actionable defect found. |
Reviews (1): Last reviewed commit: "fix(hidpp): tolerate unrecognised Backli..." | Re-trigger Greptile
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
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.
The keyboard backlight can't be read at all on an Alto Keys K98M —
openlogi backlight status(and the equivalent GUI panel) fails outright.Root cause
The K98M runs
Backlight/0x1982at version 4. ItsgetBacklightInforesponse reports status byte6, which none of the six namedBacklightStatusvariants (0–5) cover. The strictTryFromPrimitivedecode fails on that byte and the whole read errors out — status, level, and effect all lost over one unrecognised code:The interesting part:
hid/src/write/backlight.rs::status_from_firmwarealready has a catch-all mapping any "unmodelled future variant" back toAlsAutomatic, with a doc comment saying exactly that's the intent. That fallback was dead code — unreachable because the decoder aborted before it could ever run.Fix
Add
BacklightStatus::Unknown(u8)and switch the decode fromtry_from(fails closed) to a totalFrom<u8>conversion (falls back open), so an unrecognised status code is preserved instead of failing the read. This lets the existingstatus_from_firmwarefallback do the job it was already written for. No public spec documents what6means on this firmware, so I didn't invent a name for it — it's just carried through asUnknown(6).Testing
HID++ unsupported response during ReadBacklight for feature 0x1982. After:keeps_unmodelled_status_codescovering the exact byte pattern the K98M returns.cargo test -p openlogi-hidpp— 202 passed, 0 failed.cargo fmt --checkandcargo clippy --release -p openlogi-hidpp— clean.