Bug 66367 - Provide handle for ACPI to change backlight brightness, similiar to other power-related ACPI events
Summary: Provide handle for ACPI to change backlight brightness, similiar to other pow...
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium enhancement
Assignee: systemd-bugs
QA Contact: systemd-bugs
Depends on:
Reported: 2013-06-29 15:34 UTC by Peter Weber
Modified: 2014-02-21 17:23 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Peter Weber 2013-06-29 15:34:09 UTC

Add a new handle named like "HandleBrightness" to Systemd and let it take care of the brightness-events, which the kernel emits and signals to userspace. Similiar to "HandleLidSwitch" or "HandleSuspendKey" and configureable via "/etc/systemd/logind.conf". If a desktop-environment like GNOME, KDE or XFCE is able to handle this itself, it should "inhibit" the handle.

I would avoid the postfix "Keys" because such an event could be trigged by other things, like a light-sensor or something similiar.

Currently the handling of events triggered through the backlight-keys is weird on GNU/Linux. If a key-press emits an event, the Linux-Kernel sends the event to the userspace. At the same time, it is possible that the driver ACPI_BACKLIGHT, inside the kernel, reacts on the event and changes the backlight-brightness itself.

This is likely to change in future, instead the events will be only passed to userspace.

As a consequence the brightness-keys won't work on a terminal (TTY) or a plain window-manager based on X11 or Wayland:

This allows for changing the backlight-brigthness out-of-the-box. Especially on a terminal (TTY), but also on any other kind of environmnet on top of X11 or Wayland (i3wm, fluxbox, window-maker...$YOUR_SETUP_HERE).

Thank you
Comment 1 Peter Weber 2013-06-29 15:45:03 UTC
I've to apologize. Instead of the link to freedesktop:
Comment 2 Igor Gnatenko 2013-07-01 08:32:23 UTC
(In reply to comment #1)
> I've to apologize. Instead of the link to freedesktop:
> https://lkml.org/lkml/2013/6/9/161
I think this method in systemd is better.
Comment 3 Lennart Poettering 2013-09-12 18:04:02 UTC
Hmm, I am not convinced we really want this in logind. In contrast to handling of lid switch/power button/suspend button this isn't really part of the system lifecycle. It's an auxiliary thing really... I am tempted to say that gnome-settings-daemon is probably a better place for handling this...
Comment 4 Peter Weber 2013-09-14 18:04:52 UTC
Thanks for your response. I thought about HandleLitSwitch or HandleSuspendKey more in a way of basic integration of power-management, instead of a integration into the system-lifecycle. But it's obvious for me now and makes sense! You're right with this.

Well. Handling the brightness in Systemd looked like an straight solution, till now. The problem with gnome-settings-daemon is, that it requires a desktop-environment at all with the complete stoftware stack from DBUS to X11/Wayland. The changes to the kernel breaks "brigthness-keys" for users of plain TTYs and non-desktop-environements. Also gnome-settings-daemon ignores the events from the keys, if the users operates currently on a TTY and not in GNOME.

Maybe writing and shell-script (with an alias for it) which modifies the content in the responsible files in /sys/... to change the brigthness would be a sufficient solution for me.
Comment 5 Bastien Nocera 2013-10-11 07:20:00 UTC
The brightness changes should be per-output, and there's no way that you can adequately do that in the console, without a display manager of some sort, that would direct the backlight changes to the correct output.

Xorg drivers mostly use libbacklight[1] nowadays for that purpose, ensuring that they do not trample on each other (there might be multiple brightness controls for each output, and none for others).

[1]: http://cgit.freedesktop.org/libbacklight/

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.