asusctl puts ASUS ROG fan curves, lighting and GPU MUX behind a D-Bus daemon

Three processes: a daemon, a client and a desktop app

The architecture is a D-Bus split into three parts, and the split is what makes the design work on a modern Linux desktop. asusd is the system daemon, the piece that actually talks to the hardware. rog-control-center is the graphical user interface for asusd, a desktop application with system tray integration and notifications. asusctl is the command line client for asusd. The stated primary goal is to provide a safe, efficient abstraction layer over hardware features using D-Bus, and it manages automated system responses, such as switching performance profiles when connecting or disconnecting AC power. The reason for the daemon is the udev model, since asusctl uses udev rules to initialize background services when hardware is detected, and a client that talks to a running service can respond to power events without the user doing anything. The workspace layout in the repository matches this, with separate crates for asusd, asusctl, asus-shutdown, asusd-user, rog-control-center and the shared libraries underneath them.

The daemon stays under 1 MB of RAM by design

The resource claim is specific enough to be worth quoting. The project states it operates with minimal CPU overhead and under 1 MB of RAM during standard daemon execution, and it presents that as resource efficiency alongside the clean interface. This matters for a background service, because the alternative on Linux has historically been a vendor utility that sits resident and is hard to reason about. The repository structure supports that claim rather than just asserting it, since the workspace members are split into small focused crates: config-traits, dmi-id, rog-platform, rog-dbus, rog-anime, rog-aura, rog-profiles, rog-slash and rog-scsi, with simulators as a separate crate. The simulators crate in particular suggests the daemon can be exercised without the physical hardware, which is the kind of thing a maintainer of a background service needs in order to test a power event handler.

Checking whether your laptop is supported starts with lsusb

The compatibility check is unusually concrete, which is a relief compared with a list of model numbers. asusctl supports most ASUS gaming laptops equipped with a USB keyboard, and to verify device compatibility you run lsusb and look for entries matching one of these identifiers.

Bus 001 Device 002: ID 0b05:1866 ASUSTek Computer, Inc. N-KEY Device

Bus 003 Device 002: ID 0b05:19b6 ASUSTek Computer, Inc. [unknown]

Devices showing these hardware IDs typically work without extra configuration. Features such as AniMe Matrix, LED controls and Slash displays work regardless of your laptop make, so the USB keyboard path is the general case. The catch is stated directly: on a newer laptop model, adding explicit hardware support may be required, and the documentation points to the laptop support requests section for that. The same paragraph draws a useful line between features. Battery charge thresholds use generic kernel interfaces and work on non-ASUS hardware, while platform and fan controls require the ASUS-specific asus-nb-wmi or asus-armoury drivers.

Kernel version decides which features exist at all

The dependency on kernel work is the single most important operational fact in this project, and the documentation puts it in a warning box at the top. Many features are developed alongside Linux kernel updates, so if an expected feature is missing, the instruction is to ensure you are running the latest stable kernel or a kernel containing the required patches. The suggested minimum kernel version is always the latest, because improvements are merged upstream continuously. The sharpest example is Thermal Design Power support, which is tied to the new asus-armoury driver, available mainline since Linux 6.19, and the documentation says everything older is not supported. So the feature list in the readme is effectively a moving target, and a feature marked as implemented is only implemented on a kernel that has the corresponding driver. This is the opposite of the usual packaging model, where a version number tells you what you get.

What the features cover, and the layout file behind the keyboard lighting

The implemented list is grouped by category, and it is more than lighting. Under power and performance there are battery charge thresholds for configuring maximum charging limits, custom fan curves on supported hardware, GPU MUX toggling to switch GPU operational modes such as G-Sync or MUX on 2022 and newer laptops, and power profile management documented in MANUAL.md. Under lighting and displays there are built-in LED controls for the integrated keyboard lighting modes, per-key RGB configuration, advanced lighting effects that are currently undergoing revision, and AniMe Matrix display control on the G14, M16 and Strix Scar 16 and 18 models. Under system integration there is the daemon, the graphical interface, and POST audio controls for toggling the BIOS boot sound setting. One implementation detail explains the occasional misconfiguration with backlights, since support relies on hardware mappings defined in a data file, ./rog-aura/data/aura_support.ron, installed to /usr/share/asusd/aura_support.ron. The reason given is that keyboard controller configurations vary across model generations and firmware revisions, and explicit layout definitions prevent misconfigurations. The Makefile confirms the arrangement by naming the file LEDCFG and installing it as data, so a new laptop generation may need a new mapping file rather than a code change.

Installing from a distribution package and enabling the services

Pre-built binary packages are available in several Linux distribution repositories, and the documentation advises checking your package manager before building from source. The table covers Ultramarine and Nobara, Fedora through the Terra repository, openSUSE through an OBS repository, Arch Linux through the OGC Arch pacman repository, Nix and NixOS through nixpkgs, and Solus. The Nix entry is the shortest, since the package name is asusctl.

sudo systemctl enable --now asusd.service
sudo systemctl enable --now asus-shutdown.service

Those two commands are for systems such as Fedora or Ultramarine, where you enable and start the services manually after installation. On Debian, service activation may require manual intervention, and on Pop!_OS you need to disable the system76-power GNOME extension and its associated systemd service to prevent power profile conflicts. That last point is a good example of what a general Linux control utility runs into, since another distribution's power management tooling wants to own the same hardware profile.

X11 is officially out of support, and Wayland is the assumed target

The display server section is blunt, and the reason given is developer resources rather than a technical impossibility. X11 is officially unsupported, and technical assistance is not provided for X11 environments due to developer resource constraints and the unmaintained status of X11 itself. There is a path for people who need it, since the graphical application can be compiled with X11 support enabled using cargo build with the feature flag, but operation on unmaintained display servers remains the responsibility of the user. The Makefile reflects the same choice, with an X11 variable that switches the build to the rog-control-center/x11 feature. The practical read for a new user is that the desktop application targets Wayland, and the tray integration depends on it.

Where asusctl is the wrong tool

The first wrong case is a machine that is not an ASUS laptop, where the documentation promises only reduced functionality, and where platform and fan controls need ASUS specific drivers that will not be there. The second is an X11 user, covered above. The third is anyone whose kernel predates the driver work their feature depends on, since Thermal Design Power support simply does not exist before Linux 6.19 and the documentation is explicit that everything older is unsupported, so the failure looks like a missing feature rather than an old kernel. The fourth is a team that wants reproducible hardware behaviour across machines, because a feature that depends on the newest stable kernel is by definition not pinned. The fifth is a system administrator who prefers to avoid a resident D-Bus service with udev-driven activation, since the alternative of configuring the hardware directly through a short-lived tool is simpler to audit, at the cost of losing the automatic responses to power events.

Editorial conclusion

Owners of ASUS gaming laptops who want the fan curve, lighting and GPU switching controls on Linux, and who are on a recent kernel and a Wayland session, are the people asusctl is for, and the fact that the daemon sits under 1 MB of RAM with minimal CPU overhead makes it viable to leave running. It is the wrong tool for a non-ASUS machine, where the documentation says only reduced functionality is available, and it is the wrong tool for an X11 user, since the graphical interface is officially unsupported there and no technical assistance is provided. Check three things before you install it: that your laptop shows one of the expected ASUSTek USB hardware IDs, that your kernel is recent enough for the features you want, since Thermal Design Power support depends on the asus-armoury driver available mainline since Linux 6.19 and anything older is not supported, and that you have the right privileges, since the udev rules initialise the services but on Fedora and Ultramarine you still have to enable asusd.service and asus-shutdown.service yourself. The licence is MPL-2.0, the newest release is 6.5.0 from 2026-09-13, and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. OpenGamingCollective/asusctl on GitHub
3. Project website
4. README
5. Releases