← Selected work

g-helper-linux

The control panel ASUS never shipped for Linux: fan curves, RGB, MUX switching, battery limits — no bloat, no telemetry.

Stack: C# / .NET, C, shell, Nix Status: Public Links: github.com/achagani/g-helper-linux

Screenshot from the project's GitHub repo — the full control surface on Linux.

01The problem

ASUS builds some of the most interesting laptops on the market — ROG and TUF gaming machines, the Flow and the Z13, the Ally handheld, Zenbooks with MiniLED panels — and then ships the software that actually controls them, Armoury Crate, for Windows only. On Linux the hardware boots into firmware defaults and stays there. You cannot set a fan curve, cap the charge level, switch the graphics MUX, or touch the per-key RGB without a terminal and a lottery of half-maintained scripts.

On Windows, the open-source G-Helper had already proven the point: a single lightweight tray app can replace the entire Armoury Crate install — hundreds of megabytes of vendor packaging reduced to one binary that does the same job. The Linux side had asusctl, which is fine until you are not on the one distro its maintainers target. The motivation in this repo is blunt about it: the coverage wasn't there, so the port happened.

02The approach

Rather than rewrite the idea from scratch, the project keeps G-Helper's C# codebase and ports its functionality to Linux, shipping as a self-contained binary and an AppImage. The insight that makes the port possible is that Armoury Crate is not magic: it talks to the laptop through kernel sysfs attributes and ACPI/WMI methods exposed by the asus-nb-wmi module. Those interfaces exist on Linux too. Remove the vendor packaging and the same controls are reachable.

What that buys, in one screen: Silent / Balanced / Turbo performance modes, eight-point drag-to-edit fan curves per fan, battery charge limits from 40–100%, four GPU modes (Eco, Standard, Optimized, Ultimate) driving the dGPU power state and MUX switch, CPU power limits (PL1/PL2), refresh-rate and Panel OD control, MiniLED modes, per-key AURA keyboard RGB, undervolting via AMD Curve Optimizer, Fn-key remapping, trackpad numpad emulation, a live system monitor in the tray, and a self-updater. There is even experimental Lenovo support riding the mainline ideapad-laptop kernel drivers.

03Trade-offs

Reverse-engineered interfaces vs. vendor support. Nothing here is blessed by ASUS. Features are gated on kernel version — fans and battery limits from 5.17, MUX switching from 6.1, power limits from 6.2, MiniLED from 6.9 — and 2020–2021 laptops that lack the sysfs attributes need a raw ACPI/WMI mode through debugfs. Every kernel update is a regression risk the community absorbs.

Keeping C# vs. a native rewrite. A native tool would be leaner, but the C# codebase was already proven on Windows; porting it and shipping self-contained runtimes trades a larger binary for speed of development and feature parity.

Direct firmware writes are not risk-free. The MUX switch is latched — switching to Ultimate requires a reboot, and Eco-to-Ultimate round trips can take two. An interrupted write during a MUX switch could leave the machine in a state that needs a CMOS reset. The app discloses this plainly, shows pending modes in the UI, and blocks the dGPU driver with modprobe rules rather than pretending the danger isn't there.

Community-maintained forever. There is no vendor on the hook. The mitigation is the ecosystem itself: open issues, welcome pull requests, and an installer that uninstalls cleanly.

04Under the hood

The runtime contract is small. The asus_nb_wmi and asus_wmi kernel modules must be loaded (they are, by default, on ASUS laptops); everything else flows through sysfs reads and writes. GPU mode changes that need to happen before the display manager starts are staged as pending state and applied by a systemd oneshot service at boot. Eco mode with an active dGPU driver offers a three-way choice — unload now with elevated privileges, block the driver via modprobe rules for next boot, or cancel. Undervolting stays hidden unless the separate ryzen_smu driver is loaded and the CPU is supported: the app refuses to expose a control it cannot verify. The result is what Armoury Crate should have been — one binary, every switch, and a kernel feature matrix that tells you exactly what your machine can do.