feat(wlmouse): DPI stage table, high-speed, turbo, angle tune, button combinations, and the mouse behind a receiver

[ydw1904]

Two commits that together bring the WLmouse driver up to what the vendor's own
configurator exposes: the full DPI stage table, four sensor settings the driver
could not reach, and the name of the mouse sitting behind a shared receiver.

1. The DPI stage table (873597a)

These mice hold six onboard stages and send the whole table in one packet, and
the driver has always decoded it — but only the active stage reached the app, so
OpenMouse could edit one DPI value where the vendor software edits six. The
control app already ships a generic stage editor for this exact shape (Keychron
M6 and Teevolution use it), so the driver now reports dpiStages,
activeDpiStage and the dpiStageEditor hint, plus the three setters that
editor calls.

setDpiStageCount and setDpiStageValue reuse the write setDpi was already
making: count and stages travel together in one packet, so a single-value edit
is a full table write either way. That write and its read moved into
writeStages/readStages, which setDpi now uses too.

Editing one stage keeps a Y that already differs from X — the shared editor
shows a single value per stage and must not quietly flatten a separate-axis
setup.

One inferred byte. setActiveDpiStage writes profile-page command 0x02,
which is not in any capture. It is the 0x82 read with the high bit cleared,
which is how every other command in this driver pairs up (0x80/0x00,
0x81/0x01, 0x84/0x04, 0x88/0x08, 0x89/0x09, 0x8a/0x0a). The
write is verified by reading the active stage back, and the mouse answers an
unknown command with unsupported, so a wrong byte surfaces as a plain error
rather than a silent no-op. A second pair of hands on hardware would be welcome
here.

2. Sensor settings and the mouse behind the receiver (89c8f97)

Read out of the vendor's web tool, which speaks the same page-command framing —
nothing guessed:

setting	page	read / write
high-speed mode	0x01	0x8b / 0x0b
turbo mode	0x01	0x93 / 0x13
angle tune (signed byte)	0x01	0x94 / 0x14
button combinations	0x03	0x81 / 0x01
paired product id	0x00, target 0x01	0x8b, arg 0x02

The four settings are optional per model: a mouse without one answers
unsupported rather than failing the exchange, so the reads catch into null and
the status reports "no such control" instead of breaking the connection. Turbo
needs high-speed mode on before the firmware will hold it, which the read-back
reports rather than silently dropping.

The paired-product read matters most for the shared 1K receiver, which
enumerates under one product id whatever it is paired with. Without it every
mouse on that dongle reports as "WLmouse 1K receiver"; with it the driver names
the model and the app can pick artwork for it. The doubled "WLmouse WLmouse"
prefix on the shared-receiver catalogue entries goes too.

Testing

• npm run check clean, npm test 832 passing.
• New tests in src/drivers/wlmouse/hid.test.ts cover the stage table round
  trip, the Y-preservation rule, the rejection paths, and the optional settings
  degrading to null, against a fake device that models a mutable stage table.
• Hardware: a Beast Max on the 1K receiver (36a7:a882), reporting the same six
  stages its vendor software shows (screenshot above).

App side: OpenMouse-Project/openmouse#162.

Per-stage DPI colours are the obvious follow-up — the command carrying them is
still unknown, so they are deliberately out of scope.

🤖 Generated with Claude Code