Click any physical key on the keyboard canvas above to paint individual keys below.

Click any physical key on the keyboard above to inspect its actuation, Rapid Trigger sensitivity, and Hall-effect sensor ADC levels.

Adjust analog key press depth actuation and Rapid Trigger sensitivity. Product ranges: trigger 10–359 (~0.1mm–3.6mm), release 4–330, reset 4–330.

Manage keyboard configuration profiles stored on onboard memory.

⚠️ Profile writes (0x55/0x58/0x59) are exposed but can permanently change device state; only recovery is factory reset. Always take a snapshot first.

Each of these sends the one-byte profile index at +0x88 (PROTOCOL.md §8.24). Add (0x58) is keyed to the profile index you give it — the Windows app passes the currently selected row. Delete (0x59) refuses to run when only one profile remains, exactly as FUN_1400228a0 does.

The Windows app's Export and Import profile buttons are host-side file handling, not protocol operations: export dumps what these four commands read back, and import replays the corresponding writes through a decoded chain (PROTOCOL.md §8.22: a 0x56 name frame, then 0x57/0x50/0x11/ 0x14/0x20/0x23/0x40/ 0x28, each fired by the previous write's last-page ack). It is not wired here, because a correct import is only as safe as the gated writes it replays, and none of them has been hardware-validated.

Reads all ten of the device's configuration tables in one pass and shows them decoded. This mirrors what the Windows app's SyncConfigUtil collects before it pushes a configuration back (PROTOCOL.md 8.17).

Take one before changing anything. Writes to this board can only be recovered with a factory reset, which discards every profile and binding. This snapshot is the only record of the current state that can be made from the host.

Every call is a read. Nothing here can damage the device, and the JSON is plain text you can keep or diff.

Hardware performance, report rate, and debounce filters. Values are read-modify-written with readback verification.

Eight global settings carried by the 20-byte 0x50/0x5E blob. The field names come from the params_table DDL the app ships inside GameKeyboard.exe, and the widths come from reading that table back out of SQLite (PROTOCOL.md 8.14).

Values are shown as raw device numbers, not decoded. The columns tell us which byte is which, but not what 0 and 1 mean for the switches, nor which polling rate maps to which byte - so the form does not pretend otherwise.

Applying reads the device first and rewrites only the rows you changed; the other six settings and the reserved bytes come from the device unchanged. Every write is read back and reported.

The per-key remap table, the same data behind the Windows app's KeySetForm. Records are 3 bytes and the third is a HID usage ID, so entries decode to real key names; anything unmapped stays numeric rather than being guessed.

Writes are not offered: 0x20 and 0x24 are two distinct commands, and both are now decoded byte-for-byte (§8.19, §8.21.3-8.21.4). They stay gated because neither has run against hardware and each replaces a whole layer. The first test must be read → write back byte-identical → read and compare.

A read alone cannot tell you which keys are remapped: the record carries no changed flag, and a key index is not a HID usage. Read the board, set that as the reference, change something, then read again — the keys that differ are listed.

keyItem is implied by position and never sent; the three wire bytes are type, hValue, lValue (§8.19).

Ten slots, M1–M10, matching the Windows app's macro editor. Each step is one 6-byte record — type, state, lValue, hValue, and a 16-bit little-endian time in milliseconds. The key is a HID usage split across lValue/hValue, and state is 1 for down, 0 for up.

Bytes 0 and 1 are transposed on the wire. This form works in struct order and the driver applies the transposition, so what you see here is what is stored.

The field names come from the key_macro_table DDL that the app ships inside GameKeyboard.exe to persist exactly this data (PROTOCOL.md 8.12).

⚠️ Fn-layer writes (0x22/0x25) modify bindings; take a snapshot before changes. 0x23 is not a per-key edit: it is a paged 19-byte bulk write used only by the Windows app's config-import worker, and is not wired here (§8.21.8).

The Windows app's HighKeyForm stores six advanced per-key modifiers here — DKS (Dynamic Key Stroke), MT (Hold/Click), TGL (Toggle), RS (Radial Sensing), SOCD (Simultaneous Opposing Cardinal Directions, with four resolution modes) and OKS (Key Override on Release). They live in these bindings rather than in the plain keymap, so a driver that only exposes keycodes cannot express them.

Every modifier's record code and length are decoded (PROTOCOL.md §8.3.2). The codes do not run in label order: TGL=0, MT=1, DKS=2, RS=3, OKS=4, SOCD=5, while the app lays the dialogs out as DKS, MT, TGL, RS, SOCD, OKS. SOCD is fully specified (key, type, key1, key2, resolution mode); the other modifiers' data bytes are still unnamed, so those stay a raw hex field.

The keyboard's own HID interface (0x0006) is a protected usage and Chrome will not expose it, which is correct — the config channel is the vendor collection. If the picker lists several entries, choose the one whose collection tree contains usage page 0xFF02.

WARNING: This console sends raw frames. REFUSED: Firmware (0x60,0x65,0x66) and unclassified opcodes. DANGEROUS: Actuation (0x26-0x28), calibration (0x53,0x54), transport/config (0x56), keymap (0x20,0x24). Only use if you understand the risks. Gated writes not enabled by default.