[Tracking]: Lightspeed receiver support

[Stanley5249]

OpenLogi uses the existing Unifying-compatible HID++ path for supported Lightspeed and Nano receivers. Support is added by receiver PID, so this issue tracks which PIDs are recognised and which devices have been tested.

Receiver coverage

PID	Family	Device	Status
c52b, c532	Unifying	Multiple devices	Supported
c537	Nano	G602	#684 open; hardware test needed
c548	Bolt	Multiple devices	Supported
c53f	Lightspeed	G305	Supported by #388
c539	Lightspeed	G903 LS	Supported by #510
c547	Lightspeed	G502 X LIGHTSPEED	Supported; tested in #459
c53a, c53d, c541, c545, c54d	Lightspeed	No confirmed device report	Not tested

PR status

PR	State	Main work
#351	Open	Multiple Lightspeed PIDs and RGB effects
#369	Open	G305 support with extra gaming-mouse features
#388	Merged	c53f receiver recognition
#459	Open	Onboard profiles, tested with a G502 X
#510	Merged	c539 receiver recognition
#684	Open	G602 Nano receiver c537 recognition

Current direction

The merged receiver work routes Lightspeed and Nano receivers through the existing Unifying-compatible path. A separate route type is not needed unless real hardware shows different protocol behaviour.

Receiver names can still be shown as Lightspeed or Nano in the UI without changing the route.

Still needed

• Test feat(hid): support G602 nano receiver #684 with a real G602. Logitech lists its Nano receiver as 046d:c537.
• Confirm devices and hardware behaviour for c53a, c53d, c541, c545, and c54d.
• Check [Device]: Cannot detect Logi Pro Wireless Gen 1 Onboard Mode. #462, which was reported as Bolt even though the mouse uses Lightspeed.
• Add a Lightspeed option to device_support.yml and update its outdated receiver wording.

Related but separate: #392 is a wired device, #461 tracks device artwork, and gaming-mouse features are tracked separately.

[linear-code]

OLG-184

[yuzi-co]

Second verification for c539, and one label bug it surfaces.

Coverage: the table lists c539 as verified on a G903 LS. Adding a second device on the same receiver PID — G502 LIGHTSPEED (the original, not the X), paired device wpid 407f, on Windows 11 26200.8973 x86_64. Enumerates and reads correctly on current master:

> openlogi list
Unifying Receiver (82839805, vid=046d pid=c539)
  └─ slot 1 ● G502 (mouse, wpid=407f, battery=43% low (discharging))
          model_ids=[407f,c08d,0000] ext=00 serial=— unit_id=6be9d300 transports=usb+equad

DPI (0x2201), RGB (0x8070), battery (0x1001), and hi-res wheel (0x2121) all respond. So the route-shape decision this issue is about appears settled in practice for c539: the merged UNIFYING_PIDS fold from #510 works.

But the display name is wrong. Note the first line: Unifying Receiver. receiver_display_name in crates/openlogi-core/src/hid/route.rs only returns "Lightspeed Receiver" for LIGHTSPEED_PIDS (c53f, c547); c539 sits in UNIFYING_PIDS, so it prints as Unifying — while this issue's own coverage table, and the doc comment directly above the constant, both class c539 as Lightspeed.

That is only cosmetic in the CLI, but it feeds the mislabelling this issue already tracks in its third checkbox: a user reading Unifying Receiver off openlogi list will pick "Unifying receiver" in device_support.yml, and the report lands in the wrong bucket. #462 and #448 are both listed here as mislabelled for exactly that shape of reason.

Two ways to fix it, and the choice belongs with the route-shape decision this issue is holding:

1. Keep c539 in UNIFYING_PIDS for routing but consult a separate family table for the display name.
2. Move c539 into LIGHTSPEED_PIDS. Routing is unchanged: speaks_unifying_protocol is already UNIFYING_PIDS || LIGHTSPEED_PIDS, and both lists resolve to DeviceRoute::Unifying — only receiver_display_name reads the two apart.

Happy to send (2) plus a test as a small PR if that is the preferred shape — it is roughly a one-line move and an assertion alongside the existing receiver_display_name cases.

On the third checkbox (device_support.yml offers no Lightspeed connection option): related, and I have a separate report open that makes those blocks fillable on Windows at all — the Windows artifacts ship no openlogi binary, so the openlogi list / openlogi diag features output the template asks for cannot be produced there. #658, with the packaging fix in #659.

[albertorm95]

I have a G502 X Plus, how can I collab here? I don't see it in the list

lsusb
ID 046d:c547 Logitech, Inc. USB Receiver

[kublaios]

G604 over Lightspeed receiver c539, detected, no 0x1b04

G604 on its bundled Lightspeed receiver (046d:c539), macOS.

Feature dump:

device: G604  (slot 1 on receiver 0F9C1CE6)
   idx      id  ver
     0  0x0000  v1
     1  0x0001  v1
     2  0x0003  v2
     3  0x0005  v0
     4  0x1d4b  v0
     5  0x0020  v0
     6  0x1000  v0
     7  0x8070  v4
     8  0x1300  v0
     9  0x8100  v0
    10  0x8110  v0
    11  0x8060  v0
    12  0x2201  v1
    13  0x00c2  v0
    14  0x1802  v0
    15  0x1803  v0
    16  0x1805  v0
    17  0x1806  v4
    18  0x1813  v0
    19  0x1830  v0
    20  0x1890  v5
    21  0x1891  v5
    22  0x1861  v0
    23  0x1801  v0
    24  0x18b1  v0
    25  0x1df3  v0
    26  0x1e00  v0
    27  0x1eb0  v0
    28  0x1e22  v0
    29  0x2121  v0
    30  0x18c0  v0
    31  0x1814  v1
    32  0x1815  v1
  (33 feature entries)

[Stanley5249]

#757