AlienFX lighting on Linux without Command Center

Why the lights do nothing on a fresh install

On Windows, Alienware Command Center (AWCC) is what tells the lights what to do. Dell has never shipped it for Linux, so on a stock install nothing talks to the lighting hardware and it keeps running whatever its firmware already holds. Unlike the fans, there is no kernel driver to lean on here: on the current m16/m18 generation the lights are plain USB HID devices, and the protocol lives in user space. And there is not one lighting device but two.

Two USB devices, not one

The ELC does not drive the keyboard on these machines. Cryo's own first releases got this wrong: they addressed the ELC as a "4-zone keyboard" with zones 0 to 3, which is the AWCC keyboard default, and on the m18 R2 those ids turned out to be chassis lights and one phantom. The keys did not change until 0.6.0 added a separate driver for the Darfon device.

What the kernel does and does not do

On an m18 R2 running kernel 7.2, both devices are claimed by the generic HID driver (usbhid, hid-generic). Each gets a /dev/hidrawN node, readable and writable by root only, and neither shows up under /sys/class/leds. There is no brightness file to echo into: lighting means writing HID reports from user space.

The mainline alienware-wmi driver does carry an older lighting interface, but not for these machines. Per the kernel documentation, before the M-Series laptops (around 2018) the "WMAX" WMI device controlled basic RGB lighting along with deep sleep, HDMI mode and the amplifier; on newer machines the same device was repurposed for thermal profiles and sensors, which is what the fan control guide builds on. The kernel docs also note that machines with the AWCC interface usually carry an embedded STM32 RGB lighting controller, and the driver exposes two of its GPIO pins in debugfs for debugging. Neither is documented as a way to color the two USB devices above.

Read what your machine has

These are read-only and need no root. Output is from an m18 R2 on kernel 7.2.

lsusb | grep -E '187c|0d62'
# Bus 001 Device 005: ID 0d62:aab1 Darfon Electronics Corp. Keyboard
# Bus 001 Device 007: ID 187c:0551 Alienware Corporation AW-ELC
grep -H HID_NAME /sys/class/hidraw/*/device/uevent
# /sys/class/hidraw/hidraw0/device/uevent:HID_NAME=Alienware AW-ELC
# /sys/class/hidraw/hidraw4/device/uevent:HID_NAME=DELL Technologies Keyboard
# (plus the touchpad, sensor hub and any external receivers)
ls -l /dev/hidraw4
# crw------- 1 root root 243, 4 Nov  9 08:49 /dev/hidraw4
ls /sys/class/leds/
# input3::capslock input3::numlock ... phy0-led   (nothing for the backlight)

The hidraw number is not stable and can change after a resume, so find the keyboard by vendor id each time instead of hardcoding a node.

The chassis controller and its zones

On the m18 R2 the ELC zone ids map like this. They were found by lighting candidates one at a time, because the device tables published online are partly wrong for this firmware.

The controller also has two kinds of animation that blend per zone: a post-boot user animation, and six power-state slots (AC sleep, charged, charging; battery sleep, on, low). The power-state layer re-asserts itself on the power button, so a user animation that drives the button flickers and goes dark, while a slot that mentions the rings or lid makes them flicker. What works: the rings and lid in the user animation, the button alone in the four active power-state slots, the two sleep slots dark. That replaces the stock blue-on-AC button color, and because the slots are stored in the controller, AWCC on Windows reprograms them if you dual-boot.

The keyboard protocol

The keyboard speaks what alienfx-tools calls API V5. Every command is one feature report, exactly the report length (64 bytes on the m18 R2), zero padded, starting with 0xCC:

The m18 R2 map is a 20 by 8 grid of 136 light indices, and the wire id is the index plus one. Two gotchas cost real time:

• Send exactly the report length. A 65-byte packet lets a 16th block spill past the end, and every 16th key keeps its old color.
• Wait after an update. After leaving a firmware effect, poll status until byte 2 is no longer 0x80 before sending colors, or the first packet (the top row) is dropped.

And not every firmware effect is safe. Tested on the m18 R2:

So the firmware has no smooth multi-color mode. For a rainbow or a two-color morph on the keys, software has to stream whole-keyboard frames: reset, status, ten color packets, loop and update, about 14 feature reports per frame.

Tools that already exist

• alienfx-tools (T-Troll) is a Windows 10 and 11, 64-bit suite for Alienware lights, fans and power settings. Its SDK and alienfx-cli documentation are the reference for the API V5 keyboard protocol, including the effect type list above.
• AWCC (tr1xem) is an unofficial Linux alternative to Command Center with a GUI and a CLI, covering fan controls, light effects, G-Mode and autoboost. Its author is building support for more Dell lighting devices in tr1xem/alienfx-linux, whose packet captures are the other half of the keyboard reference.

Cryo's ELC protocol is ported from tr1xem/AWCC (GPL-3.0), and its keyboard code follows alienfx-tools and the alienfx-linux captures.

What Cryo does

Cryo is a root daemon (cryod), a CLI (cryoctl) and a desktop app (cryo-gui). The daemon owns both lighting devices and pushes every effect to whichever of them is present; the CLI and app talk to it over a socket that the installer opens to your account's group, so lighting changes need no sudo. There are eight effects:

The three streamed effects run at 8 fps; on the m18 R2 a frame takes about 34 ms to send. They are frames the daemon sends, so they move only while cryod runs.

cryoctl light quantum
cryoctl light static 00D1FF      # color-based effects take an optional RRGGBB
cryoctl light backforth ff2d2d
cryoctl brightness 80            # 0-100, both devices

Brightness is one value for both devices. Effect, color and brightness are saved in /var/lib/cryo/state.json and re-applied when the daemon starts (the lighting.restore setting, on by default), so they survive a reboot; until you set something, the default is Quantum at 60 percent. After suspend, cryod-resume.service runs cryoctl reapply, which reopens both devices (USB re-enumerates, and the hidraw node can be a new one) and restores the lighting along with the power profile. The power button follows the effect as described above: smooth on AC and on battery, dark in sleep.

What doctor reports

cryoctl doctor works without root and without the daemon. The lighting lines on the m18 R2:

alienware usb (187c)   0551
known AW-ELC           True
per-key keyboard (0d62) /dev/hidraw4 (64-byte report)

These lines read sysfs. The daemon capabilities JSON further down carries lighting_elc and lighting_keyboard, which say whether the running daemon could actually open each device. If neither device is found, the verdict lists "AlienFX lighting (no AW-ELC controller, no per-key keyboard)"; with the keyboard but no ELC, it lists "chassis lighting (no AW-ELC controller; keyboard backlight only)". Without the Darfon keyboard, the keys keep their firmware lighting and the chassis effects still work.

Without libusb-1.0

The ELC is reached through libusb, the keyboard through plain hidraw. Before 0.7.0 a machine without the system's libusb-1.0 sent cryod into a crash loop; since 0.7.0 it reads as "no lighting controller": chassis lighting is unavailable, and the keyboard is still driven. The package is libusb-1.0-0 on Debian and Ubuntu, libusb1 on Fedora and libusb on Arch, and desktop installs usually have it already. The installer's summary says when it is missing. In that state known AW-ELC can still read True while lighting_elc is false.

What is not supported or not verified

• Models. Both devices are verified on the Alienware m18 R2 only. The Alienware 16X Aurora AC16251 is a community SUPPORTED report that confirmed its AW-ELC 187c:0551; whether its keyboard is a separate Darfon device is not recorded. The 2011 Aurora R4 desktop gets no lighting: its 187c:0513 controller predates AW-ELC.
• The m16 and other m18 revisions. Cryo's compatibility table lists the same Darfon keyboard (0d62:aab1 or bab1) for the m16/m18 R1 and R2, and Cryo finds the keyboard by vendor id and the 0xCC report, but the keyboard protocol has only been verified on the m18 R2.
• Pre-ELC controllers and their older AlienFX protocols.
• Keyboards wired to the ELC itself. Some G-Series and m15 models use ELC zones above 0x0f for the keyboard; those are not mapped.
• Your own per-key patterns. The keys show the eight effects only.
• Lighting tied to power mode. Neither the kernel nor Cryo changes lighting when the profile changes.

Run cryoctl doctor on your machine and open a model report on GitHub, working or not. Install steps are in the quick start.