facer: an out-of-tree Linux kernel module for Acer RGB and Turbo mode

A WMI driver written from reverse engineering

The project is an unofficial Acer gaming RGB keyboard backlight and Turbo mode Linux kernel module, covering the Acer Predator, Acer Helios and Acer Nitro families. The mechanism is that it extends the current Acer-WMI Linux kernel module to support Acer gaming functions, and the README credits faustus, the equivalent project for Asus machines, as the inspiration.

The provenance matters and the README is unusually direct about it. Acer was not involved in developing this driver, and everything is developed by reverse engineering the official Predator Sense app. The driver interacts with low-level WMI methods that have not been tested on all series, and the warning at the top of the README is to use it at your own risk.

That is a fair summary of what an out-of-tree WMI driver is. WMI is the same management interface Windows uses, and the Linux kernel already ships a driver for the parts of Acer's firmware that are documented. The rest, the fan curves, the performance modes and the keyboard lighting, is only reachable through firmware methods nobody wrote documentation for, so a driver for them has to be reconstructed by watching what the vendor's own application sends.

The repository also has a miniseries on YouTube recorded about the process of creating the project, described as a way to help people contribute to this project or to similar ones that use WMI for communication.

The compatibility table separates implemented from tested

The README answers the question every buyer of a hardware driver asks first, which is whether it will work on my machine, with a table that lists product names against four columns: Turbo Mode implemented, Turbo Mode tested, RGB implemented and RGB tested.

The distinction between implemented and tested is the important part of that table, and it is unusual for a project to make it explicitly. Implemented means the code path exists and the author believes it should work. Tested means the author has run it on that machine. For the Nitro models listed at the top, AN515-45, AN515-55, AN515-56, AN515-57, AN515-58 and AN517-41, the Turbo columns are dashes and both RGB columns are marked Yes. For the Predator PH315-52 and PH315-53, Turbo shows Yes in both the implemented and tested columns and RGB shows Yes as well.

So the pattern is that the RGB backlight is the more broadly supported feature, and Turbo mode is present only on the models where it has been exercised.

The table is also truncated in the visible documentation, so the full model list is longer. That is a practical detail for anyone planning a purchase or a kernel package: the answer to whether this works on your laptop is in a specific cell of that table, not in the feature list at the top.

The build is a plain out-of-tree module Makefile

The build is a conventional kernel module Makefile, and reading it tells you what the module is and what it needs.

The first line declares the object file:

obj-m	:= src/facer.o

which means the module is named facer and lives in the `src` directory. The kernel build directory is derived from the running kernel:

KERNELDIR ?= /lib/modules/$(shell uname -r)/build

and the default target hands control to the kernel build system:

default:
	$(MAKE) -C $(KERNELDIR) M=$(PWD) modules

The `M=$(PWD)` part is what makes this an out-of-tree build, and the `?=` on KERNELDIR means the kernel directory can be overridden on the command line, which is what you need when building for a kernel other than the one you are running.

There is a conditional compile flag for LTS kernels:

ifdef LTS
    ccflags-y := -Dlts
endif

so a build with `make LTS=1` compiles the module with the LTS code path enabled. The `install` target runs the kernel build system's `modules_install`, and `clean` removes the object files, the built module and the intermediate files the kernel build leaves behind.

Secure Boot signing is handled inside the default target

The Makefile deals with Secure Boot rather than leaving it as an exercise for the reader, and that is the difference between a module that builds and a module that loads.

Two paths are named, the machine owner key in its private form and in its DER form:

KEY := /var/lib/shim-signed/mok/MOK.priv
X509 := /var/lib/shim-signed/mok/MOK.der

and the default target signs the built module if both exist:

	if [ -f "$(KEY)" ] && [ -f "$(X509)" ]; then \
		sudo kmodsign sha512 $(KEY) $(X509) src/facer.ko; \
	fi

The conditional means the build does not fail on a system where those files are absent, which is the case on distributions that do not use shim-signed MOK keys, and it signs with sha512, which is the digest Secure Boot expects for module signatures.

This is the step that decides whether the module can be loaded at all on a machine with Secure Boot enabled. An unsigned out-of-tree module is rejected at load time, and the error message usually says nothing about what to do about it, so a build that quietly skips signing produces a module that compiles and then refuses to load.

DKMS handles the version churn, and two module names are cleaned up

Because a kernel module has to be rebuilt for every kernel you boot, the packaging is the part that decides whether this driver stays usable.

The DKMS targets are there for that. `dkmsclean` removes the previously installed versions:

dkmsclean:
	@dkms remove facer/0.1 --all || true
	@dkms remove facer/0.2 --all || true

and the `dkms` target depends on that clean step, then registers and installs the module:

dkms: dkmsclean
	dkms add .
	dkms install -m facer -v 0.2

Note the `|| true` on the removal lines, which is what lets the clean step run on a machine where one of the two versions was never installed. The module name is `facer` and the current version is 0.2, while 0.1 is cleaned up for the upgrade path.

Loading at boot is handled by two small targets, one writing the module name into the modules load directory and one removing it:

onboot:
	echo "facer" > /etc/modules-load.d/facer.conf

The `dkms.conf` file at the repository root is what ties the package to the kernel build, and there is an `ArchLinux-bin-pkg` directory for distribution packaging on Arch.

The userspace side is a set of Python scripts

A kernel module is only half of a hardware feature, and the repository shows the other half clearly. The root holds `facer_rgb.py` and `keyboard.py`, the Python side that talks to the module, along with `refresh.sh` and `git-push.sh`.

The install scripts are separate by design. There is `install.sh` and `uninstall.sh` for the module itself, and `install_service.sh` and `uninstall_service.sh` for a user service, plus `install_openrc.sh` for a machine that uses OpenRC rather than systemd. The separation of a service install from a kernel module install is the right shape, because the module has to be rebuilt for a new kernel while the userland part can simply be reinstalled.

The `src` directory holds the module source, and there is a `.all-contributorsrc` for the contributors list, a `.github` directory for issues and pull requests, and a Discord badge for the project's chat. The `git-push.sh` script is the kind of thing that suggests the author works on the module on one machine and pushes to the repository from there.

Taken together the layout describes a complete out-of-tree driver project: kernel source, build and packaging, a service to expose the features to userspace, and a user-facing Python layer for the keyboard lighting.

GPL-3.0, no releases, and a repository that moves often

The licence is GPL-3.0, with the LICENSE file at the repository root, though the kernel itself is GPL-2 and GPL-3 code is generally not combined with in-tree kernel code.

The repository is not archived and the last push was on 2026-10-19, so the work is current, and the hacktoberfest topic indicates that the project has taken contributions through that route, which is also why the README carries good first issue and help wanted labels on the issue tracker.

There are no GitHub releases, so there is no version to point at. The version that matters for DKMS is the one in the Makefile, where the module is installed as facer version 0.2, and for the kernel build it is the `obj-m` declaration and the object file path.

For an adopter, the practical checklist is short. Confirm your model and the feature you want in the compatibility table, build with the kernel headers for the kernel you are running, sign the module if Secure Boot is on, install the service and the Python layer, and expect to repeat the build after every kernel update. The README's warning about untested WMI methods on some series is the part to keep in mind, because the module talks to firmware that the vendor never documented and that may change with a BIOS update.

Editorial conclusion

facer fits an Acer gaming laptop owner on Linux who wants the per-key lighting and the performance mode their machine can do but the stock driver does not expose, and who is willing to run a reverse engineered driver and rebuild it on every kernel update. It is the wrong choice if the hardware already works, or if Secure Boot signing or a stock kernel is a requirement you cannot bend. Verify first that your exact model appears in the compatibility table with the feature you want marked as tested, and read the warning in the README before you build it.

Frequently asked questions

Official sources

1. Issues
2. JafarAkhondali/acer-predator-turbo-and-rgb-keyboard-linux-module on GitHub
3. License: GPL-3.0
4. README