feat(rapoo): drive the VT9 Pro through the Rapoo HID client - #422
Merged
Merged
Conversation
The mouse-protocol PR that adds the Rapoo codec and its WebHID client also adds RapooHidClient, and it was not on the list of clients the controller opens on connect. Without that entry the driver never gets to run against a device that is already picked, which is the whole point of the client: it answers on its own vendor collection, so nothing else notices it. The client reports the battery on its own when the transport has no receiveInputReport (WebHID alone cannot read the register channel), and when OpenMouse Bridge supplies it the same connect path unlocks DPI, polling rate and the sensor settings.
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.
What this changes
mouse-protocolgains a Rapoo codec and aRapooHidClientfor the Rapoo VT9 Pro(
0x24AE:0x1205receiver,0x24AE:0x4405cable). This adds that client toNEEDS_OPEN, the list of clients the controller opens on connect.The entry matters for this driver specifically: the mouse answers on its own
vendor collection (
FF00:0x000E), so nothing else would open that interface. Ifit stays closed,
readStatus()never runs and the device looks like any otherunknown mouse.
Behaviour
motion sync, debounce and the sleep timer:
receiveInputReportis what makesthe register channel readable, and on hardware the walk returned the full map
(4000 Hz, 800 DPI, 16 ms debounce, battery 100 %).
pushes on its own, so the device is still useful in the browser.
Review notes
protocol notes and the sanitized capture ship with the
mouse-protocolPR.0x2B, which drops thedevice off the bus until it is unplugged and replugged.
Companion PR
OpenMouse-Project/mouse-protocol#147 (the driver itself).
Depends on the protocol release
This PR needs the companion
mouse-protocolPR to be merged and published:until then the
@openmouse/protocolversion inpackage.jsonhas nodrivers/rapoo/hid, so the import cannot resolve. That dependency is bumped fromthe published release by
.github/workflows/update-protocol.yml, which is whythis PR does not touch
package.jsonitself.Keeping it a draft until that release exists.