fix(core): resolve connection label from the live route, not static transports

[4ni1ak]

Summary

• Fixes the GUI/diagnostics connection label showing the wrong transport for a multi-transport device on a Direct route.

Root cause

For a Direct route, the connection label (openlogi-desktop's diagnostics report and gallery-card glyph) was picked from the device's static DeviceTransports capability flags — the transports the firmware merely claims to support — checking Bluetooth/BTLE before USB. A device that supports both (e.g. G915 X LS: USB + eQuad + BTLE all true) therefore always showed "Bluetooth (direct)", even when it was actually plugged in over USB.

A Direct route already carries the vendor/product id of the HID node this session actually enumerated. For a multi-transport device, the firmware packs a distinct PID per transport into DeviceModelInfo::model_ids (ascending bit order: Bluetooth, BTLE, eQuad, USB), so that pid tells us exactly which transport is live right now — it just wasn't being consulted.

Changes

• crates/openlogi-core/src/device.rs: add DeviceModelInfo::transport_for_product_id, matching a product id against the packed model_ids slots, plus the ModelTransport enum it returns.
• crates/openlogi-desktop/src/services/diagnostics.rs: connection_for now resolves the Direct-route label via transport_for_product_id first, falling back to the old capability-flag guess only when the product id matches no known slot.
• crates/openlogi-desktop/src/app/home.rs: connection_icon_path (gallery-card glyph) gets the same fix, for the same reason.
• crates/openlogi-desktop/src/app/tests.rs, crates/openlogi-core/src/device.rs (tests module), crates/openlogi-desktop/src/services/diagnostics.rs (tests module): regression tests reproducing the exact G915 X LS report from [Bug]: G915 X Lightspeed listed as bluetooth connection when connected over USB #1218 (model_ids = [0xb38a, 0x40b5, 0xc356], transports usb+equad+btle) — same model, two different live routes (USB-direct and BTLE-direct), asserting the label/icon differs correctly between them, plus fallback-path coverage for an unrecognized product id and missing model info.

Testing

• cargo test -p openlogi-core — 273 passed
• cargo test -p openlogi-desktop — 210 passed
• cargo fmt --all -- --check — clean
• cargo clippy -p openlogi-core -p openlogi-desktop --all-targets -- -D warnings — clean
• Not runtime-tested on hardware: this machine has no G915 X LS (or any Logitech HID++ hardware). Verification is unit/integration only, reproducing the reporter's exact diagnostic data (model ids, transports, route). Real-hardware confirmation is left to the maintainer.

Fixes #1218

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; the live-route transport resolution matches the documented HID++ model-ID packing contract and no actionable regressions remain.

Summary

The PR corrects user-facing connection classification for directly attached multi-transport devices by resolving the enumerated route PID against the firmware-reported per-transport model IDs.

• Adds a shared core helper that maps packed model IDs to Bluetooth, BTLE, eQuad, or USB.
• Uses the resolved live transport for gallery icons and diagnostic connection labels.
• Preserves the existing capability-based fallback for absent or unrecognized model information.
• Adds focused regression coverage for USB and BTLE routes of the same multi-transport device.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    Route[Direct route PID] --> Lookup[Match packed model IDs]
    Model[Enabled transport flags] --> Lookup
    Lookup -->|USB or eQuad| Wired[Wired label / USB icon]
    Lookup -->|Bluetooth or BTLE| Bluetooth[Bluetooth label / icon]
    Lookup -->|No match| Fallback[Legacy capability-based fallback]

Loading

_{Reviews (2) · Last reviewed commit: "fix(core): resolve connection label from..."}