On Sat, Mar 8, 2025 at 5:53 PM Chris Moerz <free...@ny-central.org> wrote: > > Dear LDWG community, > > I recently shared on our last call that I had whipped together a kernel > module that helps battery runtime with more aggressive screen dimming; the > code is now on GitHub, if anyone is interested in checking it out. > > While usual screen savers and desktop environments blank or dim after a > minute, this module allows dimming after just a second of inactivity. > > https://github.com/christian-moerz/framework-kmod > > I have yet to create a port for it. It comes with the kernel code and a > man page to support it. So it's rather bare bones in the documentation > department. > > Currently, the module provides one key functionality - dynamically dimming > the screen when the computer is not used, and turning up brightness again > once activity by the user is detected. > > It keeps track of input signals through evdev(4) and after a set timeout > period, in which no input was detected, reduces screen brightness. > Upon user input, it immediately increases screen brightness back to > previous levels. > > Brightness levels for dimmed and bright state, as well as timeout > settings (the length of time that needs to pass without any input signal > before dimming the screen) can be customized through sysctls. > > Those values can be set differently for when the laptop runs on power > outlet, or on battery. > > I should add, this module only works, if you have drm-kmod loaded (i915kms > on Intel, amdgpu on AMD/Ryzen). I'm making use of their capabilities and > did not re-implement backlight functions. > > I also have started work on a dbus client, that catches vlc's playback > hints - I hope to wire that up through a device node, so it suspends > dimming during playback. > > There is also code for a Xcc based user space program; I could not yet > reliably make that work - if anyone has pointers, I'd be very interested. > > Feedback and input very welcome!
This feels like a wrong direction to me (or maybe I'm misunderstanding the intended usecase). Generally speaking, there are two approaches to manage the screen brightness: 1. From the lower levels, maybe even from within the kernel, like your kmod does. 2. From the upper levels, on the DE plane. Currently KDE Plasma takes the second approach and I think there should be a reason for it. Most likely a DE has more information on what's going on in the system to decide whether to dim the screen or lit it up. Another and more specific reason is to support multiseat configuration - when a computer has two monitors, two sets of input devices and two users simultaneosly running two graphical sessions we don't want an activity of the first one to affect the brightness of the second one. Actually, Plasma already has a FreeBSD backend for brightness control, so dimming the screen after an inactivity period already works for us. Same goes for inhibiting brightness adjustments when a video is being played in a browser or a player application. Moreover, it will turn out that the kmod will fight with the DE to control brightness. What's the added value for the kmod, exactly? Maybe it is intended to be used with more simplistic DEs that do not control brightness themselves?
