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?

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

Update to kdelibs-4.10.0-1.fc18.x86_64 (etc), no change in dpms

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.

To be clear, it's kde-workspace that's responsible for the screenlocker and for powerdevil.

kde-workspace-4.10.0-1.fc18.x86_64

Yes, just updated all the kde stuff from kde-fedora's kde-unstable, and rebooted.

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?

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.

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)

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?

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.

OK, good. Can you file a bug with chrome (actually the bugtracker is chromium, I think?) and post a link here?

http://code.google.com/p/chromium/issues/detail?id=174641

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

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.

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

This is happening again with Chrome and Plasma 5.4.