Confirmed working: Alienware 16X Aurora (AC16251), with one small quirk

[liviubrinza]

Summary

Confirming the Alienware 16X Aurora (AC16251) works with alienfx-linux. Per-zone
color control and hardware-persisted state both function correctly. Filing this as
a tested-device data point, plus one detection quirk that may be worth a look.

System

• Laptop: Alienware 16X Aurora (AC16251), BIOS 1.0.0 (April 2025)
• OS: Zorin OS 17.3 (Ubuntu 22.04 base)
• Desktop: GNOME 46, Wayland
• Kernel: 7.0.0-28-generic

Device

• Detected as: Alienware AW-ELC, VID 0x187c, PID 0x551, APIv4
• Zones (4 total), mapped via probe:
  • 0 = left
  • 1 = center
  • 2 = right
  • 3 = numpad
  • 4–22 = no effect (unused)

What works

• probe correctly drives each zone during testing
• setone 0 <zone> <r> <g> <b> sets individual zones as expected
• -s (save) persists state across a full reboot — confirmed the keyboard stays
  in the saved state after power cycle

Quirk: status reports "0 lights"

status shows the device but reports 0 lights, even though the zones respond
correctly by ID:

Device #0 - Alienware AW-ELC, VID#0x187c, PID#0x551, APIv4, 0 lights

Because of the 0-light count, setall and setdim produced no visible effect,
but setone targeting explicit zone IDs (0–3) works fine, as does probe. Looks
like light-count detection isn't populating for this APIv4 variant even though
control is fully functional.

Happy to provide any additional captures or test specific commands if useful.
Also a BIG thank you for the work you put in! This was the only way I could get my keyboard backlight to do anything under Linux

[tr1xem]

Thanks for opening a issue

For 0 light count I tested the app and what i think is you are running probe with sudo while status and other commands without sudo

the mapping file is located at /root/.local/share/alienfx/mapping.json can you verify and send the file