Uh oh!
There was an error while loading. Please reload this page.
Conversation
The Lingbao M5 Pro (PixArt PAW3395) enumerates under VID 0x3151 on the very same 0xFFFF/0x02 vendor interface FantechHidClient claims, so the registry handed it to that driver — which could not read a single value from it, and reported fabricated ones rather than failing. 0x3151 belongs to MicLink/mlzn, the ODM, not to Fantech. The mouse is configured by GearHub-V5 (qmk.top); its protocol was read out of that bundle and then verified byte for byte against real hardware. LingbaoHidClient implements the three things the Fantech driver lacks: - The Bit7 checksum, byte[7] = 255 - sum(bytes 0..6). Without it the device ACKs the write and answers 64 zero bytes, silently. - The 2.4G relay. A receiver does not forward a command just because one was written to it: select the target (0xF6 0x05), poll status until ready (0xF7), send, then notice-read (0xFC) before reading back. 0xF7 also carries link state and battery. - The mouse-class command set (GET_DPI 0xD4 / SET_DPI 0x54) and its seven-entry report-rate table, in which code 5 means 250 Hz. The Fantech driver carries the six-entry keyboard table, where code 5 means 125 Hz instead. Commands are serialised through a queue. The relay is stateful, so two exchanges in flight at once interleave and corrupt each other — readStatus() ran into this on its first concurrent read. Scoped to the M5 Pro's two product ids (0x402D receiver, 0x4026 wired) so it cannot shadow Fantech's own hardware, and FantechHidClient now leaves those two ids alone; the registry's one-driver-per-device test enforces it. Verified live on a Lingbao M5 Pro receiver: DPI stages 400/800/1600/3200/ 6400/26000 with stage 2 active, 8000 Hz, battery 44%, firmware v3.03, device id 2285. Bluetooth mode is not covered — over BLE the mouse moves to a different usage page and a separate read path. The same investigation showed FantechHidClient inventing data on any device that does not answer, so this also fixes: - readStatus() throws instead of returning 1600 DPI / 8000 Hz decoded from an all-zero reply, letting the caller try the next driver - setDpiForSlot() no longer zeroes every DPI slot it is not writing - 250 Hz is no longer advertised when it cannot be encoded, so the UI cannot render a button that throws on click - the hardcoded "Wired (USB)" and the placeholder firmware string are gone rather than mislabelling wireless units Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
# Conflicts: # src/drivers/mouse-types.ts # src/drivers/registry.ts
Uh oh!
There was an error while loading. Please reload this page.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Rebase/merge of #49 onto current main, resolving additive brand-union conflicts in mouse-types.ts/registry.ts against #50/#53/#54/#55. Closes#49.