Red Hat Bugzilla – Bug 1254337
Ignores idle-dim setting, dims screen on battery on very short idle interval
Last modified: 2016-02-28 21:03:44 EST
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):
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
Screen dims to lowest settings despite option being turned off.
Screen should stay at its set brightness.
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:
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: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
Aug 19 17:48:44 gaspode audit: <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: 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: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
Aug 19 17:48:45 gaspode audit: <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: 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/
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.