fix: gate device config panels on HID++ capabilities (closes #127)

[AprilNEA]

Problem

On master, a Bluetooth-direct / wired MX Anywhere 3S / MX Master 3 shows only a Lighting (color) tab — the Buttons and Pointer tabs vanish, so there's no way to remap back/forward or anything else (#127).

Root cause

Two pieces interact:

• inventory.rs::probe_direct (the receiver-less path: Bluetooth-direct, USB-C) hard-codes kind: DeviceKind::Unknown. There's no Bolt pairing register on this path to supply a real kind, and nothing else filled it in.
• app.rs::supports_lighting (added in feat: add wired G-series keyboard RGB control #29 for wired G-series keyboards) treats any Unknown + DeviceRoute::Direct device as a lighting-capable keyboard.

So a Bluetooth-direct mouse is indistinguishable from a wired keyboard: is_configurable_pointer(Unknown) is false (no Buttons/Pointer) while supports_lighting is true (Lighting only). A Bolt-connected unit reports Mouse(0x02) from the pairing register and is unaffected — which is why the same model works over the Bolt receiver but breaks over Bluetooth.

Fix

Read the device's marketing type from HID++ feature 0x0005 (DeviceTypeAndName) and use it for the kind:

• Folded into the existing probe_features session, so it's one extra short round-trip on an already-open device — no new Device::new / enumerate_features handshake.
• Direct path: uses the 0x0005 type directly → a Bluetooth-direct mouse is now Mouse, restoring the Buttons + Pointer tabs and dropping the spurious Lighting tab.
• Bolt path: keeps the authoritative pairing-register kind, falling back to 0x0005 only when that register reads Unknown — so currently-correct devices are untouched.

map_device_type maps the 0x0005 enum to our DeviceKind; resolve_device_kind encodes the precedence (primary wins unless Unknown, then probe) and is unit-tested.

Verification

• cargo test -p openlogi-hid — 3 new precedence tests pass.
• cargo clippy -p openlogi-hid --all-targets clean under -D warnings.
• Not yet verified on hardware — @AprilNEA will test on an Anywhere 3S / Master 3 over Bluetooth. The tab gating is deterministic given kind == Mouse; this just needs to confirm the device answers 0x0005 at index 0xff on the direct path.

Notes / out of scope

• Master3 has detected the device, but all configuration changes aren’t taking effect #98 (filed before feat: add wired G-series keyboard RGB control #29) describes a different mix — the DPI button isn't visible to the macOS CGEventTap (it's outside button range 0–4; see hook_runtime.rs), plus pointer drift and a scroll-direction request. If that user is on a post-feat: add wired G-series keyboard RGB control #29 build over Bluetooth this fix restores their tabs, but the DPI-button limitation is separate and not addressed here.
• A residual edge case — a Bolt register misreading kind as Keyboard(0x01) rather than Unknown — would not be covered, but there's no evidence of it.

Fixes #127

[greptile-apps]

Greptile Summary

This PR fixes #127 by replacing kind-based UI panel gating with capability-based gating — panels now show when the device's HID++ feature table announces the relevant feature, not when DeviceKind matches a mouse/keyboard pattern. It also reads 0x0005 (DeviceTypeAndName) to give Bluetooth-direct devices a real kind instead of hard-coded Unknown, and adds a stateful Enumerator that caches per-device probe results across polling ticks.

• Core fix (app.rs): tabs_for now uses Capabilities (derived from the device's own feature-ID table) instead of is_configurable_pointer / supports_lighting; the Buttons and Pointer tabs are independent, and the lighting tab requires an actual lighting feature rather than Unknown + Direct.
• Kind resolution (inventory.rs): probe_features reads 0x0005 in the same HID++ session and resolve_device_kind prefers that self-reported type over the Bolt pairing register, with the asset registry's curated kind taking precedence at the GUI layer via effective_kind.
• Probe cache (Enumerator): immutable data (model info, capabilities, marketing type) is memoized across enumerate ticks with a grace-period eviction; battery is refreshed every REFRESH_TICKS ticks. Probes now run concurrently across HID candidates via futures-concurrency.

Confidence Score: 5/5

The change is safe to merge; the capability-gating logic is deterministic and well-tested, the probe cache is correctly isolated per-device, and the removal of exposes_peripheral_feature is sound because enumerate_features already returns all feature IDs including ReprogControls and AdjustableDpi.

The fix is narrow and well-contained: the UI path now reads from a Capabilities struct derived entirely from the device's own HID++ feature table, so panel display is provably correct for any device that answers enumerate_features. Fallbacks (presumed_from_kind for offline devices, asset-registry kind overriding the Bolt register) are documented and tested. The concurrent probe dispatch and cache eviction logic have unit tests covering edge cases like grace-period resets and stale-tick boundaries. The only nit is the futures-concurrency version being pinned directly rather than through the workspace.

No files require special attention; the most complex file (inventory.rs) has thorough inline documentation and tests.

Important Files Changed

Filename	Overview
crates/openlogi-hid/src/inventory.rs	Major rewrite: adds stateful Enumerator with per-device probe cache, concurrent HID candidate probing via futures-concurrency, and derives Capabilities from the feature table returned by enumerate_features. Adds 0x0005 DeviceTypeAndName read for direct-path kind resolution. Logic is sound; cache eviction and staleness checks are well-tested.
crates/openlogi-core/src/device.rs	Adds Capabilities struct (buttons/pointer/lighting flags derived from HID++ feature IDs), from_registry_type on DeviceKind, and capabilities: Option on PairedDevice. Vocabulary mapping comment clearly explains why numeric values can't be shared between Bolt register and 0x0005. Well-tested.
crates/openlogi-gui/src/app.rs	Replaces kind-based tab gating (is_configurable_pointer + supports_lighting) with capability-based gating; Buttons and Pointer tabs are now correctly independent. Falls back to Capabilities::presumed_from_kind for offline/unprobed devices. Core fix for #127.
crates/openlogi-gui/src/state/devices.rs	Adds effective_kind() that prefers the human-curated asset registry kind over the runtime HID++ classification; propagates capabilities from probe into DeviceRecord. Tests cover the key conflict resolution cases.
crates/openlogi-gui/src/state.rs	Preserves last-known capabilities when a device goes offline, so a sleeping mouse keeps its button/pointer panels instead of regressing to the presumed-from-kind fallback.
crates/openlogi-gui/src/watchers/inventory.rs	Switches from a one-shot enumerate() call per tick to a persistent Enumerator, allowing probe-cache reuse across ticks.
crates/openlogi-hid/Cargo.toml	Adds futures-concurrency = "7" as a direct pin rather than routing it through the workspace, inconsistent with all other dependencies.
crates/openlogi-gui/src/asset/mod.rs	Adds kind: DeviceKind to ResolvedAsset by converting the registry's type string via from_registry_type, enabling effective_kind() to prefer the curated registry classification.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[HID++ device detected] --> B{Bolt receiver?}
    B -- Yes --> C[probe_bolt_slot\npairing register → bolt_kind]
    B -- No --> D[probe_direct\nregister = Unknown]

    C --> E[probe_or_reuse\ncached? stale?]
    D --> E

    E -- fresh probe --> F[probe_features\nDevice::new + enumerate_features]
    E -- cache hit --> G[reuse Cached probe]

    F --> H[Capabilities::from_feature_ids]
    F --> I[0x0005 → map_device_type → probed_kind]
    F --> J[Battery + ModelInfo]

    H --> K[ProbedFeatures]
    I --> K
    J --> K

    K -- capabilities.is_some --> L[Cache probe\nCacheOutcome::Fresh]
    K -- capabilities.is_none --> M[Don't cache\nfallback to prior or default]

    L --> N[resolve_device_kind\nprobed wins unless Unknown]
    G --> N

    N --> O[PairedDevice.kind + capabilities]
    O --> P[build_device_list\neffective_kind: asset > HID++]
    P --> Q[DeviceRecord.capabilities]

    Q -- Some --> R[tabs_for: use measured caps]
    Q -- None --> S[tabs_for: presumed_from_kind]

    R --> T{caps.buttons?}
    R --> U{caps.pointer?}
    R --> V{caps.lighting?}

    T -- Yes --> W[Buttons tab]
    U -- Yes --> X[Pointer tab]
    V -- Yes --> Y[Lighting tab]

Loading

_{Reviews (7): Last reviewed commit: "fix(hid): don't let a failed re-probe co..." | Re-trigger Greptile}

[AprilNEA]

Pushed a follow-up that strengthens the fix and addresses the review note.

Why the precedence flipped. #127's reporter is on a Logi Bolt receiver, not Bluetooth-direct. On the Bolt path a device only renders the lighting-only UI when it's classified as a Keyboard, which means the receiver's pairing register is misreporting the MX Anywhere 3S as a keyboard. The first revision only filled an Unknown register from 0x0005, so it would not have fixed that user.

The device's own HID++ 0x0005 (DeviceTypeAndName) report is authoritative, so resolve_device_kind now prefers it for any online device and falls back to the pairing-register kind only when the device is offline (no probe) or 0x0005 returns a type we don't model. This corrects a register that reports the wrong concrete kind — covering both the Bolt and the Bluetooth-direct cases in #127.

Re: the discarded-round-trip note. The 0x0005 read is unconditional again, but it's no longer discarded — it's now the primary kind source. It runs only for online devices that just answered the battery + device-info reads, so it's one cheap short round-trip with a real purpose.

The bolt_kind value the register reports is logged on the paired slot debug line, so a RUST_LOG=openlogi_hid=debug run on the affected device will confirm exactly what the receiver was reporting.

[AprilNEA]

Reframed: capability-driven gating (the root fix)

The earlier commits made the DeviceKind proxy more accurate (0x0005, asset cross-check, precedence). That treated the symptom. The disease was gating capability decisions on identity at all — whether to show a DPI panel has nothing to do with "is this a mouse", only with whether the device exposes 0x2201/0x2202.

This PR now pivots to the essential line:

• openlogi-core — Capabilities { buttons, pointer, lighting } derived from the device's HID++ feature-ID set (from_feature_ids); presumed_from_kind is the offline fallback.
• openlogi-hid — probe_features captures the feature-ID list that enumerate_features already returns (zero extra round-trips) and returns a ProbedFeatures struct. The Bluetooth-direct peripheral discriminator reuses those caps, so the redundant exposes_peripheral_feature probe (an extra Device::new + root lookups) is deleted.
• openlogi-gui — DeviceRecord carries Option<Capabilities>; the snapshot merge carries the last-known set forward so a sleeping device keeps its panels. tabs_for shows each panel iff its capability is set. is_configurable_pointer and the supports_lighting Unknown+Direct heuristic are deleted.

kind is now identity-only (icon/label) — a wrong kind is a cosmetic glitch, never a lost panel.

What this resolves from the review:

• The asset-vs-0x0005 precedence concern (review finding feat(gui): internationalize the UI (en / zh-CN / zh-HK) #1) is defanged — kind no longer gates function, so a registry typo only mislabels an icon.
• The future keyboard-support mirror bug is pre-empted: a keyboard's button config will gate on 0x1b04, not kind == Keyboard.

No #29 regression: a wired G-series keyboard exposes 0x8080 (PerKeyLighting) in its feature table — set_keyboard_color itself resolves 0x8080 to write — so caps.lighting is true for it and the Lighting tab stays.

Verified: cargo test (core/hid/gui) + cargo clippy -D warnings green; whole workspace builds. Still pending hardware confirmation on the affected Anywhere 3S / Master 3.