feat(razer): extended-matrix lighting for the Basilisk V3 - #156
Merged
snekxs merged 3 commits intoOct 3, 2026
Merged
Conversation
Firmware "Mouse 1.0" over the cable, through OpenMouse Bridge on Windows, with RazerHidClient unmodified: - Identity, firmware, DPI (1800) and polling (500 Hz) read back on the existing 0xff transaction id. - 800 DPI and 1000 Hz each wrote, read back and were restored. - Polling was read back but not measured (the sampler saw dropouts), and the DPI stage read gave nothing usable, so no stage editor is offered. The app's hardware test export is in captures/razer-diamondback-chroma/. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
OpenRazer drives the Diamondback Chroma's LEDs through the older Chroma command family (class 0x03), not the extended matrix the Cobra and Viper Mini use. Adds that family to the generic RazerHidClient behind a new per-product standardMatrixLighting flag, set only on 0x004c: - codec: razerSetStandardEffectCommand (off, spectrum, wave, static, reactive, breathing random/single/dual on 0x03/0x0a) and the backlight brightness pair (0x03/0x03, 0x03/0x83, backlight led 0x05, 0-255 level as whole percent), byte for byte from razerchromacommon.c - driver: readStatus reports one "Mouse" zone with the brightness read from the mouse; setLighting writes the effect, then the brightness only when it changed, confirmed by read-back. The effect has no read, so it is cached and marked write-only, as on the Cobra and Viper Mini. Every command uses the product's 0xff transaction id, breathing included, although OpenRazer lists this model's breathing on 0x3f: that entry sits in the block where the Cobra's breathing turned out to answer on its usual id. Untested on hardware; the checklist is in docs/razer-testing.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A Basilisk V3 user reported the mouse connecting with no lighting card. The generic RazerHidClient had no lighting for it: OpenRazer drives this model (and the 35K) through the extended-matrix family on transaction id 0x1f, per led, not the standard family the Diamondback Chroma uses. Adds that behind a per-product extendedMatrixLighting flag on 0x0099 and 0x00cb: - codec: razerSetExtendedEffectCommand takes an optional led (default stays the logo, so the Cobra and Viper Mini are unchanged) and gains the wave effect (0x04, direction 0x01, speed 0x28, size 6); new per-led brightness pair 0x0f/0x04 and 0x0f/0x84; RAZER_LED names ZERO_LED, the scroll wheel and the logo. Byte for byte from razerchromacommon.c. - driver: readStatus reports three zones (Mouse, Scroll wheel, Logo) with each led's brightness read from the mouse; setLighting dispatches to the extended family, writes the effect to that zone's led, then the brightness only when it changed, confirmed by read-back. Effects have no read, so they are cached and marked write-only. Off, Spectrum, Wave and Static are offered; OpenRazer exposes no reactive or breathing here. Untested on hardware; the checklist is in docs/razer-testing.md. The app needs only the protocol bump: it already renders lightingZones. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
ydw1904
marked this pull request as ready for review
October 2, 2026 18:46
|
🎉 This PR is included in version 0.23.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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
2 participants
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.
Summary
A Basilisk V3 user reported the mouse connecting with no lighting card. OpenRazer drives the Basilisk V3 (0x0099) and V3 35K (0x00cb) through the extended-matrix lighting family on transaction id
0x1f, addressed per led, so this adds that family to the genericRazerHidClientbehind a newextendedMatrixLightingproduct flag.Stacked on #151 (Diamondback standard-matrix lighting), which holds the shared
setLighting/ brightness plumbing. Until #151 merges this diff shows its commits too; only the top commit is this PR.razerSetExtendedEffectCommandtakes an optionalled(default stays the logo, so the Cobra and Viper Mini are byte-identical) and gainswave(effect0x04, direction0x01, speed0x28, size 6). New per-led brightness pair0x0f/0x04+0x0f/0x84.RAZER_LEDnamesZERO_LED, scroll wheel and logo. All fromrazerchromacommon.c.readStatusreports three zones (Mouse = every LED incl. underglow, Scroll wheel, Logo) with each led's brightness read from the mouse.setLightingwrites the effect to that zone's led on0x1f, then brightness only when it changed, confirmed by read-back. Effects have no read so they are cached andwriteOnly.0x00and is the first thing to drop if it fails.0x0099and0x00cbonly.docs/razer-testing.mdgets a Basilisk V3 section with the test checklist.Not verified on hardware
Nobody on the project owns the mouse. The reporter can test it: the app needs only the protocol bump, since it already renders
lightingZones.Test plan
tsc --noEmitcleandocs/razer-testing.md