DPMS timeout restored incorrectly on login

Lure and abattoir both have indicated that they experience this too.

Similar report also on Gnome - see bug 66277

Similar report but after resume: bug 65734

I have the exact same issue on Kubuntu Edgy also...

When I select 15minutes, the value is always 5 hours after login.

I'm seeing this problem on Edgy. If I set the Offtime to 30 minutes, it reverts to 5 hours. If I set the Offtime to 1 minute, it reverts to 1 hour.

Attached fix went into KDE svn yesterday.

Good. :)

Sorry, but the patch doesn't fix this problem. Although it fixes the bug about not saving monitor power off setting (bug #46585 https://launchpad.net/bugs/46585 and KDE bug tracker bug #128696 https://bugs.kde.org/show_bug.cgi?id=128696 ).

I made a clean install of Kubuntu 6.10, applied the fix and this bug still persists. The root of this problem is that KDE for some reason uses wrong time units, it misinterprets seconds for minutes. After applying the patch if I set monitor to go off after 2 minutes, displayconfigrc had line "dpmsSeconds=120", command "xset q" returned value 120 and monitor went off after 2 mins. However after logout&login system settings showed monitor to go off after 2 hours and "xset q" returned 7200.

However there is a workaround. I edited manually the dpmsSeconds value in displayconfigrc to 2 and after new login system settings show that monitor should go off after 2 mins, "xset q" returns 120 and my monitor actually went off after 2 minutes. But there is a catch.

Before KDE is fully up and running it still seems to interpret the dpmsSeconds value in displayconfigrc as seconds. So if the dpmsSeconds value is small enough, monitor goes off after few seconds of inactivity. Basically this means that your desktop starts with a blank screen. I was able to reproduce this with dpmsSeconds values 5 and smaller. If the value was bigger (for example 10) the seconds to minutes conversion happened before monitor went off and it stayed on until as many minutes had passed as was the value of dpmsSeconds.

How to fix this? Quick and dirty hack would be dividing the value stored in displayconfigrc by 60 (this causes blank start screen problem with small power off times), but the right way would be to find out where and why this seconds=minutes misinterpretation happens and use only seconds (or only minutes).

A few weeks ago I spent some time trying to get to the bottom of this problem. It appears that guidance is working fine and is setting the dpms values correctly during login. But once the login sequence is complete xset reports wrong values. I've checked that displayconfig-restore is using the correct command for xset. I can only conclude that some other process is changing the dpms settings during login. I'll have to keep looking...

thanks for your effort H Jalonen .

Simon: Lure & I also spent some time investigating this prior to Edgy's release, and we arrived at the same conclusion as you -- guidance is behaving properly, but something else in the login sequence is changing the DPMS timeout.

In addition, I tried trapping xset with my own dummy binary, and displayconfig-restore is the only thing using xset. So, this other culprit must be using a different mechanism to reset DPMS timeout.

On Saturday 11 November 2006 17:43, John Dong wrote:
> Simon: Lure & I also spent some time investigating this prior to Edgy's
> release, and we arrived at the same conclusion as you -- guidance is
> behaving properly, but something else in the login sequence is changing
> the DPMS timeout.
>
>
> In addition, I tried trapping xset with my own dummy binary, and
> displayconfig-restore is the only thing using xset. So, this other culprit
> must be using a different mechanism to reset DPMS timeout.

Looking at other bugreports, GNOME users report the same problem. Something
fishy is going on there.
--
sebas

 http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I have not seen anyone assume that all the citizens of New York are guilty of
murder, violence, robbery, perjury, or writing proprietary software. -
Richard M. Stallman

Thanks for the info John. My next step would be to 'wedge' the xset binary with a something dummy. At least I don't have to bother now. I wonder which API xset uses for setting DPMS.... mmm.

Is this driver related in some way? I'm using the closed source nVidia driver.

I already did that, Simon... only thing that uses xset is
displayconfig-restore, and it does call it with correct values.

I am using closed-source fglrx.

On 11/11/06, Simon Edwards <email address hidden> wrote:
>
> Thanks for the info John. My next step would be to 'wedge' the xset
> binary with a something dummy. At least I don't have to bother now. I
> wonder which API xset uses for setting DPMS.... mmm.
>
> Is this driver related in some way? I'm using the closed source nVidia
> driver.
>
> --
> DPMS timeout restored incorrectly on login
> https://launchpad.net/bugs/65791
>

Kubuntu edgy here shows this problem. I'm using the nVidia closed source driver.

Just tried the nv driver. Same problem.

A horrific workaround I'm currently using is a python script in the background that checks DPMS periodically and resets it if it's an unexpected value....

jdong@jdong-laptop:~$ cat /usr/local/bin/dpmswatch
#!/usr/bin/python
import os
import time
while True:
  st=os.popen('xset -q | grep Standby').read()[:-1].strip()
  if st != "Standby: 120 Suspend: 120 Off: 120":
    print "Bad DPMS:",st
    os.system('xset dpms 120 120 120')
  time.sleep(10)

jdong@jdong-laptop:~$ cat .kde/Autostart/displayconfig-restore
#!/bin/bash
python /usr/local/bin/dpmswatch &

John Dong wrote:
> A horrific workaround I'm currently using is a python script in the
> background that checks DPMS periodically and resets it if it's an
> unexpected value....

It sure is brute force, but it works for me!

An easier on the system workaround is:

ln -s /usr/bin/displayconfig-restore ~/.kde/Autostart/displayconfig-restore

It uses the system settings value (the real one, not multiplied by 60 as system settings insists on displaying).

That actually doesn't work on my system -- it restores the DPMS timeout too early and it gets overwritten again. Previously I had a sleep 20 && displayconfig-restore and similar lines for 20,30,and 40 second delays, but even then when my system is under IO load and logging in, it would not work.

Exactly. So it's _not_ a bug in guidance. Can someone who suffers from this problem just look up the real problem? Replacing xset with some debugging trap would help _a_lot_ here.

This (trapping xset) has already been done.
https://launchpad.net/distros/ubuntu/+source/kde-guidance/+bug/65791/comments/10
It seems what is changing the setting is not using xset.

Found the culprit in kdebase. This patch makes DPMS timeouts accurate again. I will upload some testing packages soon.

--- kdebase-3.5.5.orig/kcontrol/energy/energy.cpp
+++ kdebase-3.5.5/kcontrol/energy/energy.cpp
@@ -340,7 +340,7 @@
     if (hasDPMS) {
         if (enable) {
             DPMSEnable(dpy);
- DPMSSetTimeouts(dpy, 60*standby, 60*suspend, 60*off);
+// DPMSSetTimeouts(dpy, 60*standby, 60*suspend, 60*off);
         } else
             DPMSDisable(dpy);
     } else

wrong status

Testing packages available by putting the following in your sources.list:

"deb http://buntudot.org/people/~jdong/kdebase/ ./"

Package built from Edgy kdebase with that one patch above.

Hi John, greetings for nailing the bug! I wouldn't have the time not even to try.

By taking a look on the code, it seems the multiply by 60 thing crept in when they added the capability to get the system settings. The hardwired constants DFLT_STANDBY, DFLT_SUSPEND and DFLT_OFF are meant to be minutes, so there are those "60 *" to make then seconds. But the system settings are already in seconds! So, my fix would be:
 - make those constants mean seconds (multiply then by 60)
 - take out those "60 *" and let it set the timeouts

What do you think?

Here is my patch.

--- energy.cpp~ 2006-12-05 23:12:07.000000000 -0200
+++ energy.cpp 2006-12-05 23:15:14.000000000 -0200
@@ -77,8 +77,8 @@
 #endif

 static const int DFLT_STANDBY = 0;
-static const int DFLT_SUSPEND = 30;
-static const int DFLT_OFF = 60;
+static const int DFLT_SUSPEND = 1800;
+static const int DFLT_OFF = 3600;

 /**** DLL Interface ****/
@@ -340,7 +340,7 @@
     if (hasDPMS) {
         if (enable) {
             DPMSEnable(dpy);
- DPMSSetTimeouts(dpy, 60*standby, 60*suspend, 60*off);
+ DPMSSetTimeouts(dpy, standby, suspend, off);
         } else
             DPMSDisable(dpy);
     } else

There must be a more complete way of just simply castrating kdebase of kenergy altogether, since its functionality is all done by guidance, and heck kenergy isn't even user-visible in any fashion.

I'd rather see that happen than any of the workarounds posted this far.

I still have an inclination towards my method as a workaround if the ideal solution takes too long because I don't think kenergy should be calling DPMSSetTimeouts at all; in Kubuntu it's none of kenergy's business.

Either way, please consider a fix and release to SRU in a timely manner because this is one of the more annoying regressions that KUbuntu edgy has generated.

Jonh, thanks for pushing this one forward. I think both of suggested patches are not really appropriate, as they just cure the side effect and not the root cause. The issue is that kdisplayrc contains values in minutes, therefore it does not make sense to change defaults to seconds as suggested by Francisco. I think the correct patch is that when kdisplayrc is read, proper defaults are used. Currently, they use DPMS values directly (in seconds) and this wrongly initializes the defaults.

I think the right patch is the following:

diff -Nur kdebase-3.5.5a.dfsg.1/kcontrol/energy/energy.cpp kdebase-3.5.5a.dfsg.1.new/kcontrol/energy/energy.cpp
--- kdebase-3.5.5a.dfsg.1/kcontrol/energy/energy.cpp 2006-10-01 19:31:49.000000000 +0200
+++ kdebase-3.5.5a.dfsg.1.new/kcontrol/energy/energy.cpp 2006-12-09 13:05:07.000000000 +0100
@@ -111,9 +111,9 @@
            DPMSInfo(dpy, &pre_configured_status, &pre_configured_enabled);
            /* let the user override the settings */
            enabled = cfg->readBoolEntry("displayEnergySaving", pre_configured_enabled);
- standby = cfg->readNumEntry("displayStandby", pre_configured_standby);
- suspend = cfg->readNumEntry("displaySuspend", pre_configured_suspend);
- off = cfg->readNumEntry("displayPowerOff", pre_configured_off);
+ standby = cfg->readNumEntry("displayStandby", pre_configured_standby/60);
+ suspend = cfg->readNumEntry("displaySuspend", pre_configured_suspend/60);
+ off = cfg->readNumEntry("displayPowerOff", pre_configured_off/60);
        } else {
        /* provide our defauts */
            enabled = true;

I am building kdebase now to try this out.

I am still not sure why this is triggered only with KDE 3.5.5. There was only one change in 3.5.5 in this code:
http://websvn.kde.org/branches/KDE/3.5/kdebase/kcontrol/energy/energy.cpp?rev=575644&r1=438982&r2=575644

I will discuss with the guy who committed this change about his view of this problem.

I find this bug very annoying, as I have to adjust those settings _every_ time I log in!

It has taken 2 months already.... Please do something about it !

I did not get any response from last changer of kenergy, so I have prepared patch for kdebase that should address this for feisty.

Debdiff is available on: http://lure.lu.funpic.de/kubuntu/feisty/kdebase16.debdiff

On Saturday 06 January 2007 15:27, Luka Renko wrote:
> I did not get any response from last changer of kenergy, so I have
> prepared patch for kdebase that should address this for feisty.

Is this recorded on bugs.kde.org? If you CCMAIL: kde-devel, I'm pretty sure
someone can commit the fix to KDESVN, then we will have it in for 3.5.6 and
don't have to carry an additional patch with us.

> Debdiff is available on:
> http://lure.lu.funpic.de/kubuntu/feisty/kdebase16.debdiff
--
sebas

 http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Unix is user-friendly. However, it isn't idiot friendly.

Fix uploaded to Feisty (and also committed to KDE SVN for 3.5.6 and 4.0)

Awesome. Now, what about a SRU for Edgy?