feat: Add lamparray support

[scardracs]

New Asus devices has a I2C-HID controller named ITE5570 which supports lamparray (the windows' common way to setup lights). This PR should take care of it. Please test it on a supported device and report back as mine does not have that I2C controller (my G614pr still uses a usb N-KEY).

Closes: #148

[Rivet0153]

DISCLAIMER I did some testing on this branch with Claude. I am not a developer nor do I claim to understand the response generated by Claude. If none of the information below is useful, Add me on discord and maybe I can help out since I have the hardware. Discord: Rivet0153

Testing on ASUS TUF Gaming A16 FA608PM — found and fixed the LampRangeUpdate report format bug

Hardware: ASUS TUF Gaming A16 FA608PM (BIOS FA608PM.321), Ryzen 9 8940HX, RTX 5060
OS: Nobara Linux 44, kernel 7.0.1-200.nobara.fc43.x86_64

Device match: Same VID:PID as the FA608WV this PR targets (0B05:19B6), but the chip identifies differently:

HID_NAME=ITE51368:00 0B05:19B6
HID_PHYS=i2c-ITE51368:00

(FA608WV reports ITE5570, mine reports ITE51368 — likely a different revision of the same family, sharing the USB PID.)

Initial result

Built and ran this branch directly. asusd found the device correctly:

Found ASUS HID LampArray candidate: hidraw1 VID=0B05 PID=19B6
LampArray ready: 0b05:19b6 on "/dev/hidraw1"
LampArray ready: LampCount=1 rgb=(ff,00,00) i=128

No errors logged, but the keyboard backlight did not physically respond to any color/effect command.

Diagnosis

Bypassed asusd and sent the raw HIDIOCSFEATURE ioctls directly (control report 0x46 + range update 0x45) — both returned success at the kernel level with no errno, confirming this wasn't a permissions/driver issue.

Pulled the device's own HID report descriptor (/sys/class/hidraw/hidraw1/device/report_descriptor) and decoded the actual field layout for report 0x45 (LampRangeUpdateReport):

Usage 0x55 (LampUpdateFlags): 8-bit → 1 byte
Usage 0x61 (LampIdStart): 16-bit → 2 bytes
Usage 0x62 (LampIdEnd): 16-bit → 2 bytes
Usage 0x51-0x54 (R,G,B,I): 8-bit → 4 bytes each

Total payload = 9 bytes + report ID = 10 bytes.

The current code sends 8 bytes, treating LampIdStart/LampIdEnd as 8-bit fields instead of the 16-bit fields this chip's descriptor actually declares. The ioctl succeeds (it's not malformed enough to error), but R/G/B/Intensity land at the wrong byte offsets on the wire, so the chip receives garbage and does nothing visible.

Also confirmed via HIDIOCGFEATURE readback of report 0x41 (LampArrayAttributesReport) that LampCount=1 is correctly detected — that part of the existing code is fine.

Fix confirmed working

Corrected 10-byte layout:

[report_id=0x45, flags=0x01, LampIdStart_lo, LampIdStart_hi, LampIdEnd_lo, LampIdEnd_hi, R, G, B, I]

Sent via raw ioctl (bypassing asusd) — keyboard lit up correctly in red, green, and blue.

Suggested fix

In the report-building code for 0x45, change LampIdStart/LampIdEnd from 1-byte to 2-byte little-endian fields (matches Python struct.pack("<BBHHBBBB", ...) layout). Happy to share the full raw descriptor dump (748 bytes) and both test scripts if useful — can also test a patched build if someone wants to point me at a branch.