Keyboard lighting on 2024+ Predators (Helios Neo 16) via AcerService fallback

[GodrezJr2]

Summary

On a Predator Helios Neo 16 (PHN16-72, BIOS V1.18) OpenSense shows no Keyboard light, only Light bar and Logo. This adds a Keyboard light through AcerService's local API as a fallback, so the keyboard can be recoloured without PredatorSense's UI.

What I found

Diagnostics on this model:

GetGamingKBBacklight = error
=> keyboard: rgb=False zones=0 ledArray=16 ...

• SMBIOS reports an LED array (ledArray=16), so the RGB keyboard exists, but the GetGamingKBBacklight probe errors, so rgb stays false.
• While PredatorSense changed the keyboard colour, WMI-Activity logged no ExecMethod at all, so it is not the ACPI-WMI class.
• USBPcap on both root hubs saw no matching write either. The 258A:010C keyboard chip only showed enumeration control traffic, and the only bulk traffic was a USB mass-storage device.
• PredatorSense/AcerLightingService reach the keyboard through a local JSON API on 127.0.0.1:46933 (ACER magic + packet id + JSON). I found the protocol through hammadzaigham/PreySense, which documents it, and confirmed it on this laptop (VERSION handshake, LIGHTING query, LIGHTING set).

Change

• AcerServiceTransport: minimal client for that API (optional AES-ECB key from HKCU\Software\Acer\XSense\AESkey, as PreySense does).
• AcerServiceKeyboardBackend / LightingBackendKind.AcerServiceKeyboard: 4 zones, the same 7 zoned effects, same id as the native keyboard so settings carry over.
• CapabilityProbe: offers it only when the native keyboard path is absent and SMBIOS has an LED array and the port answers. Laptops that work natively are unchanged, and laptops without an RGB keyboard still show no tab.
• Logs AcerService keyboard fallback: ... in the diagnostics.

Tradeoffs, please weigh in

• This needs AcerLightingService running, which goes against OpenSense not needing Acer's stack. It is only a fallback for hardware with no known native path. I'm happy to gate it behind a setting if you'd rather it be opt-in.
• The proper fix is the real transport (which appears to be an EC-backed path that neither WMI nor USB capture sees). I did not find it.

Tested

• dotnet test: 478 pass (2 new).
• Real hardware, PHN16-72: the Keyboard tab appears and Static colours change the keyboard.
• Not verified: the animated effects, the direction encoding for Wave/Shifting (commented in the code), and per-zone colour independence.

Diagnostics excerpt above; I can paste the full dump if useful.

🤖 Generated with Claude Code