|Summary:||battery mon screen dim stopped working|
|Product:||[Frameworks and Libraries] solid||Reporter:||Neal Becker <ndbecker2>|
|Component:||powermanagement||Assignee:||Oliver Henshaw <oliver.henshaw>|
|Severity:||major||CC:||cfeck, jnerin, joe.yasi, KDE, oliver.henshaw, rdieter|
|Latest Commit:||http://commits.kde.org/kde-workspace/8622cfc9cf539326ca6703a39062b13194d1e26a||Version Fixed In:||4.10.1|
Description Neal Becker 2013-02-01 14:23:21 UTC
After updating to kdelibs-4.9.98-1.fc18.x86_64 from kde-unstable,kde-testing repos, screen will no longer dim after 10 min. In batterymon, I have Switch off after 10 min as I always had before. It no longer has any effect. Screen does not switch off. Reproducible: Always Steps to Reproduce: 1. walk away 2. 3.
Comment 1 Oliver Henshaw 2013-02-02 18:02:22 UTC
I assume this is http://lists.fedoraproject.org/pipermail/kde/2013-January/012202.html and followups so you're talking about DPMS power saving (turning off the screen) and not about dimming the backlight, right? A few questions to help me understand what's going on: - The list message says you have the screenlocker set to activate after 10 minutes. Does the screen actually lock after 10 minutes away or have you been locking the screen yourself? - Just to check, what version of kde-workspace do you have? - what version did you have before the update? - Do you have anything interesting in the logs? Specifically, what's the output of 'grep -i powerdevil .xsession-errors' - What's the output of 'xset -q | tail -4' - What's the output from running the command 'sleep 590; xset -q | tail -4; sleep 30; xset -q | tail -4' and leaving the computer for at least 11 minutes?
Comment 2 Neal Becker 2013-02-02 18:28:41 UTC
Thank you for helping with this 0. Yes, I'm talking about DPMS power saving not turning off the screen 1. I had screenlocker set to activate after 10 minutes. It does lock 2. I turned off screen locker, and then the screen still does not turn off 3. I had 4.9.97 before updating to 4.9.98. Looking at yum.log, I think it's very likely that this update broke DPMS. 4. grep -i powerdevil .xsession-errors kded(993) PowerDevilUPowerBackend::setBrightness: org.kde.powerdevil.backlighthelper.setbrightness failed kded(993) PowerDevilUPowerBackend::brightness: org.kde.powerdevil.backlighthelper.brightness failed 5. xset -q | tail -4 DPMS (Energy Star): Standby: 600 Suspend: 900 Off: 1200 DPMS is Enabled Monitor is On 6. sleep 590; xset -q | tail -4; sleep 30; xset -q | tail -4 DPMS (Energy Star): Standby: 600 Suspend: 900 Off: 1200 DPMS is Enabled Monitor is On DPMS (Energy Star): Standby: 600 Suspend: 900 Off: 1200 DPMS is Enabled Monitor is On
Comment 3 Neal Becker 2013-02-02 18:52:27 UTC
Update to kdelibs-4.10.0-1.fc18.x86_64 (etc), no change in dpms
Comment 4 Oliver Henshaw 2013-02-02 18:56:40 UTC
Hmm, nothing suspicious there. What's the exact version of kde-workspace and did you log out and in again after updating? I can't think of any way that would cause a problem like this, but better safe than sorry. And do you have the same problem if you change the powerdevil "Switch off time" to another value? Can you also report the last few lines of 'xset -q' a few seconds before and a few seconds after the screen should turn off? e.g. 'sleep 55; xset -q | tail -4; sleep 10; xset -q | tail -4' if you set it to one minute.
Comment 5 Oliver Henshaw 2013-02-02 18:57:27 UTC
To be clear, it's kde-workspace that's responsible for the screenlocker and for powerdevil.
Comment 6 Neal Becker 2013-02-02 18:59:25 UTC
kde-workspace-4.10.0-1.fc18.x86_64 Yes, just updated all the kde stuff from kde-fedora's kde-unstable, and rebooted.
Comment 7 Oliver Henshaw 2013-02-02 19:35:03 UTC
Another thing to try: if you set the screen to turn off one minute before the screen locks does the screen still lock at the expected time?
Comment 8 Neal Becker 2013-02-02 19:55:32 UTC
I created a new test user. Logged in as that user. Only thing I changed was set screen to turn off after 5 min. It seems it did! Then I decided to remove all kde settings from MY account. mv ~/.kde ~/.kde.save Login. Only things I changed from defaults were, screen to turn off after 5 minutes, startup with empty desktop. Setup a few favorite icons, 4 desktops. screen does NOT turn off after 5 minutes. apps running include google-chrome-unstable, emacs, and knode.
Comment 9 Neal Becker 2013-02-02 21:15:58 UTC
Partially solved? I've tested several times. If google-chrome is runing, screen will not turn off. If google-chrome is not running, screen does blank. I've had chrome running all the time for a couple of years and never saw this before. chrome is Version 25.0.1364.58 beta (google-chrome-beta)
Comment 10 Oliver Henshaw 2013-02-04 18:13:56 UTC
I haven't been able to reproduce this on F17 with google-chrome-beta-25.0.1364.58-179520.x86_64 Can you see whether this happens (maybe with the test user) just with chrome running or is it some flash or video or something on a web page that causes chrome to do this?
Comment 11 Neal Becker 2013-02-05 14:43:24 UTC
I found it! I removed .config/google-chrome, starting with a clean chrome. If chrome has gmail open, screen will not blank. If I close gmail tab, leaving chrome running but showing e.g., google-calendar, screen does blank. There! I just retested again. 100% repeatable.
Comment 12 Oliver Henshaw 2013-02-06 14:09:08 UTC
OK, good. Can you file a bug with chrome (actually the bugtracker is chromium, I think?) and post a link here?
Comment 13 Neal Becker 2013-02-06 15:07:31 UTC
Comment 14 Jorge Nerín 2013-02-13 10:17:51 UTC
Question, has there been any change that prevents DPMS poweroff when chrome calls the dbus api to inhibit powermanagement?: method call sender=:1.6056 -> dest=org.freedesktop.PowerManagement serial=2 path=/org/freedesktop/PowerManagement/Inhibit; interface=org.freedesktop.PowerManagement.Inhibit; member=Inhibit string "chromium-browser" string "Uploading data." signal sender=:1.2 -> dest=(null destination) serial=42203 path=/org/freedesktop/PowerManagement/Inhibit; interface=org.freedesktop.PowerManagement.Inhibit; member=HasInhibitChanged boolean true signal sender=:1.2 -> dest=(null destination) serial=42204 path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement.Inhibit; member=HasInhibitChanged boolean true method call sender=:1.6056 -> dest=org.freedesktop.PowerManagement serial=3 path=/org/freedesktop/PowerManagement/Inhibit; interface=org.freedesktop.PowerManagement.Inhibit; member=UnInhibit uint32 5859 signal sender=:1.2 -> dest=(null destination) serial=42207 path=/org/freedesktop/PowerManagement/Inhibit; interface=org.freedesktop.PowerManagement.Inhibit; member=HasInhibitChanged boolean false signal sender=:1.2 -> dest=(null destination) serial=42208 path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement.Inhibit; member=HasInhibitChanged boolean false
Comment 15 Oliver Henshaw 2013-02-15 18:36:51 UTC
This is indeed a kde bug. The problem is that powerdevil restarts the DPMS timer every time the inhibitions change - so that the frequent short-lived PowerManagement inhibitions indefinitely delay screen blanking. Note that this isn't new behaviour, I think it dates back to 4.8 - perhaps inhibiting powermanagement while syncing is new behaviour in chrome? We only really want to restart the DPMS timer when display power management inhibitions stop. This should hopefully be fairly easily fixed in 4.10.1. In the slightly longer term, I've been wanting to change the implementation of screen power saving in a way that would make this a non-issue but there's no reason not to fix this ASAP.
Comment 16 Oliver Henshaw 2013-02-26 17:57:45 UTC
Git commit 8622cfc9cf539326ca6703a39062b13194d1e26a by Oliver Henshaw. Committed on 22/02/2013 at 18:51. Pushed by oliverhenshaw into branch 'KDE/4.10'. Cache whether screen powersaving is inhibited DPMSAction disables or enables DPMS (and sets timeouts) as appropriate when inhibition policy changes. As setting DPMS timeouts resets the timer this will delay the time at which DPMS activates. But this is only necessary if the ChangeScreenSettings inhibition changed. Chrome sets short-lived InterruptSession inhibitions while uploading data. This has the effect of indefinitely delaying DPMS activation. So cache the current screen inhibition state and only decide whether to enable or disable DPMS if the new state is different. REVIEW: 109126 M +11 -1 powerdevil/daemon/actions/dpms/powerdevildpmsaction.cpp M +1 -0 powerdevil/daemon/actions/dpms/powerdevildpmsaction.h http://commits.kde.org/kde-workspace/8622cfc9cf539326ca6703a39062b13194d1e26a
Comment 17 Joseph Yasi 2015-11-07 03:54:09 UTC
This is happening again with Chrome and Plasma 5.4.