Bug 1254337 - Ignores idle-dim setting, dims screen on battery on very short idle interval
Ignores idle-dim setting, dims screen on battery on very short idle interval
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon (Show other bugs)
22
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-17 14:28 EDT by Dimitris
Modified: 2016-02-28 21:03 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-28 07:04:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dimitris 2015-08-17 14:28:05 EDT
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.
Comment 1 Dimitris 2015-08-17 22:57:52 EDT
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
Comment 2 Dimitris 2015-08-19 20:50:42 EDT
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?
Comment 3 Dimitris 2015-08-19 21:15:19 EDT
killing g-s-d (and letting the session(?) restart it) works around this
Comment 4 Dimitris 2015-08-19 21:16:30 EDT
g-s-d is at 3.16.2-1.fc22
Comment 5 Rui Matos 2015-08-25 10:40:56 EDT
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?
Comment 6 Dimitris 2015-08-26 00:51:05 EDT
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).
Comment 7 Bastien Nocera 2015-08-28 07:04:26 EDT
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.
Comment 8 Dimitris 2015-08-28 13:21:05 EDT
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.
Comment 9 W.C. Epperson 2016-02-28 21:03:44 EST
Noting that g-s-d means gnome-settings-daemon may make this more useful, even though closed.

Note You need to log in before you can comment on or make changes to this bug.