With a 10 ms wait an occasional glitch remained; the keyboard is likely
sometimes slower to echo, so the next packet still arrived too early.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The keyboard echoes each colour packet back; wait for that echo before
sending the next one, like OpenRGB's EVision driver, instead of firing all
packets back to back. Skip packets whose colours did not change and resend
the whole frame every 500 ms so the keyboard stays under plugin control.
Add a passive listener tool for the echoes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The keyboard applies each packet as it arrives. With 56 colour bytes per
packet, LEDs 18, 74 and 93 straddled two packets and briefly showed a mix of
old and new colour. 54 is a multiple of 3, and 7 x 54 covers exactly LEDs
0..125, so the frame no longer pads past the last LED either.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lets the frame rate be capped at 30, 15 or 10 fps to find out whether the
occasional random-colour flashes on single keys depend on the update rate.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Drop the per-packet device.pause(1), which rounds up to the Windows timer tick
and capped the keyboard at roughly 10 fps; keep a pause in low frame-rate mode.
Add a "Key test" option with column and row sweeps to verify the LED map.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Per-key RGB for the wired Womier K87 (EVision firmware, 320F:502A) using the
EVision protocol, with the 87-key LED map found by hand.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mangavalkandClaude Opus 5.5