I'm a little bit out-of-date, do I sume up correctly?
The past:
ACPI in-kernel handles hotkeys and passes it events to ACPI_BACKLIGHT (other drivers didn't work in this way) or userspace
The future:
ACPI in-kernel handles hotkeys and passes it events to userspace, which passes it to $RANDOM_DRIVER
NAME could be:
HANDLEBRIGHTNESS (without the extension KEY or KEYS, maybe it is a sensor or whatever...)
This would allow for a environment agnositic approach, i.e. it works out-of-the box with the TTY, X11, Wayland and the different desktops. The backlight brigthness would be modifiable with the hotkeys always. If GNOME, KDE or XFCE handles the hotkeys itself, it could "inhibit" the HANDLE and uses it own facilities for power-management.
I'm a little bit out-of-date, do I sume up correctly?
The past:
ACPI in-kernel handles hotkeys and passes it events to ACPI_BACKLIGHT (other drivers didn't work in this way) or userspace
The future:
ACPI in-kernel handles hotkeys and passes it events to userspace, which passes it to $RANDOM_DRIVER
If that is correct: Could probably Systemd provide a hook for brightness, similiar to HANDLELIDSWITCH? /wiki.archlinux .org/index. php/Systemd# ACPI_power_ management
see here: https:/
NAME could be:
HANDLEBRIGHTNESS (without the extension KEY or KEYS, maybe it is a sensor or whatever...)
This would allow for a environment agnositic approach, i.e. it works out-of-the box with the TTY, X11, Wayland and the different desktops. The backlight brigthness would be modifiable with the hotkeys always. If GNOME, KDE or XFCE handles the hotkeys itself, it could "inhibit" the HANDLE and uses it own facilities for power-management.