G-Helper for Linux: an ASUS laptop control panel without Armoury Crate

What the project is and why it exists

The motivation section states it in one line. Since `asusctl` doesn't really care about Ubuntu, the author decided to port most functionality from the original G-Helper for Windows.

That is the whole origin story, and it explains the shape of the project. Armoury Crate is ASUS's own control utility on Windows, and it is large, it installs services, and it phones home. The open source G-Helper by seerge is the community alternative that most Linux-leaning Windows users switched to, and this project is a port of that idea to the Linux side.

The result is described as turning an ASUS ROG, TUF, Flow, Z13, Ally, Zenbook, Vivobook or ProArt into a power user's dream, with the tagline promising fan curves, AURA RGB, MUX, battery limits and GPU mode, and no bloat and no telemetry.

The list of supported families is wide and specific. ROG is the gaming line, TUF is the more mainstream gaming brand, Flow is the small-form-factor desktop, Z13 is the convertible, Ally is the handheld, Zenbook and Vivobook are the consumer laptops and ProArt is the creator line. Covering all of them from one tool means the tool has to handle several generations of ASUS firmware interfaces, which is why the port is a substantial piece of work rather than a thin wrapper.

The application is tested on KDE but other desktop environments should also work. That is a candid statement of the testing position: one desktop is verified, others are expected to work because the app is largely a system tray utility with a settings window rather than something deeply integrated with a specific shell.

The project is GPL-3.0 licensed, written in C#, and the homepage is g-helper-linux.elevatech.xyz. The releases are v1.0.94 from 2026-10-08, v1.0.93 from 2026-09-18 and v1.0.92 from 2026-08-23, and the last push was on 2026-10-20, so it is actively maintained with a steady release rhythm.

One detail in the repository root suggests how the project stays in step with two different upstreams: there is a `.kernel-last-checked` file and a `.upstream-last-checked` file. One tracks the kernel driver interface, which changes and can break the tool, and the other tracks the Windows original.

The feature list, and the parts that go beyond a fan control panel

The features block is long, and it is worth reading it as a map of what an ASUS laptop's firmware exposes.

┌──────────────────────────────────────────────────────────────────┐
│  Performance modes         Silent / Balanced / Turbo            │
│  Custom fan curves         8-point drag-to-edit per fan         │
│  Battery charge limit      Protect longevity (40-100%)          │
│  GPU mode switching        Eco / Standard / Optimized (MUX)     │
│  Power limits              CPU PL1/PL2, Dynamic Boost, temps    │
│  Screen control            Refresh rate, Panel OD, MiniLED      │
│  Keyboard backlight        Brightness + RGB (per-key Aura)      │
│  Display                   Brightness, gamma, multi-backend     │
│  Undervolting              AMD Curve Optimizer, Intel MSR       │
│  CPU boost + EPP           Turbo boost, energy preference       │
│  Audio DSP                 EQ, noise suppression, reverb        │
│  Anime Matrix / Slash      LED matrix display control           │
│  ROG Ally                  Controller mode, handheld config     │
│  FnLock remapping          Custom Fn key bindings               │
│  NumberPad                 Trackpad numpad emulation             │
│  Mouse / peripherals       DPI, polling, Logitech HID++         │
│  System monitor            CPU/GPU/RAM dashboard + tray stats   │
│  Self-updater              In-app update check + changelog      │
│  System tray               Background tray icon + context menu  │
│  Auto-start                XDG autostart .desktop integration   │
└──────────────────────────────────────────────────────────────────┘

The first entries are the expected ones. Performance modes, custom fan curves with eight drag-to-edit points per fan, and a battery charge limit from 40 to 100 percent. The charge limit is the one that matters most day to day, because charging a lithium cell to 100 percent and leaving it there is what shortens its life, and setting a ceiling is the single most useful thing this tool does for battery longevity.

Then the entries that show how much of the laptop is actually reachable. Screen control covers refresh rate, the panel's overdrive and the MiniLED backlight. Display control covers brightness, gamma and multi-backend support. Keyboard backlight covers brightness and per-key AURA RGB.

Undervolting is the entry that shows the project goes past what Armoury Crate offers on Linux, with AMD Curve Optimizer and Intel MSR support. CPU boost and EPP control the turbo behaviour and the energy performance preference. And Audio DSP covers equalisation, noise suppression and reverb, which on ASUS hardware with the right DSP means tuning the speakers the laptop actually has rather than whatever ALSA offers.

The Anime Matrix and Slash entry is the LED matrix display control, the small addressable panel on the lid of some models. It is a display that has no equivalent on a generic Linux laptop and no simple interface at all without vendor tooling, so having it work is one of the more distinctive things the port delivers.

The ROG Ally entry covers controller mode and handheld configuration, which is the gaming handheld where the same controls that matter on a laptop, performance modes, fan curves and battery limit, matter in a different form factor.

The desktop integration entries close the list. FnLock remapping for custom Fn key bindings, trackpad numpad emulation, DPI and polling rate settings with Logitech HID++ support, a system monitor with a CPU, GPU and RAM dashboard plus tray statistics, an in-app self-updater, a system tray icon with a context menu, and XDG autostart integration so the tool comes up with the session.

The entries near the end are the ones a user is most likely to never touch, and their presence is what makes the difference between a fan curve editor and a laptop control panel.

GPU mode switching and the reboot that comes with it

The GPU mode section is the one with the most operational consequence, and it is where the MUX switch appears.

G-Helper manages the ASUS dGPU, the discrete GPU, power state and the MUX switch through four modes.

╔══[ MODES ]═════════════════════════════════════════════════════╗
║                                                                 ║
║  Eco         dGPU powered off (dgpu_disable=1)                 ║
║              Maximum battery life, iGPU only                    ║
║                                                                 ║
║  Standard    Hybrid mode (dgpu_disable=0, MUX=iGPU)            ║
║              dGPU available for offloading, iGPU drives display ║
║                                                                 ║
║  Optimized   Auto-switch based on power source                  ║
║              Eco on battery, Standard on AC power               ║
║                                                                 ║
║  Ultimate    dGPU direct (dgpu_disable=0, MUX=dGPU)            ║
║              Best performance — dGPU drives display directly    ║
║                                                                 ║
╚═════════════════════════════════════════════════════════════════╝

Eco powers the discrete GPU off entirely and runs on the integrated GPU, which is the mode for battery life. Standard is hybrid: the discrete GPU is available for offloading work but the integrated GPU drives the display. Optimized switches automatically based on the power source, Eco on battery and Standard on AC. Ultimate drives the display directly from the discrete GPU, which is the mode for games and for anything that needs the full graphics power on screen.

The underlying mechanism is a pair of settings. `dgpu_disable` controls whether the discrete GPU is powered at all, and `MUX` controls which GPU drives the display panel. Those are separate decisions, and the four modes are the sensible combinations of them. That separation is also why the reboot requirement exists.

The transition table is the part to read before changing anything:

| Transition | Reboot? | Why | |------------|---------|-----| | Eco ↔ Standard | Usually no | May need reboot if GPU driver is active | | Any to Ultimate | Yes | MUX switch is latched, takes effect on reboot | | Ultimate to Any | Yes | MUX switch back to iGPU requires reboot |

The reason is that the MUX switch is latched. The hardware multiplexer is a physical switch in the display path that is set during boot, so changing which GPU drives the panel takes effect only after a restart. Switching between Eco and Standard usually does not need one, because that changes the dGPU power state rather than the display routing, though a reboot may still be needed if the GPU driver is active.

So the practical rule is that Ultimate is a mode you enter deliberately and stay in for a while, and Optimized is the mode that suits a laptop that moves between a desk and a bag. That is a real constraint rather than a software shortcoming, and the table states it plainly enough that nobody will discover it by being surprised.

Lenovo support, and the kernel driver dependency

Alongside the ASUS work there is experimental Lenovo support, and the description is specific about both what it covers and what it depends on.

Experimental Lenovo support for the IdeaPad, Legion, LOQ and Yoga lines covers performance modes, battery conservation, fan monitoring, PPT limits and keyboard backlight, and it works through the mainline `ideapad-laptop` and `lenovo-wmi` kernel drivers, with kernel 6.17 or newer required for the power limits.

Two things about this are worth drawing out.

The first is that the support is described as experimental, which is the correct word for a feature that depends on kernel drivers that are still being developed. The ideapad-laptop driver is a relatively recent addition to the mainline kernel and its interface is still settling, so a user interface built on it inherits that instability. The 6.17 requirement for power limits is a concrete instance of that, and it is better to know the floor than to find out that a control does nothing.

The second is the difference in mechanism between the two vendors. The ASUS side is built on ASUS's own ACPI and firmware interfaces, which the kernel exposes through the asus-wmi driver. The Lenovo side uses the ideapad-laptop driver, which is a generic Linux driver rather than a vendor-specific one. So the Lenovo support is a thinner layer that sits on top of a kernel driver doing the interpretation work, while the ASUS support has to do more of that work itself.

That distinction also explains the scope difference. Lenovo gets performance modes, battery conservation, fan monitoring, PPT limits and keyboard backlight, which is the set of controls the ideapad-laptop driver exposes. There is no GPU MUX mode for Lenovo, no Anime Matrix, no AURA RGB, no audio DSP, because those are ASUS-specific features with no Lenovo equivalent.

The `.kernel-last-checked` file at the repository root fits here. It records when the tool last checked its assumptions about the kernel interface, which is the kind of bookkeeping a project needs when it depends on a driver that is allowed to change underneath it.

There is also experimental support mentioned alongside, and the phrasing distinguishes it as experimental rather than as a separate product. So the project is expanding beyond ASUS in a way that is still being worked out, and the README is careful to label the expansion as such.

Building it, and the shape of the repository

The repository layout is what you would expect from a .NET desktop application that also has to build Linux packages.

There is a `GHelper.Linux.sln` solution file and a `src/` directory for the application, along with `global.json` which pins the .NET SDK version the build expects. There are `build.sh` and `build-appimage.sh` scripts, `format.sh` for formatting, and a `vendor/` directory. The `tests/` directory holds the test suite.

The `install/` directory covers installation for the distributions, and the `nixos/` directory covers NixOS, which is a good sign for a Linux-native project because Nix packaging requires the build to be reproducible and the dependencies to be declared rather than assumed.

There is an `audio-helper/` directory, which is almost certainly a separate helper binary for the audio DSP work, since manipulating equalisation and noise suppression usually means talking to a DSP pipeline that the desktop audio stack does not expose to a normal application.

The `docs/` directory holds the documentation, the `assets/` directory the images and icons, and the `scripts/` directory the supporting scripts. There is a `SECURITY.md` and a `CHANGELOG.md`, and the README links a changelog badge.

The distribution story is visible in the badges. There is a badge counting total binary downloads for a release asset called `ghelper`, and a separate badge counting AppImage downloads for `GHelper-x86_64.AppImage`. So there are at least two packaged forms: a binary archive and a self-contained AppImage, which is the format that works across distributions without a package manager.

The AppImage approach is a deliberate choice for a tool like this, because the hardware interfaces it talks to are vendor-specific and the number of distributions that would need to package it is large. An AppImage sidesteps that, at the cost of not integrating with the distribution's own update mechanism, which is presumably why the self-updater feature exists in the application itself.

The self-updater being built into the app is the detail that closes that loop. A user on a distribution that has no package for the tool can still receive updates, which is what makes an AppImage-first distribution viable for hardware-support software.

Editorial conclusion

Adopt G-Helper Linux if you own a supported ASUS laptop and want the power and thermal controls that Windows users get from the same tool, since the port covers most of the original's functionality. Do not expect it to be a full replacement for Armoury Crate on Linux, since the project's own claim is that it ports most functionality from the original rather than all of it, and check first how your GPU mode changes require a reboot, because the MUX switch is latched and any transition to or from Ultimate means restarting.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. utajum/g-helper-linux on GitHub