[Device] ZORNER ZH99 HE (sbarda firmware, 19f5:fb2a) — lighting protocol documented, offering a PR

[lostintired]

Device type

Keyboard

Device model

ZORNER ZH99 HE (Hall-effect, vendor configurator "sbarda")

vendorId:productId

19f5:fb2a

Connection type

Wired (USB)

What happens today?

Not detected (doesn't appear in the browser picker)

Diagnostics

Composite device, three interfaces (Windows HID enumeration):
MI_00            usage 0x01/0x06  Keyboard          in 9 / out 2 bytes
MI_01            usage 0x01/0x00  vendor channel    in 65 / out 65 bytes  <- settings
MI_02 COL01      usage 0x01/0x06  Keyboard          in 16
MI_02 COL02      usage 0x01/0x02  Mouse             in 6
MI_02 COL03      usage 0x0C/0x01  Consumer Control  in 3
MI_02 COL04      usage 0x01/0x80  System Control    in 3
MI_02 COL05      usage 0x01/0x0C  Wireless Radio    in 2

Can you help test?

Yes, and I can capture USB traffic (Wireshark / usbpcap)

Anything else?

Tested on Windows 11 over USB. Command 03 reports the firmware build date as Aug 1 2025, 11:08:11. The board is wired-only; the Wireless Radio Controls collection is just part of its HID descriptor. In Chrome the control.openmouse.app picker doesn't list it, as expected without a 19f5 filter.

I maintain KbLight (https://github.com/lostintired/sbarda-kblight, MIT), a small Windows tray app that keeps the lighting settings applied on this keyboard. I'd rather have the board supported in a project with a community than maintain a single-device tool on my own, so I'd like to contribute the protocol to keyboard-protocol.

Verified on my ZH99 HE (fb2a):

• MI_01 uses 64-byte output/input reports with Report ID 0, not feature reports.
• Requests are 55 <cmd> 00 <checksum> <len> <offset lo> <offset hi> 00 followed by up to 56 data bytes; replies start with AA <cmd>. The checksum is the low byte of the sum of payload bytes 4–63 (0-based, excluding the report ID), in both directions.
• Commands 01/02 open and close a session; 05 reads and 06 writes a 32-byte settings block.
• Lighting is in bytes 8–16 of that block (effect, brightness, speed, direction, multicolor, color index, RGB) and bytes 24–31 (the RGB neon light box, which on the board itself is only adjustable with Fn keys and which the vendor configurator can't set). I haven't decoded the remaining bytes.

KbLight writes with read-modify-write: read the block, change only the lighting bytes, write, then read back and compare. Unknown bytes go back untouched, which I believe is what your CONTRIBUTING asks for.

Not fully verified: 20 preset effect codes and the parameters each one accepts. They come from the vendor configurator's database, and I've only checked some of them on the board by eye.

One quirk affects the design: the board doesn't keep written settings across power loss. After a replug it falls back to its default effect, so the lighting only sticks if something re-applies it on connect, logon and resume. The vendor configurator writes with the same 06 command and doesn't re-apply anything on startup; I haven't found a save-to-flash command in its traffic, though its binary has several opcodes I never saw on the wire. KbLight does the re-applying today. In OpenMouse, that looks like a job for Bridge rather than the web panel.

Caveats:

• Only fb2a is tested. The vendor configurator also lists 19f5 PIDs fb29, fce0, fe20, fe50, ff0c and ff1d, but I don't know which models they belong to.
• My protocol notes are in Russian (https://github.com/lostintired/sbarda-kblight/blob/main/docs/PROTOCOL.md). The PR would include an English coverage ledger, docs/sbarda-support.md, in the same format as your other docs/ files, and sanitized request/reply fixtures for the tests.
• Scope is lighting only. I haven't looked at actuation or rapid trigger on this board.

Two questions before I start:

1. Would you accept a src/sbarda/ codec with a driver in src/drivers/, verified: true for fb2a only, plus a lighting card in openmouse?
2. Bridge can already apply DPI and polling rate with the browser closed. Would a similar native path for keyboard lighting be welcome, re-applying the saved state on device connect, logon and resume? If so, I can look into it after the protocol PR.