Description of problem: GPM seems to ignore the idle-dim setting and, when on battery, dims the screen on a very short idle interval. Version-Release number of selected component (if applicable): 3.16.1-2.fc22 How reproducible: Every time Steps to Reproduce: 1. Set org.gnome.settings-daemon.plugins.power idle-dim to off 2. Go to battery. 3. Wait around 10-20 seconds 4. Screen dims to its lowest setting Actual results: Screen dims to lowest settings despite option being turned off. Expected results: Screen should stay at its set brightness. Additional info: There is no BIOS setting for dimming the screen when on battery. This is a Thinkpad X200s with a kernel command line that has included, since F19: acpi_osi=Linux thinkpad_acpi.brightness_enable=0 The first was needed to make volume keys work correctly, while the second was needed to make the brightness keys (Fn-PgUp/PgDown) work correctly. This problem was not present from F19 through F21, and seems to be a recent regression in F22 - possibly even kernel 4.1.4 onwards.
A reboot seems to clear this condition, but, after a typical day that includes hibernation and (un)docking, it surfaces again. One thing I missed earlier: Once the symptom appeared, I tried to turn DPMS off (xset -dpms) but it didn't make any difference. Normally my DPMS settings are: DPMS (Energy Star): Standby: 0 Suspend: 0 Off: 0 DPMS is Enabled Monitor is On
I removed the thinkpad_acpi.brightness_enable=0 kernel option since it also doesn't seem to be needed any more, but the behavior is the same. When the display dims (and subsequently brightens as soon as I press a key/move the mouse) I see these in the journal: Aug 19 17:48:44 gaspode pkexec[18081]: pam_unix(polkit-1:session): session opened for user root by (uid=1000) Aug 19 17:48:44 gaspode audit[18081]: <audit-1105> pid=18081 uid=1000 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' Aug 19 17:48:44 gaspode pkexec[18081]: d: Executing command [USER=root] [TTY=unknown] [CWD=/home/d] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 4] Aug 19 17:48:45 gaspode pkexec[18086]: pam_unix(polkit-1:session): session opened for user root by (uid=1000) Aug 19 17:48:45 gaspode audit[18086]: <audit-1105> pid=18086 uid=1000 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' Aug 19 17:48:45 gaspode pkexec[18086]: d: Executing command [USER=root] [TTY=unknown] [CWD=/home/d] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 15] What's causing this?
killing g-s-d (and letting the session(?) restart it) works around this
g-s-d is at 3.16.2-1.fc22
So, this still works correctly if you use an older kernel? Can you check if there are differences under /sys/class/backlight/ between older kernels and the ones where this bug happens?
Haven't been able to reproduce the last couple of days. FWIW, under 4.1.6-200.fc22.x86_64 I have: $ ls -l /sys/class/backlight/ total 0 lrwxrwxrwx. 1 root root 0 Aug 25 21:10 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 lrwxrwxrwx. 1 root root 0 Aug 25 21:17 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight I'll boot an older kernel when I get the chance (oldest installed is 4.1.4-200.fc22 currently).
The display is aggressively dimmed when battery is low. That's completely expected. File a bug against gnome-settings-daemon in the upstream bug tracker at https://bugzilla.gnome.org if you want to discuss this, but I don't think any changes are planned in this regards.
Aside from the fact that I haven't reproduced this, this happened with the battery fully charged - thinkpad had just been undocked after hours on the docking station. Also, killing g-s-d (and observing that a new one was started) fixed the problem.
Noting that g-s-d means gnome-settings-daemon may make this more useful, even though closed.