Skip to content

supported devices: add the VXE R1 on both transports - #156

Open
SakethKanchi wants to merge 1 commit into
OpenMouse-Project:control-panelfrom
SakethKanchi:feat/vxe-r1-supported
Open

supported devices: add the VXE R1 on both transports#156
SakethKanchi wants to merge 1 commit into
OpenMouse-Project:control-panelfrom
SakethKanchi:feat/vxe-r1-supported

Conversation

@SakethKanchi

Copy link
Copy Markdown

Adds the VXE R1 to the supported-devices table on both of its transports.

Depends on OpenMouse-Project/mouse-protocol#44, which makes the ATK driver
identify VXE mice by CID/MID and claim VXE's wired transport. Please merge that
first — until it lands (and openmouse's git dependency picks it up), the
supported claim here is only true against a local build.

Changes

  • supported-mice.ts: one row, pids: [0x1085, 0xf58f] — the 2.4 GHz receiver and
    wired. Both are shared product ids, so the note points at the CID/MID
    identity (2,12, PAW3395) rather than implying the ids identify the model.
  • supported-mice.test.ts:
    • VXE registered as a driver-reported brand, alongside the existing CRDRAKO
      entry — the ATK driver reports it via deviceBrand().
    • both product ids pinned in PID_UNIVERSE. The ATK discovery filter matches on
      vendor + usage page, so the protocol pins no ATK product ids of its own;
      0xf58f is pinned by ATK_COMPX_PRODUCT_IDS because it sits under the shared
      0x3554.

No driver or controller wiring was needed: AtkHidClient is already imported in
src/device/controller.ts and grouped in DM_CLASSES/DEDICATED.

Verification

npm run check passes (112 tests) with mouse-protocol#44 installed locally per
CONTRIBUTING's overlay recipe.

Verified in Chrome over WebHID on a real VXE R1 (firmware Mouse 3.13): the device
connects through the picker without crashing, names itself VXE R1, shows brand
VXE, 1,000 Hz, lift-off Low, Motion Sync on, ripple off, and angle snapping as
N/A (its angle register is unprogrammed). DPI tracked the mouse's own DPI-button
stage correctly — 1,200 DPI on stage 1, 1,600 on stage 2.

Battery also now shows a real charge state rather than "Unknown" — Charging on
the cable, Discharging on the receiver.

Before the protocol fix the same device showed ATK Wireless mouse -1k dongle at
320 DPI.

Note for a maintainer

ui/device-images.ts has no R1 asset and matches artwork by display-name regex, so
VXE R1 falls back to unknown-device.png. I deliberately did not map it to
another model's render.

The ATK driver now identifies VXE mice by CID/MID and claims VXE's wired
transport, so the R1 is supported over its 2.4 GHz receiver (0x1085) and
wired (0xf58f). Both are shared product ids, hence the note pointing at
the CID/MID identity rather than the ids.

Register VXE as a driver-reported brand alongside CRDRAKO, and pin both
product ids in the PID universe: the ATK filter matches on vendor plus
usage page, so the protocol pins no ATK product ids of its own.
@logm1lo

logm1lo commented Sep 5, 2026

Copy link
Copy Markdown

Continued the R1 work in #163, depending on protocol PR OpenMouse-Project/mouse-protocol#53. #163 retains your original app commit in its history, narrows the claim to the physically tested wired R1 SE+, and adds Chromium WebHID read/write verification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants