Repository navigation
Device request: Lamzu Paro Aurora (0x37b0: 0x000d / 0x0001 / 0x0007) #167
Description
Activity
PID correction — I pulled Lamzu's official Aurora web configurator device table (https://www.lamzu.net/Config/env-models.json, ModelEN: PARO), which gives the exact roles:
- 0x0007 = mouse on its cable (PIDWired)
- 0x000d = 1K receiver (_1KDongle)
- 0x000e = 8K receiver (_8KDongle)
So the 8K dongle is 0x000e, not 0x0001 (0x0001 appears in the table only as _8KDongleIDVD). Rate lists from the table: wired 125–1000 Hz, 1K dongle 125–1000 Hz, 8K dongle 500–8000 Hz; DPIMax 30000. Bootloader identities to keep excluded: 0x0008 (mouse DFU), 0x0004 (1K dongle DFU); 0x0002 (8K dongle DFU) is shared with the Inca 8K and already excluded. The protocol flags match the Inca 8K entry exactly (IsNewProtocol: 1, IsCompx: 0), so the Paro Aurora should work with the existing lamzu driver via catalog entries alone. None of the three PIDs has been exercised on hardware yet — I can test on a real unit and report back.
Fixed in #172 — catalogued the Paro Aurora under Lamzu's own vendor id
0x37b0:0x0007wired and0x000d1K dongle at 125-1000 Hz,0x000e8K dongle at 500-8000 Hz, with0x0008/0x0004/0x0002bootloader ids excluded. Thanks for the PID correction from the official configurator table — it's what made this a catalog-only change. None of the three has been exercised on hardware yet, so a wrong rate list is the failure mode rather than a dead device.🎉 This issue has been resolved in version 0.26.0 🎉
The release is available on:
Your semantic-release bot 📦🚀
- added a commit that references this issue
on Oct 7, 2026
Device Support / Protocol Request: Lamzu Paro Aurora
Device Overview:
Why it may be cheap to add:
@openmouse/protocol/lamzucatalog covers Maya X, Inca 8K, CRDRAKO KO-ONE and Attack Shark models, but not the Paro Aurora.LAMZU_INCA_PRODUCTS.Evidence:
Hardware verification: not done yet. I'm happy to test on real hardware and provide
lsusboutput / WebHID enumeration details if a driver build becomes available.