Skip to content

fix(razer): upload full Diamondback LED frames on every edit - #236

Open
DEERSTUDIO101 wants to merge 1 commit into
OpenMouse-Project:mainfrom
DEERSTUDIO101:fix/diamondback-full-frame
Open

DEERSTUDIO101 wants to merge 1 commit into
OpenMouse-Project:mainfrom
DEERSTUDIO101:fix/diamondback-full-frame

Conversation

@DEERSTUDIO101

@DEERSTUDIO101 DEERSTUDIO101 commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

Ticket T 0124 reports that Diamondback Chroma whole-mouse effects work, but individual LED control only changes the first LED. Upload the complete 21-cell row and activate custom mode after every edit, matching OpenRGB's Diamondback update sequence. Preserve previously acknowledged colors and initialize unknown cells to black because custom colors cannot be read back.

The linear-frame codec now permits RGB data across the full 80-byte argument area while retaining the firmware's fixed 0x32 header. This removes the incorrect 16-cell limit and allows all 21 Diamondback LEDs in one report. Cache updates remain conditional on successful upload and activation.

References:

Validation:

  • npm run build passed.
  • Custom-frame and Razer HID tests: 61 passed.
  • Razer device catalog tests: 30 passed.
  • git diff --check passed.

Physical confirmation is still pending. The reporter should test LED 0, LED 1 and LED 20, preserving previously selected colors, disabling a cell, and switching between whole-mouse effects and custom mode. Mamba Elite lighting is outside this change.

Summary by CodeRabbit

  • Bug Fixes
    • Improved Diamondback per-LED lighting updates by sending the complete 21-cell row and activating custom mode with each edit. Cells without a known color are set to black, while previously acknowledged colors are preserved.
    • Lighting status continues to reflect cached cell colors and modes after updates. Failed uploads or activation do not update the cache.
  • Tests
    • Updated lighting checks to cover full-row updates, concurrent edits, and black defaults for unknown cells.

@github-actions github-actions Bot added type: bug PR title category: bug area: protocol Protocol codecs and shared types area: drivers Device drivers and transport integration area: tests Protocol and driver tests area: documentation Documentation labels Oct 16, 2026
@coderabbitai

coderabbitai Bot commented Oct 16, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration
  • Configuration used: Repository: OpenMouse-Project/mouse-protocol/.coderabbit.yaml
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 8171f878-1dc2-4fd1-b6b3-b11f3dacdaee
📥 Commits

Reviewing files that changed from the base of the PR and between 4cadd7d and d9ef100.

📒 Files selected for processing: 5
  • docs/diamondback-custom-lighting.md
  • src/drivers/razer/hid.test.ts
  • src/drivers/razer/hid.ts
  • src/razer/codec.ts
  • src/razer/custom-frame.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

📝 Walkthrough

Per-LED Diamondback edits now upload the full 21-cell row and activate custom mode on each edit. The custom-frame command accepts up to 26 colors. The driver updates its LED cache after upload and activation succeed.

Changes: Diamondback lighting

Layer / File(s) Summary
Custom-frame capacity
src/razer/codec.ts, src/razer/custom-frame.test.ts
The command now accepts up to 26 colors. Tests cover 21-color and maximum-length frames, including packet bounds and checksums.
Full-row per-LED updates
src/drivers/razer/hid.ts, src/drivers/razer/hid.test.ts, docs/diamondback-custom-lighting.md
Each per-LED edit uploads a complete row, using cached Static colors and black for unknown cells, then activates custom mode. The cache updates only after both commands succeed. Tests and documentation reflect the row contents and command sequence.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Suggested reviewers: snekxs

Merge Risk: ⚪ Minimal · up to d9ef1

Diamondback per-LED edits now upload the full 21-cell row and activate custom mode. No concrete merge-blocking issue was found; hardware confirmation is still pending.

Security architecture risk: 🔵 Low · up to d9ef1

The change remains within existing mouse-lighting access and does not establish a new privilege or access-control bypass. Each edit now replaces the full lighting frame; physical behavior and recovery after partial failure remain unconfirmed.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

  • inferred — The changed setter's effective scope is the complete 21-cell lighting row on the client's existing HID device, rather than only the edited cell. The inspected change does not add device acquisition or grant access to another device; the codec constructs a command without owning a device handle.

Trust Boundaries and Controls

  • observed — Caller-supplied lighting values pass LED-index, zone, mode, and color validation before transmission. The resulting command uses the existing queued request path and the client's existing sendFeatureReport operation; the capacity increase does not introduce a separate transmission path.

Resilience and Maintainability Implications

  • inferred — The software cache commit is failure-contained, but upload and activation are separate device commands, not a physical transaction. If upload succeeds before activation fails or execution is interrupted, source evidence cannot establish the displayed state or rollback. Subsequent edits resend a complete row; neither write-only readback nor cross-client synchronization is promised.
Pre-merge checks: Passed 5
Check name Status Explanation
Description Check Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check Passed The title clearly and concisely describes the main change: uploading complete Diamondback LED frames for every edit.
Docstring Coverage Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 4 files. (1 skipped: 1 …
Linked Issues check Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check Passed Check skipped because no linked issues were found for this pull request.
Full details: Docstring Coverage

Explanation

Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 4 files. (1 skipped: 1 unsupported.)

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: documentation Documentation area: drivers Device drivers and transport integration area: protocol Protocol codecs and shared types area: tests Protocol and driver tests type: bug PR title category: bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant