Fix: headset/USB-HID tools no longer starved when the dongle is plugged in
The wake feature advertised USB `REMOTE_WAKEUP` (bmAttributes `0xE0`) in the configuration descriptor unconditionally whenever `ENABLE_WAKE_HID` was compiled — which was ON by default since the wake toggle landed (30 May).
A wake-capable device is treated specially by the host USB stack. On Linux, Wine/Proton's libusb HID scanner grabs every wake-capable HID device on the bus — including unrelated peripherals such as an Arctis headset command interface. That starved the headset's control daemon with `EBUSY`, so the headset appeared permanently offline while a Proton game was running.
What changed
- Standard firmware now ships with `REMOTE_WAKEUP` OFF (`bmAttributes 0xC0`) — identical enumeration to pre-wake firmware. This is the recommended build for everyone.
- A separate `ds5-bridge-wake-*.uf2` is now published on every release for users who specifically need the dongle to wake a sleeping Windows host (and accept the Linux/Proton trade-off).
Which UF2 to flash
| Asset | When to use |
|---|---|
| `ds5-bridge-v1.2.10-autohaptics.uf2` | Default. Recommended for everyone. |
| `ds5-bridge-wake-v1.2.10-autohaptics.uf2` | Only if you need host-wake on Windows. |
| `ds5-bridge-debug-v1.2.10-autohaptics.uf2` | Troubleshooting (USB-serial verbose logs). |