Skip to content

feat(keychron): claim the M6 with its own driver instead of Pulsar's - #128

Draft
ydw1904 wants to merge 1 commit into
OpenMouse-Project:devfrom
ydw1904:codex/keychron-m6-app
Draft

feat(keychron): claim the M6 with its own driver instead of Pulsar's#128
ydw1904 wants to merge 1 commit into
OpenMouse-Project:devfrom
ydw1904:codex/keychron-m6-app

Conversation

@ydw1904

@ydw1904 ydw1904 commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

Draft: blocked on OpenMouse-Project/mouse-protocol#33. This branch imports @openmouse/protocol/drivers/keychron/m6-hid, which only exists on that PR's branch. CI installs from the lockfile pin, so the type check fails until #33 merges and the pin moves. Ready to review as a change; not ready to be green.

Why

The M6 driver in mouse-protocol is enough for the registry to detect the mouse, but not for the app to drive it. The sidebar lists it as "Keychron · Available", and activating it fails with:

client.describeCollections is not a function

pulsarClient() is a negative check: any active client not listed in DEDICATED is assumed to be a Pulsar client and routed into showPulsarExplorer(), which calls describeCollections() — a method only the Pulsar drivers have. So a new driver class is broken by default until it is named in that list, and the error message points nowhere near the cause.

This is not specific to any one transport: the M6 fails the same way in Chrome over WebHID as it does through OpenMouse Bridge.

What changes

KeychronM6HidClient joins NEEDS_OPEN, next to the Nape Pro's KeychronHidClient. Its open() is what attaches the input-report listener its query/reply exchanges depend on, and NEEDS_OPEN feeds DEDICATED, so one entry covers both needs.

Verification

Wired Keychron M6 on macOS. Before: sidebar row stuck at "Keychron · Available", activation throwing. After: connects and reports 800 DPI, 500 Hz, and battery, and a DPI change (800 → 1600 → 800) flashes to the mouse and reads back.

Locally npm run build and npm test pass with the #33 driver installed.

Worth considering separately

pulsarClient() treating "unclaimed" as "Pulsar" means every future driver hits this same trap, with an error that names a Pulsar-only method. Inverting it — an explicit Pulsar list, with unclaimed clients reported as unsupported — would turn a confusing runtime failure into an obvious one. Out of scope here.

🤖 Generated with Claude Code

The M6 driver in @openmouse/protocol is enough for the registry to detect
the mouse, but not for the app to drive it: the sidebar lists it as
"Keychron · Available" and activating it fails with

    client.describeCollections is not a function

pulsarClient() is a negative check — any active client not listed in
DEDICATED is assumed to be a Pulsar client and routed into
showPulsarExplorer(), which calls describeCollections(), a method only the
Pulsar drivers have. A new driver class is therefore broken by default
until it is named here, and the error points nowhere near the cause.

KeychronM6HidClient joins NEEDS_OPEN, next to the Nape Pro's
KeychronHidClient: its open() is what attaches the input-report listener
its query/reply exchanges depend on, and NEEDS_OPEN feeds DEDICATED, so
one entry covers both.

Verified on a wired Keychron M6: the device connects and reports 800 DPI,
500 Hz, and battery, and a DPI change flashes to the mouse and reads back.

Needs the M6 driver from OpenMouse-Project/mouse-protocol#33.
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.

1 participant