Keylightc - A new (Linux) keyboard backlight timeout daemon for Framework 13

Framework Laptop 13 Linux
1

I’ve seen several posts here asking about an automatic timeout for the keyboard backlight when not typing or using the trackpad, similarly to what at least some other laptops support. After not being entirely satisfied with any of the existing solutions for this feature, I decided to write my own, keylightc. Please note that it does require functionality introduced in Linux 6.11 in order to work. So if you’re looking for this functionality and running Linux 6.11 (the just released Ubuntu 24.10 does), please give this a try. If you have any questions, please don’t hesitate to ask here. If you think you’ve found a bug, please open a bug report on the GitLab page.

What is keylightc?
This is a small daemon for Linux with no dependencies on external libraries or desktop environments that will automatically fade in the keyboard backlight on a Framework 13 (it should work on all of the Intel and AMD boards) whenever you press a button on the internal keyboard or use the trackpad. It will then fade it back out a default of 10 seconds later. The backlight timeout, fade duration, and maximum brightness are all configurable with command-line arguments. Information about how to install, configure and run it is in the README on the GitLab project page.

Why should I use this instead of keylightd?
The main reason I wrote this instead of continuing to use keylightd as I had before is because keylightd appears to be unmaintained at this point and depends on quite a number of third-party Rust crates, at least one of which also appears unmaintained and is not packaged for Debian, which transitively makes it difficult to package keylightd itself for Debian and Debian-derived distros. keylightc, on the other hand, has no external dependencies and is therefore very easy to package, which I did in a PPA for Ubuntu.

Why should I use this instead of the input-events LED trigger in Linux 6.11?
If the input-events LED trigger in Linux 6.11 does what you need, then you should absolutely use that. It has several limitations, however, that in my view still make keylightc useful. These include the fact that you can’t configure the maximum brightness, the fact that fading is not supported, that fact that input events on any input device (not just the internal ones) will trigger the backlight, and the fact that any attempt to change the backlight brightness in userspace will disable the trigger.

6 Likes
2

Nice!

Note: You should be able to replace the udev rule which is a bit iffy with

SUBSYSTEM=="backlight", KERNEL=="*:kbd_backlight", TAG+="uaccess"

(Untested)

This does not need to execute external programs and will only grant the currently logged in user the permissions.

3

Thanks, I’ll give that a shot, but I don’t think it will work because keylightc does not run as the currently logged-in user (at least when run using the provided systemd unit), it runs as a systemd dynamic user. I wish there was a better way to grant that user access to the backlight device, but I couldn’t find any.

4

Ah, indeed. I missed that.

Some ideas:

  • Give the daemon root, but drop the privileges after start
  • Let systemd open the file for you with OpenFile=
  • Use a dbus API like org.freedesktop.UPower.KbdBacklight
1 Like
5

The OpenFile= approach does exactly what I want, thanks! It can be done without linking to systemd, maintains the current approach of not having any external dependencies, and doesn’t require creating a static user for the daemon. There will be a new build rolling out in the PPA shortly with the changes.

2 Likes