Repository navigation
hotfix(razer): retry corrupt replies after an 8K polling switch - #48
Merged
Merged
Conversation
The receiver returns garbage while it reconfigures the wireless link after switching to 8,000 Hz, so the DPI and charging reads failed with bad checksums and the lift-off read silently hid the panel. exchange now re-sends a request whose reply came back corrupt, and setPollingRate pauses 150 ms for the link to settle before reading back.
Contributor
Author
|
was verified working on hardware via discord user pochiko_ [531696159056461835} |
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.
Summary
Hotfix for the Razer Viper V3 Pro (firmware 1.12): setting the polling rate to 8,000 Hz on the HyperSpeed receiver briefly reconfigures the wireless link, and feature-report exchanges sent into that window come back with a bad checksum.
Problem
0x04/0x85) and charging read (0x07/0x84) threwClass 0x04 command 0x85 returned a reply with a bad checksum.(and the equivalent for charging).readLiftOffdegrades tonullon a failed exchange.Fix
exchangenow re-sends a request whose reply came back corrupt (bad checksum / wrong length) instead of treating it as fatal, retrying within the existing response budget. Busy (0x01) replies still keep reading without a re-send.setPollingRatepauses 150 ms after a wireless rate write so the read-back happens after the link settles (the Viper V4 Pro driver documents the same pause).Testing
hid.test.tscases: a corrupt reply is retried instead of surfacing a checksum error, and retrying does not break the command/response pairing of the multi-step lift-off write.npm test(200 tests) andnpm run buildpass.