fix(openrgb): follow the device when OpenRGB's device list changes #11

Merged

jwarykowski merged 1 commit from fix/openrgb-device-list into main

2026-10-14 03:33:23 +00:00

jwarykowski commented

2026-10-14 03:30:43 +00:00

(Migrated from github.com)

Why

OpenRGB announces device list changes unprompted: after a rescan, or when a device is plugged in or out. keybars only read from the server while waiting for a reply, so it never saw them. The keyboard could move to another index mid-run and its frames would go to whatever device took its place, and a rescan also resets devices to their saved mode, so the bars stopped showing.

What

A reader takes every packet as it arrives. Device list updates set a flag; replies go to the request waiting for them. Requests now time out after 5 s instead of hanging on a stalled server, and a reply that arrives too late is dropped rather than answering the next request.
The device follows itself. After an update, the next flush finds it again by name, serial and location, then name and serial (a replug can change the location), then a name only one device has. A match must have the same number of LEDs.
It's put back as it was. If keybars was driving it, it goes back to its per-LED mode and gets its whole frame.
Unplugged isn't fatal. While the device is missing, frames are dropped instead of failing, and painting resumes when it's back. RestoreAll goes to the new index too.
The controller description now keeps the serial and location it used to skip.

Testing

The fake server no longer announces an update before every reply; tests trigger updates on purpose.
TestFollowsDeviceListChanges: the keyboard moves from index 0 to 1, then disappears, then comes back at 0. Checks SETCUSTOMMODE and the whole frame go to the new index each time, nothing is sent while it's gone, and restore goes to the right device. Disabling the follow makes it fail.
TestSame covers the matching rules: exact, replugged, twins told apart by serial, ambiguous twins, a different LED count, gone.
TestLateReplyIsDropped: a stale reply in the queue doesn't answer a new request.
go test -race ./... passes.

Not verified

Still not run against real OpenRGB or a real keyboard.

## Why OpenRGB announces device list changes unprompted: after a rescan, or when a device is plugged in or out. keybars only read from the server while waiting for a reply, so it never saw them. The keyboard could move to another index mid-run and its frames would go to whatever device took its place, and a rescan also resets devices to their saved mode, so the bars stopped showing. ## What - **A reader takes every packet as it arrives.** Device list updates set a flag; replies go to the request waiting for them. Requests now time out after 5 s instead of hanging on a stalled server, and a reply that arrives too late is dropped rather than answering the next request. - **The device follows itself.** After an update, the next flush finds it again by name, serial and location, then name and serial (a replug can change the location), then a name only one device has. A match must have the same number of LEDs. - **It's put back as it was.** If keybars was driving it, it goes back to its per-LED mode and gets its whole frame. - **Unplugged isn't fatal.** While the device is missing, frames are dropped instead of failing, and painting resumes when it's back. `RestoreAll` goes to the new index too. - The controller description now keeps the serial and location it used to skip. ## Testing - The fake server no longer announces an update before every reply; tests trigger updates on purpose. - `TestFollowsDeviceListChanges`: the keyboard moves from index 0 to 1, then disappears, then comes back at 0. Checks SETCUSTOMMODE and the whole frame go to the new index each time, nothing is sent while it's gone, and restore goes to the right device. Disabling the follow makes it fail. - `TestSame` covers the matching rules: exact, replugged, twins told apart by serial, ambiguous twins, a different LED count, gone. - `TestLateReplyIsDropped`: a stale reply in the queue doesn't answer a new request. - `go test -race ./...` passes. ## Not verified Still not run against real OpenRGB or a real keyboard.