The K70 RGB PRO V2 (1B1C:1BB3) was detected but never lit: it blanked
into software render mode and then fell back to its onboard effect.
Getting it working turned up five faults, three of which affect every
Corsair V2 device rather than just this keyboard.
Packet size is now read from the HID report descriptor before the first
write instead of being inferred from a reply. These devices come in a 64
byte and a 1024 byte flavour, and sending a short packet to a 1024 byte
endpoint stalls it until the device is power cycled, so the size has to
be known up front rather than after two short queries have gone out.
CORSAIR_V2_PACKET_SIZE was 1024 while pkt_sze reached 1025, so every
read using pkt_sze overran its stack buffer by a byte. The command
helpers now use pkt_sze against buffers of the corrected size.
The lighting resource probe ran before the device was placed in software
render mode, where the answer is meaningless, and treated any error as
"use resource 1". Devices that answer invalid or unsupported for
resource 1 want the alternate lighting resource, which takes RGB
triplets; this keyboard is one of them. The probe now runs after the
render mode switch and distinguishes a stale open handle from an
unsupported resource.
Direct lighting writes were sized from the keymap, which covers only the
keys that exist. The hardware expects its full slot count and ignores a
short write, so corsair_v2_device carries an optional hw_led_count and
the buffer map is padded to it. Set to 193 for this keyboard.
The keepalive thread wrote LEDs on its first pass, because
last_update_time was left at the clock epoch and so always read as older
than the update period. That raced detection on the same HID handle with
no locking, which both corrupted the transaction and could abort the
process. The clock is now started before the thread runs, device
transactions are serialised behind a mutex, and the thread is stopped
before Shutdown rather than after.
Also fixes an uninitialised stack buffer sent to the device during
setup, and widens the K70 RGB PRO matrix to 22 columns so the numpad
period key has a position in the layout instead of being dropped.
Verified on hardware: repeated colour changes apply and the device stays
responsive across runs.
Co-Authored-By: Claude Opus 5 <[email protected]>
Measured on an ASRock Intel Arc B580 Steel Legend, which uses this same
packet: holding everything else fixed and stepping data[5] through 0xFF,
0x40 and 0x00 dims the zone progressively and turns it off at zero, while
data[4] does not change brightness. So data[4] is the effect speed and
data[5] is the brightness, the other way around from what the comments
said. The bytes written are unchanged, this only fixes the labels.
Every other ASRock controller shuts the device thread down before deleting
the controller. This one did not, so tearing it down logs
Device thread still active in base class destructor, ensure Shutdown()
was called from inherited destructor
on every exit. Seen on an ASRock Intel Arc B580 Steel Legend, but the file
is shared with the Radeon Steel Legend and Taichi cards.
hid_get_report_descriptor returns -1 on failure and the length was
stored unsigned, so the descriptor walk ran past the end of the stack
buffer. Windows reconstructs the descriptor from preparsed data and can
fail where Linux returns the kernel's copy. A failed read now leaves the
device with no lamps, the same as a descriptor with missing reports.
SalastilandClaude Opus 5