Cryo Docs
Everything to get Cryo running on an alienware-wmi laptop: requirements, install, compatibility, configuration, architecture, and the security model. Then dive into the 11-command CLI Reference.
Step 1 → 3
Quick start
From git clone to a running daemon in one command.
1Check the requirements
- alienware-wmi kernel driverAll thermal I/O goes through the in-kernel driver over sysfs — no acpi_call, no out-of-tree modules.
- NVIDIA proprietary driverGame detection reads dGPU process state via NVML. Without it, Cryo degrades gracefully — everything else keeps working.
- Python 3.12+The daemon, GUI, and CLI are Python 3.12 on PySide6/Qt 6.
- uvAlready installed and on your PATH before you run the installer — it provisions an isolated uv venv, no system pip pollution.
Developed on the Alienware m18 R2, designed for the alienware-wmi family (Alienware and Dell G-Series). The daemon probes what your machine supports at startup and the GUI, tray, and CLI render only what exists — see Compatibility below. The m18 R2 is the only tested model so far; watch your temperatures on first runs.
2Install from source
The installer provisions a uv venv, creates /etc/cryo, installs the cryod systemd unit, and adds a desktop entry:
$ git clone https://github.com/I4cTime/cryo.git && cd cryo && sudo ./packaging/install.sh
To update later, pull and re-run the installer:
$ cd cryo && git pull && sudo ./packaging/install.sh
Verify with cryoctl doctor first (it works without the daemon and lists what was probed), then cryoctl status — see the CLI reference for all 11 commands.
3Check compatibility
Every feature is probed at startup. What the kernel or the machine doesn't offer is hidden or disabled with a visible notice — never assumed.
| Feature | Requires | When missing |
|---|---|---|
| Power modes | alienware-wmi platform profiles | Cryo won't start without the driver |
| G-Mode | G-Mode-capable model (kernel advertises balanced-performance and performance) | "Performance" becomes the boost profile; auto-rules fall back |
| Fan curves + manual boost | fan*_boost support — probed; "not implemented in every model" per the kernel docs | Curves and sliders disabled with a visible notice |
| Thermal Guard | Fan boost (above) | Disabled — nothing to actuate |
| Auto profiles (AC/battery) | A Mains-type power supply in sysfs (name discovered, not assumed) | Battery rules never fire; everything else works |
| CPU Turbo toggle | intel_pstate/no_turbo or cpufreq/boost | Toggle hidden |
| Game detection | NVIDIA proprietary driver (NVML) | Auto-G-Mode off; manual modes unaffected |
| AlienFX lighting | AW-ELC USB controller 187c:0550/0551 (≈2020+ m/x-series keyboards) | Lighting section hidden |
Tested models
| Model | Thermals | Curves / Guard | G-Mode | Lighting | Game sense | Reported by |
|---|---|---|---|---|---|---|
| Alienware m18 R2 (Intel + RTX 4080) | ✓ | ✓ | ✓ | ✓ | ✓ | maintainer |
Have a different Alienware or Dell G-Series machine? Run cryoctl doctor and open a model report with the output — working or not, both results grow this table. The canonical matrix lives in the repo's COMPATIBILITY.md.
Known out of scope for now: AMD dGPU game detection (needs DRM fdinfo instead of NVML); Pre-ELC lighting controllers (older AlienFX protocols, per-key RGB); Aurora/Area-51 desktops (thermals may work; entirely untested).
Configuration
/etc/cryo/config.json
Deep-merged over the shipped defaults — a partial file (even an empty object) is always valid. Set only what you want to change.
{
"profiles": {
"custom": {
"curves": {
"cpu": [[45, 0], [60, 15], [70, 35], [80, 60], [88, 85], [95, 100]],
"gpu": [[45, 0], [60, 15], [70, 40], [80, 70], [87, 100]]
}
}
},
"auto_rules": {
"on_battery": "quiet",
"on_ac": "balanced",
"on_game": "gmode",
"after_game": "balanced"
},
"gamesense": {
"ignore": ["xwayland", "gnome-shell"]
},
"lighting": {
"effect": "quantum",
"brightness": 80
}
}The example above is illustrative — it shows the shipped defaults for the curves, auto_rules, and lighting keys. The file holds only your overrides and the daemon never rewrites it; what the daemon changes on its own (last lighting, the curves-off latch a manual boost sets) lives in /var/lib/cryo/state.json. Curve points are [temperature °C, fan boost %]; the ignore list under gamesense matches exact lowercase process basenames, never substrings. Print the effective merged config with cryoctl config.
How it fits together
Architecture
One root daemon owns the hardware; the GUI, tray, and CLI are thin clients on a Unix socket.
- cryod — the root daemonRuns under systemd as root and is the only process that touches hardware: platform profiles and fan boosts via the alienware-wmi sysfs interface, game detection via NVML, and AlienFX via raw HID.
- /run/cryo.sock — one socket, JSON linesGroup-owned Unix socket, mode 0660. Requests and responses are single JSON lines; sending {"op":"subscribe"} upgrades the connection to a 1 Hz push telemetry stream.
- Thin clientsThe Qt GUI (QLocalSocket, 2-second auto-reconnect), the tray icon, and cryoctl are all equal clients of the same protocol — nothing in the UI holds hardware state.
- Config that can't half-break/etc/cryo/config.json is deep-merged over shipped defaults, so a partial file is always valid — set only what you want to change.
Security model
Permissions
Root where the hardware demands it, unprivileged everywhere else.
- Why root at allPlatform-profile and fan-boost writes go through privileged sysfs attributes, and AlienFX needs raw HID access. Isolating that in one small daemon means the GUI and CLI never need elevation.
- The socket is the boundary/run/cryo.sock is group-owned with mode 0660 — only root and members of the cryo group can talk to the daemon. No TCP port, nothing network-facing.
- In-kernel driver onlyAll thermal I/O uses the mainline alienware-wmi driver. No acpi_call, no out-of-tree modules, nothing taints the kernel.
Want the full tour?