Comment 10 for bug 1626651

I just dist-upgraded again, and with 4.8.0-14 my brightness keys work again (bug 1626429). Under i3 (no unity-settings-daemon), I get a tame and immediate reaction:

UDEV [38372.886325] change /devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 (backlight)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0
ID_PATH=pci-0000:00:02.0
ID_PATH_TAG=pci-0000_00_02_0
SEQNUM=2735
SOURCE=hotkey
SUBSYSTEM=backlight
SYSTEMD_WANTS=systemd-backlight@backlight:acpi_video0.service
TAGS=:systemd:
USEC_INITIALIZED=9377712

21:07:21 fork 1298 parent /lib/systemd/systemd-udevd
21:07:21 fork 25614 child /lib/systemd/systemd-udevd
21:07:21 exit 25614 0 0.002 /lib/systemd/systemd-udevd

which matches the one uevent, but there is no userspace helper involved. Brightness change still works as it's hardwired into the driver. This proves that with just kernel and udev rules there is no delay and waste.

Under unity, with unity-settings-daemon, I now confirm the flurry of userspace action. The main pain point is the pkexec in

  pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness

as that starts a full new PAM session, including systemd --user and other expensive stuff. Our /etc/pam.d/polkit-1 pulls in "common-session"; when changing this to "common-session-noninteractive" it becomes muuuch cheaper, but this would again be wrong for cases where we actually do want to run a new session for whatever we run there -- I'm trying to think about cases where this would break. I. e. should pk-exec behave more like "su" or "su -".

It would probably be best to grep the archive for usage of pk-exec, review whether any of it requires an interactive PAM session, and if not switch it to noninteractive.