feat(hid): recognise Lightspeed receiver 046d:c547 (G915, G502 X)

[bobaoapae]

Summary

Adds recognition for the Lightspeed receiver 046d:c547 — the receiver that ships with newer G-series devices such as the G915 keyboard and the G502 X LIGHTSPEED. Before this change the PID was not in any known-receiver list, so the receiver fell through detect() and any device paired to it was completely invisible (never appeared in list or the GUI), while a c539/c53f receiver next to it enumerated fine.

Same shape as #510 (c539) and #388 (c53f), per the direction in #512 that once the route shape landed, further Lightspeed PIDs reduce to rows in the coverage table: the receiver answers the same HID++ 1.0 registers (pairing count, connection state, pairing information) as Unifying, so it routes through the existing Unifying code path and is only differentiated by its user-facing display name.

Changes

• openlogi-hid / route.rs — add 0xc547 to LIGHTSPEED_PIDS; the doc comment no longer claims the list is nano-receivers-only. Added the PID to the display-name test alongside 0xc53f.
• openlogi-hidpp / receiver::unifying::VPID_PAIRS — add (0x046d, 0xc547) so detect() builds the (Unifying-protocol) receiver for it, with the hardware-verification note in the doc comment following the existing 0xc53f/G305 precedent.

No routing, pairing, or display-name logic changes — the existing speaks_unifying_protocol / receiver_display_name helpers cover the new PID.

Testing

Verified on Windows 11 with a real G915 on its Lightspeed receiver (paired device wpid 0x407c):

# before: receiver not recognised — G915 invisible in `list` and the GUI

# after
Lightspeed Receiver (809CA30E, vid=046d pid=c547)
  └─ slot 1 ● G915 KEYBOARD (keyboard, wpid=407c, battery=—)
          model_ids=[b354,407c,c33e] ext=00 serial=— unit_id=ed4dc152 transports=usb+equad+btle

The agent enumerates the keyboard, registers it in config.toml, and the GUI lists and selects it. (battery=— is expected: the G915 only exposes 0x1001 BatteryVoltage, which is name-only in the feature registry — unrelated to receiver routing.)

Local gate on this branch:

cargo fmt --all -- --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace

Notes

• 0xc547 is the second Lightspeed PID verified on real hardware for the [Tracking]: Lightspeed receiver support #512 coverage table (G915 here; [Tracking]: Lightspeed receiver support #512 records a G502 X LIGHTSPEED report).
• As with feat(hid): recognise Lightspeed nano receivers (G-series, e.g. G305) #388, I have deliberately not added the remaining unverified PIDs from the coverage table (c53a, c53d, c541, c545, c54d).

Refs #512

[greptile-apps]

Greptile Summary

Adds recognition and Unifying-protocol routing for the 046d:c547 Lightspeed receiver.

• Registers 0xc547 as a Lightspeed PID with the appropriate display name.
• Adds 046d:c547 to receiver detection.
• Extends Linux receiver-child filtering to all Lightspeed PIDs and adds a c547 regression test.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
crates/openlogi-hid/src/route.rs	Adds 0xc547 to the shared Lightspeed PID table and verifies its display name.
crates/openlogi-hid/src/transport.rs	Extends Linux receiver-child filtering to Lightspeed receivers, resolving the previously reported enumeration gap without excluding the receiver node itself.
crates/openlogi-hid/src/transport/tests.rs	Adds a representative c547 child sysfs path regression test.
crates/openlogi-hidpp/src/receiver/unifying.rs	Enables receiver detection for 046d:c547 through the existing Unifying-compatible protocol implementation.

_{Reviews (2): Last reviewed commit: "fix(hid): filter Lightspeed receiver chi..." | Re-trigger Greptile}

[greptile-apps]

Lightspeed child nodes remain unfiltered

On Linux, adding 0xc547 only to LIGHTSPEED_PIDS leaves receiver-child filtering unchanged because is_receiver_child_sysfs_path checks only BOLT_PIDS and UNIFYING_PIDS. Child HID nodes beneath this receiver are therefore treated as direct-device candidates, adding unnecessary probes and potentially creating failed or duplicate inventory entries.

Knowledge Base Used:

• openlogi-hid: device inventory, pairing, and HID++ feature control
• openlogi-hidpp: HID++ protocol implementation