TUXEDO Control Center puts fan, CPU and profile control on TUXEDO laptops

A vendor utility for one specific family of laptops

The TUXEDO Control Center, short TCC, gives TUXEDO laptop users full control over their hardware, CPU cores, fan speed and more. The project description in the repository says the same thing more plainly: a tool to help you control performance, energy, fan and comfort settings on TUXEDO laptops.

That audience is narrow and the project is honest about it. This is not a general Linux power management tool that happens to support one brand, it is the manufacturer's own control panel, open sourced. The screenshots in the repository show a system monitor, a dark theme, a tools page, battery and mains views, a profiles page, profile settings and an about panel, in both English and German.

Because it is the vendor's utility, the surrounding infrastructure is part of the product. The project points at a press release with English and German versions, at info pages in both languages, and at a documentation page for how to add TUXEDO's software package sources, which is where pre-built packages are published.

The licence is GPL-3.0, the primary language is TypeScript, the default branch is master, the last push was on 2026-09-23, and the repository publishes no GitHub releases. The application version in the package metadata is 3.0.10.

Three processes: Angular, Electron and a Node daemon

The project structure in the README explains the architecture better than any description would, and it is worth reading line by line because it explains why the installation has the shape it has.

tuxedo-control-center
|  README.md
|--src
|  |--ng-app            Angular GUI (aka electron renderer)
|  |--e-app             Electron main
|  |--service-app       Daemon part (Node 24)
|  |--common            Common shared sources
|  |  |--classes
|  |  |--models
|  |--dist-data         Data needed for packaging
|--build-src            Source used for building

So there is an Angular application that acts as the Electron renderer, an Electron main process, and a separate daemon written for Node 24, with a common directory holding the shared classes and models that both sides use.

The daemon is not incidental. A GUI that has to change fan speed needs to talk to the hardware, and on Linux that means a privileged service, not a desktop application. That is why the install instructions involve systemd units and a D-Bus policy file, and why the npm scripts include a way to start the daemon directly with sudo.

The dist-data directory holds the files needed for packaging, which is where the systemd service files and the D-Bus configuration live, and build-src holds the sources used for building, including the version increment script.

Fan control depends on tuxedo-drivers, not on the app

The README contains one short sentence that decides whether this project will do anything for you: TCC depends on tuxedo-drivers for some core functionality like fan control.

That is the honest boundary of the tool. The application is a front end, and the actual control of the hardware comes from the kernel side of the stack. Without tuxedo-drivers installed and working, the interface can still be launched, and you can still look at things like the system monitor, but the part everyone wants, the fan curves and the CPU core configuration, has nothing underneath it.

This is why the project is not a general system tuning tool. A tool that sets fan speed on a specific laptop family needs to know that family's EC and firmware conventions, and that knowledge lives in the driver package rather than in a TypeScript application.

The dependency also shapes the maintenance story. When a user reports that the fans do not respond, the first question is whether tuxedo-drivers is present and current, and the second is whether the daemon is running at all, since the GUI talks to the daemon rather than to the hardware directly.

For anyone evaluating the project, the correct first check is therefore not the Electron app but the driver package, and the documentation's own warning is the place to start.

Building from source on Debian and Ubuntu

The development setup is documented as a numbered list, and the first step installs the build dependencies, including the Node.js 24 toolchain from the NodeSource setup script:

    curl -sL https://deb.nodesource.com/setup_24.x | sudo -E bash -

    sudo apt install -y git gcc g++ make nodejs libudev-dev rpm

The listed packages explain the shape of the project: gcc and g++ and make because there is a native component, built with binding.gyp, libudev-dev for device access, and rpm because the release build produces both deb and rpm packages.

The second step clones the repository and installs the dependencies:

    git clone https://github.com/tuxedocomputers/tuxedo-control-center

    cd tuxedo-control-center

    npm clean-install

Two details in that command are worth noting. It is clean-install rather than install, so the lockfile is honoured exactly, which matters for a repository with a native module and patched dependencies. And the postinstall script in the package metadata runs electron-builder install-app-deps and then patch-package, so the native module is built for Electron and the patches in the patches/ directory are applied automatically.

The project also has a docker/ directory, which suggests a containerised path exists, though the README does not describe it in the visible text.

systemd units and a D-Bus policy for the daemon

The third step of the development setup is the part that makes the daemon usable, and it is a manual sequence with seven sub-steps.

First you copy the tccd.service and tccd-sleep.service files from src/dist-data into /etc/systemd/system/. Then you run npm run build in the project folder, which produces the service binary. Then you edit the tccd.service file, the exec start and stop lines, so they point at the development build path, the dist/tuxedo-control-center/data/service/tccd location rather than the installed one.

Next you copy the com.tuxedocomputers.tccd.conf file into /usr/share/dbus-1/system.d/. That is the D-Bus system policy that lets the unprivileged desktop session talk to the privileged daemon, and it is the piece that makes the Electron application able to request fan changes without running as root.

Only then do the two systemctl commands, one to start the service with systemctl start tccd and one to enable it plus the sleep service for autostart with systemctl enable tccd tccd-sleep, and finally npm run start in the project folder to launch the graphical interface.

The two units, tccd and tccd-sleep, are the mechanism for the daemon surviving sleep and resume, which is the same problem the Bonjour Sleep Proxy solves elsewhere. The README does not document how to undo these manual steps, so a developer should keep track of the system directories they touched.

The npm scripts, the native module and the version bump

The package scripts are the working vocabulary of the project, and the README lists them in a table.

There is build-release with autoversion, which builds and packages the release deb and rpm, and pack-prod and pack-debug with an all, deb or rpm target. There is build-prod and build-debug, each described as building the service, the Electron app and the Angular app, and start and start-watch, where the watch variant reloads automatically on changes to the Angular directory. There is also a tests script, which corresponds to the karma.conf.js in the repository.

Looking at the actual script bodies in the package metadata shows how the build is composed. build-prod is a sequence, run-s clean build-electron build-native-prod build-service-prod build-ng-prod copy-files, and build-ng-prod runs the Angular compiler with aot true and optimisation true for the release configuration. build-electron is a plain tsc invocation over the e-app project, so the Electron main process is TypeScript compiled to JavaScript, while the native piece is a separate step, and the presence of binding.gyp and patches/ in the tree tells you that piece is a native module with patched dependencies.

Version bumps are scripted too. The ver script runs build-src/inc-version.sh, and there are inc-version-patch, inc-version-minor and inc-version-major scripts that bump the version in the root package and in the src package together, so the nested package does not drift out of step with the application version.

For debugging, the README says the Electron main and renderer debugging is configured for Visual Studio Code in the .vscode/launch.json file, and there is a start-tccd-debug script that runs the service with source maps enabled under sudo.

Open source, but the hardware half is not

The licensing and maintenance picture is a mixed one, and it is worth being clear about.

The code is GPL-3.0, with the COPYING file at the root of the repository, which is consistent with a project whose goal is to let users and packagers see exactly what runs on their machine. For a distribution that wants to ship the tool, the copyleft obligations are the usual ones for a GPL-3.0 program.

The maintenance signals are modest but recent. The last push was on 2026-09-23, the application version is 3.0.10, and the repository carries a CHANGELOG.md and a FEATURES.md alongside the COPYING file. There are no GitHub releases, so the packaged versions on the vendor's package sources are the artefact users actually install, and the repository is where the source for those packages lives.

The limitation that follows from all of this is simple. TUXEDO Control Center is useful on a TUXEDO machine with tuxedo-drivers installed and nothing else. On a different laptop the fan and CPU controls have no backend, and the rest of the application, the monitor, the battery view, the profiles, is generic enough that other tools will do that job.

The build is also a desktop application rather than a service you deploy once and forget. It has a native module, a patched dependency tree, systemd units and a D-Bus policy, and the development path assumes you have root on the machine, which is fine for a laptop owner and heavy for a server.

Editorial conclusion

TUXEDO Control Center is the right choice for a TUXEDO laptop owner who wants to tune fans and CPU behaviour and switch profiles, and it is the wrong tool for any other Linux machine, since the hardware control depends on tuxedo-drivers and on the vendor's own service. Before building from source, check that tuxedo-drivers is installed and that the tccd service starts, and decide whether you need the daemon at all, since the packaged release already installs it.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. tuxedocomputers/tuxedo-control-center on GitHub