cpupower-gui is a graphical front end for the knobs cpupower already exposes

The same knobs as cpupower, with a window

cpupower-gui is described as a program designed to let you change the frequency limits of your CPU and its governor, with functionality similar to cpupower, and the readme makes the comparison explicit. That is the honest summary: this is a graphical front end over the same kernel interfaces the command line tool uses, not a different approach to power management. The topics attached to the repository, gnome, gtk3, gui, linux and python3, put the implementation in a GTK 3 application written in Python, which is a combination that is easy to install on most desktop distributions and easy to read if you want to change it. The project description says the same thing in different words, that it is a graphical program used to change the scaling frequency limits of the CPU. The practical appeal is not that it does something cpupower cannot, but that the per-CPU structure of the scaling driver, which is a directory of files under sysfs with a different one for each processor and a separate online switch, is flattened into a window with a processor drop-down, which is a real saving for anyone who has looked for the right file at least once.

A processor list, sliders, a governor and an online switch

The graphical flow is short. You select the CPU from the drop-down menu, adjust the sliders for the frequency range, and click Apply. The governor is changed from a second drop-down, and there is a switch labelled All CPUs, drawn as a square icon in the top left corner, that applies the same settings to every processor. Each CPU also has an Online checkbox next to the drop-down that enables or disables that specific processor, and the checkbox initially shows the current state, whether the CPU is online or offline. There is a subtlety in the interface that is worth knowing about, because it is the kind of thing that looks like a bug. If the checkbox is greyed out, that means the CPU is not allowed to go offline, which is a driver level restriction rather than a fault in the program. The readme also notes that if the Intel P-state driver is used and energy preferences are available, a drop-down for them appears, which is the one place where the interface offers something the plain scaling interface does not.

Two profiles, and where they differ under the hood

The two governor profiles are the feature that turns the program into a daily tool rather than a tuning panel. The performance profile sets the governor for all CPUs to performance, which is the obvious behaviour and the one you want when a compile is running. The balanced profile is the interesting one, because it does something conditional. It sets the governor to powersave if that governor is available, and otherwise to a scaling governor such as ondemand or schedutil. The distinction matters because those are not equivalent. A machine that only offers the scaling governors is left with a driver that scales frequency on demand, and a machine that exposes powersave is parked until something asks for more. The profiles can be selected from the desktop icon or from the actions in the tray icon, which is the route that matters for a laptop, since the tray is always there. The interface is also described as mobile friendly and adapting to the window size, with a screenshot from a PinePhone running phosh on Mobian as the example, which is a good sign for a program that has to work on a small touchscreen as well as on a desktop.

The command line is a first class interface

The command line support is not an afterthought, and the help output shows why. There are subcommands for configuration, frequency, energy, profile and online or offline, each with a short alias, and the usage line shows the abbreviations in square brackets so you can type the short form. There are also top-level flags for the balanced and performance profiles, and a flag to start the graphical program from the gapplication service, which is how it integrates with a desktop's application launcher.

$ cpupower-gui -h
usage: cpupower-gui [-h] [--version] [-b] [-p] [--gapplication-service]
                    {[co]nfig, [freq]uency, [ene]rgy, [pr]ofile, [off]line,
                    [on]line} ...

The config subcommand applies the default configuration from the configuration files, and running it prints what it did per processor, the minimum and maximum frequency in megahertz, the governor and the online state, which is a useful confirmation that a change landed. The frequency subcommand queries or sets the minimum and maximum frequencies of one or more CPUs, and the energy subcommand is noted as system dependent. The gapplication route lets a script or a desktop menu item switch profile, since the application actions are exposed as a service.

# Switch to balanced profile
gapplication action org.rnd2.cpupower_gui Balanced

Packaged in five distribution families, with one caveat

The packaging section is the longest part of the readme, and the reason is that a program like this gets packaged by whoever maintains each distribution. Arch Linux and its derivatives have it in the AUR, with a stable package and a git package built from this repository. blackPanther OS installs it after updating the repositories. Debian and Ubuntu have it in the software manager and in the terminal, with a warning that the version in those repositories is way out of date, and a pointer to the GitHub releases page for a deb of the latest version. Fedora and openSUSE get it from the openSUSE Build Service repository, with the commands to add the repository for a given Fedora release and for openSUSE Tumbleweed, and the note that the binaries there are built from the latest git revision. OpenMandriva has it in its official repository. The repology badge in the readme tracks the packaged versions across all of them, which is a quick way to see whether your distribution is current without checking five pages.

Meson, translations and a flatpak style desktop file

The build system is meson, with a build configuration and an options file at the top level, a build-aux directory holding the auxiliary scripts, and a package source directory holding the application code. There is a translation directory, which tells you the interface is localised, and a data directory for its resources. The desktop entry point is a JSON file named after the application identifier, which is the format a gapplication service definition uses, and the readme's gapplication examples use the same identifier, so the desktop integration and the command line are wired to the same service actions. There is also a pre-commit configuration, a contributing guide, an authors file and a copyleft licence file. Two things stand out for anyone picking the project up. The build is not a Python packaging exercise, it is a meson build with translations and desktop integration, which is the right shape for a program that wants to be a first class desktop application. And the localisation work is the kind of thing that turns a small utility into something a distribution can actually ship.

Editorial conclusion

cpupower-gui earns its place for a laptop user who wants to switch between a quiet and a fast profile without learning the sysfs layout of the scaling driver, since the graphical path hides the per-CPU directories and the per-CPU online switch, and the two profile actions are one click or one command. It is the wrong tool if you want something more capable than the standard driver interface, since it exposes the same knobs as the command line tool it resembles, and it is the wrong choice on a distribution whose packaged version is old, which the readme warns about for Debian and Ubuntu. Verify three things before you install it: which version your distribution ships, because the readme says the Debian and Ubuntu packages are way out of date and offers a newer deb on the releases page instead, that the driver on your machine exposes what the interface expects, since the energy preference drop-down only appears when the Intel P-state driver is in use, and that you can give the program the privileges it needs, since writing scaling limits and governors is a privileged operation. The licence is GPL-3.0, the last push was on 2026-05-21, and the newest tagged release is v1.0.0 from 2020-11-06.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. vagnum08/cpupower-gui on GitHub