Uh oh!
There was an error while loading. Please reload this page.
Conversation
The Inca enumerates under vendor id 0x37b0, not the shared CompX ODM id 0x373e that every earlier Lamzu, CRDRAKO, and Attack Shark product uses, so it was invisible to the driver. It answers the existing CompX framing unchanged, so this is a catalog and discovery change rather than a new protocol: only the product lookup needed splitting per vendor id. Confirmed on hardware (Windows 11, hidapi) in both connection modes: - 0x0009, the mouse on its cable - 0x0010, the 8K receiver Both answer on MI_02 (usage page 0xffff, usage 0x0000), report id 0, a 65-byte feature buffer, and both address the mouse as target 0x02, so neither needs a mouseTarget override. Every existing CompX decoder produces a correct value with no new cases: firmware 0.18, battery 100%, five DPI stages read unscaled as big-endian, lift-off 0x01 -> Medium, sleep 60 s. The two connections run different polling-rate families, which the capture shows directly: LAMZU_POLLING_RATES encodes 1000 Hz twice, 0x01 in the 125-1000 family and 0x10 in the 1000-8000 family, and the cable answered 0x01 where the 8K receiver answered 0x40. Wired is therefore RATES_1K and the 8K receiver RATES_8K. 0x000f, the 1K receiver this model can also ship with, is taken from Lamzu's own configurator device table and has not been exercised on hardware. That table also names 0x000a and 0x0002 as the mouse and dongle DFU bootloader identities; they never speak this protocol and are excluded on purpose, with a test to keep them out. The WebHID filter is narrowed to usage page 0xffff, which keeps the mouse, consumer, system and keyboard collections out of the picker on a platform that exposes a device's interfaces separately. A WebHID enumeration of both connections settles the one collection that narrowing cannot exclude: MI_01's 0xffff/0x0001 declares no feature reports at all, while only 0xffff/0x0000 declares report 0, so the driver's feature-report-0 check rejects it rather than offering a dead entry. On Chrome/Windows the point is moot anyway — all seven collections arrive on a single HIDDevice, so each connection is one picker entry however the filter is written. Writes are entirely uncaptured. The inherited setters are unproven on an Inca, so this should be treated as read-only support. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018C96pMdnhGcXhLQhHYkLWc
# Conflicts: # src/drivers/vendors.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
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.
Rebase/merge of #45 onto current main, resolving an additive conflict in vendors.ts (both this PR's Lamzu Inca filter and #49's Lingbao filter landed in the same spot). Closes#45.