fix(hid): show the 0x0005 device name when the receiver stores no codename#286
Open
samsontands wants to merge 2 commits into
Open
fix(hid): show the 0x0005 device name when the receiver stores no codename#286samsontands wants to merge 2 commits into
samsontands wants to merge 2 commits into
Conversation
…ename Unifying receivers (and some Bolt pairings) don't store a per-slot codename, so a fully-recognised device showed up as "Unknown device" in `openlogi list` and the GUI. The slot probe already reads HID++ 0x0005 for the device kind; this also reads its marketing name via `get_whole_device_name()` and uses it as the codename fallback when the receiver register has none. Behavior is unchanged whenever a stored codename exists. Verified on an original MX Master (reports "Wireless Mouse MX Master", wpid 4060) over a Unifying receiver on macOS 26: `openlogi list` now shows the model name instead of "Unknown device". Adds a Tested devices section to the README. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
`probe_features` is shared by the Bolt, Unifying, and direct paths. The direct (BT/USB) path already uses the HID node name as the codename, so the marketing-name read (`get_whole_device_name`, several HID++ round-trips for long names) was fetched and then discarded there on every cache-miss probe. Thread a `want_name` flag so only the Bolt/Unifying paths — which can lack a stored codename — pay for it. The direct path passes `false`. Addresses review feedback on AprilNEA#286. Co-Authored-By: Claude Opus 4.8 <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
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.
Problem
On a Unifying receiver, a fully-recognised device shows up as "Unknown device" in
openlogi list(and the GUI device list). The display name (codename) is read only from the receiver's stored codename register (read_codename), which a Unifying receiver doesn't populate per slot — so it is alwaysNonethere, and some Bolt pairings lack it too.Fix
The slot probe already creates the HID++
0x0005(DeviceTypeAndName) feature to read the device kind. This change also reads the device's marketing name viaget_whole_device_name()and uses it as thecodenamefallback only when the receiver register returns none. When a stored codename exists, behavior is unchanged.Touched:
crates/openlogi-hid/src/inventory.rs—ProbedFeaturesgains anamefield, populated inprobe_features;probe_unifying_slotandprobe_bolt_slotusecodename.or_else(|| probe.name.clone()).Verification
Original MX Master (reports
Wireless Mouse MX Master,wpid 4060) over a Unifying receiver, macOS 26:Before:
After:
cargo fmt -p openlogi-hid -- --check,cargo clippy -p openlogi-hid --all-targets -- -D warnings, andcargo test -p openlogi-hid(61 passed) are all clean.Notes
0x2201, SmartShift0x2110, and Back/Forward/mode-shift remapping) already works — this PR is purely about the display name.🤖 Generated with Claude Code