fix(hid): show the 0x0005 device name when the receiver stores no codename

[samsontands]

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 always None there, 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 via get_whole_device_name() and uses it as the codename fallback only when the receiver register returns none. When a stored codename exists, behavior is unchanged.

Touched: crates/openlogi-hid/src/inventory.rs — ProbedFeatures gains a name field, populated in probe_features; probe_unifying_slot and probe_bolt_slot use codename.or_else(|| probe.name.clone()).

Verification

Original MX Master (reports Wireless Mouse MX Master, wpid 4060) over a Unifying receiver, macOS 26:

Before:

slot 1 ● Unknown device (mouse, wpid=4060, ...)

After:

slot 1 ● Wireless Mouse MX Master (mouse, wpid=4060, ...)

cargo fmt -p openlogi-hid -- --check, cargo clippy -p openlogi-hid --all-targets -- -D warnings, and cargo test -p openlogi-hid (61 passed) are all clean.

Notes

• Adds a short Tested devices section to the README documenting the MX Master result.
• Generic HID++ control on this device (DPI 0x2201, SmartShift 0x2110, and Back/Forward/mode-shift remapping) already works — this PR is purely about the display name.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR fixes devices connected via a Unifying receiver (and some Bolt pairings) showing as "Unknown device" by reading the device's own marketing name from HID++ feature 0x0005 (DeviceTypeAndName) and using it as a codename fallback when the receiver's stored codename register returns None.

• Adds a name: Option<String> field to ProbedFeatures, populated via get_whole_device_name() only on the Bolt/Unifying probe paths (want_name = true); the direct path skips it (want_name = false) to avoid wasteful round-trips since info.name already serves as the codename there.
• Threads the want_name flag through probe_or_reuse → probe_features, and applies the fallback in both probe_unifying_slot and walk_bolt_slot via codename.or_else(|| probe.name.clone()).

Confidence Score: 5/5

Safe to merge — the change is purely additive, touching only the codename fallback on the Bolt/Unifying paths, with no risk of overriding an existing stored codename.

The want_name flag correctly gates the extra HID++ round-trip so the direct path is unaffected. The or_else fallback fires only when the receiver register returns None, leaving existing behaviour unchanged when a codename is present. The name field is cached as part of ProbedFeatures alongside the other immutable device data, so cache hits carry it forward correctly.

Files Needing Attention: No files require special attention.

Important Files Changed

Filename	Overview
crates/openlogi-hid/src/inventory/features.rs	Adds name: Option<String> to ProbedFeatures and reads it conditionally (want_name flag) from 0x0005 with proper trim/empty guard. Well-structured and correct.
crates/openlogi-hid/src/inventory/probe.rs	Both Bolt and Unifying slot probes now fall back to probe.name when the receiver-stored codename is None; the direct path correctly passes want_name = false. Logic is clean and correctly scoped.
crates/openlogi-hid/src/inventory/cache.rs	Adds want_name parameter to probe_or_reuse and threads it through to probe_features. Minimal, correct change; the cached ProbedFeatures now carries the name and it persists across cache hits normally.
README.md	Adds a Tested devices table documenting the MX Master on a Unifying receiver.

_{Reviews (3): Last reviewed commit: "perf(hid): skip the 0x0005 name read on ..." | Re-trigger Greptile}