Match AJAZZ AKP03 and other clones by USB ID - #1
Open
nanderss wants to merge 1 commit into
Open
Conversation
The AJAZZ AKP03 is listed as a supported clone, but it enumerates as 0300:3002 with the descriptor "HOTSPOTEKUSB HID DEMO" rather than the 5548:1001 that was hardcoded. It exposes the same 0xFFA0/0x01 vendor HID interface with 1024-byte reports and speaks the same CRT protocol, so it works unmodified once the matcher accepts its IDs. Replace the single vendorID/productID pair with a deviceIDs list and build one matching dictionary per entry. Also log the IDs being waited for: with no device attached the daemon otherwise sits silent forever, which is indistinguishable from a device that failed to connect. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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 free
to 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.
The README lists the AJAZZ AKP03 as a known clone that "should work out of the box", but it doesn't: it enumerates under different USB IDs than the hardcoded pair, so
IOHIDManagerSetDeviceMatchingnever fires and the daemon waits forever for a device that is plugged in and working.On my unit (macOS 26.5, Apple Silicon) it appears as:
Everything except the IDs matches what
Protocol.swiftexpects — same vendor usage page, same usage, same 1024-byte output reports — and it speaks the CRT protocol unmodified. Buttons, both knob types and knob clicks all decode correctly once the matcher accepts it.Replaces the single
vendorID/productIDpair with adeviceIDslist and builds one matching dictionary per entry.IOHIDManagerSetDeviceMatchingMultiplewas already being used, so this is just supplying more than one.Also logs the IDs being waited for at startup. With no match the daemon is completely silent, which is indistinguishable from a device that failed to enumerate — that ambiguity is most of what made this hard to diagnose.
Tested on an AJAZZ AKP03. I don't have a TreasLin N3 to confirm the original path still matches, but that entry is unchanged.