Bug 264730 - monitor is powered off after 10 minutes although contrary powerdevil settings
Summary: monitor is powered off after 10 minutes although contrary powerdevil settings
Status: RESOLVED NOT A BUG
Alias: None
Product: solid
Classification: Frameworks and Libraries
Component: powermanagement (show other bugs)
Version: unspecified
Platform: Archlinux Linux
: NOR normal with 55 votes (vote)
Target Milestone: ---
Assignee: Dario Freddi
URL:
Keywords:
: 261005 264621 265319 265689 275147 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-01-29 12:38 UTC by Moritz Augustin
Modified: 2012-09-18 12:12 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
powerdevil config (ui/conf) (321.61 KB, application/x-bzip)
2011-01-29 12:41 UTC, Moritz Augustin
Details
powerdevil2profilesrc (245 bytes, application/octet-stream)
2011-02-23 18:38 UTC, lcn.mustard
Details
powerdevil2profilesrc (871 bytes, application/octet-stream)
2011-09-30 14:57 UTC, S. Burmeister
Details
powerdevilrc (126 bytes, application/octet-stream)
2011-09-30 14:58 UTC, S. Burmeister
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Augustin 2011-01-29 12:38:31 UTC
Version:           unspecified (using KDE 4.6.0) 
OS:                Linux

watching a movie is very annoying. I have to  move the mouse every 10 minutes to see the pictures of the movie again and not only the beautiful black of the monitor in off/standby mode... with my current kde installation (kde 4.6 final archlinux packages)

after 10 minutes of idling (no mouse/keyboard actions) the monitor is powered off - either when watching a movie or whithout watching a movie

I have a desktop computer so no battery (and as you see in the screenshots only the first option in the global settings is not greyed out)

my powerdevil settings are attached (ui and config)

Reproducible: Didn't try

Steps to Reproduce:
wait 10 minutes

Actual Results:  
monitor is powered off

Expected Results:  
monitor should continue to operate and show the current desktop/movie whatever

hardware is a phenom 2 x4 910e processor, mainboard msi 770-c45
software archlinux 64 bit, kde 4.6 final (current packages) (kernel 2.6.36.3)
Comment 1 Moritz Augustin 2011-01-29 12:41:59 UTC
Created attachment 56608 [details]
powerdevil config (ui/conf)
Comment 2 Moritz Augustin 2011-01-29 12:46:06 UTC
in kde 4.5.5 it worked fine and the monitor was not powered off after 10 minutes

if not possible to find the actual bug (what would be a pitty) please tell me which program is responsible for powering off the monitor so I can disable it as a workaround because e.g. watching movies is very annoying atm and I do not want to leave KDE just for this tiny bug impressive bug
Comment 3 Dario Freddi 2011-01-29 13:31:49 UTC
Can you please tell me what the output of "xset -q" says?

Btw: in the meanwhile, you can disable the monitor's powersaving features by issuing "xset -dpms". Issue "xset +dpms" to re-enable it. And of course, don't do this before performing the "xset -q" test :)
Comment 4 Moritz Augustin 2011-01-29 13:43:32 UTC
Ok the 600 (seconds I guess) in "Standby: 600    Suspend: 600    Off: 600"
seem responsible. Should Powerdevil change these values?

Thanks for the workaround!

Output of xset -q:

~ % xset -q
Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000000
  XKB indicators:
    00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
    03: Compose:     off    04: Kana:        off    05: Sleep:       off
    06: Suspend:     off    07: Mute:        off    08: Misc:        off
    09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
    12: Group 2:     off    13: Mouse Keys:  off
  auto repeat delay:  660    repeat rate:  25
  auto repeating keys:  00ffffffdffffbbf
                        fadfffefffedffff
                        9fffffffffffffff
                        fff7ffffffffffff
  bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  20/10    threshold:  4
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  0    cycle:  600
Colors:
  default colormap:  0x20    BlackPixel:  0    WhitePixel:  16777215
Font Path:
  /usr/share/fonts/misc/,/usr/share/fonts/TTF/,/usr/share/fonts/Type1/,/usr/share/fonts/100dpi/,/usr/share/fonts/75dpi/,built-ins
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Enabled
  Monitor is On
Comment 5 Dario Freddi 2011-01-29 14:07:01 UTC
Yes, it should indeed change them, as it should disable DPMS due to your configuration (the equivalent of the workaround I suggested).

Accepting the bug, hopefully your workaround won't be needed in 4.6.1 :)
Comment 6 Dario Freddi 2011-01-29 14:08:14 UTC
*** Bug 264621 has been marked as a duplicate of this bug. ***
Comment 7 Dario Freddi 2011-01-30 15:24:03 UTC
Git commit 8db343c4b8c511b6d85dbe0ffebc039280836280 by Dario Freddi.
Pushed by dafre into branch 'master'.

Move DPMS handling in the constructor.

This makes more sense as

1. With the previous approach, DPMS support was queried everytime a profile changed, now it is queried on startup only.
2. It allows to disable DPMS on startup even if a profile has not loaded the action yet.

CCBUG: 264730

M  +17   -17   powerdevil/daemon/actions/dpms/powerdevildpmsaction.cpp     

http://commits.kde.org/a5d5b61a/8db343c4b8c511b6d85dbe0ffebc039280836280
Comment 8 Dario Freddi 2011-01-30 15:24:03 UTC
Git commit 5dd9f08b1849800989778d4ca82f91b6977acfff by Dario Freddi.
Pushed by dafre into branch 'master'.

Add a new method to ActionPool, init(), to load on startup actions which require instant load.

Some actions, such as DPMS, require to be initialized even if no profile explicitly asked for the action itself,
as it might be necessary to perform some changes when the action is disabled.

BUG: 264730

M  +27   -0    powerdevil/daemon/powerdevilactionpool.cpp     
M  +2    -0    powerdevil/daemon/powerdevilactionpool.h     
M  +3    -0    powerdevil/daemon/powerdevilcore.cpp     

http://commits.kde.org/a5d5b61a/5dd9f08b1849800989778d4ca82f91b6977acfff
Comment 9 Dario Freddi 2011-01-30 15:24:46 UTC
Git commit c514910cef68c614286be7135e0d22d9226dacfa by Dario Freddi.
Pushed by dafre into branch '4.6'.

Add a new method to ActionPool, init(), to load on startup actions which require instant load.

Some actions, such as DPMS, require to be initialized even if no profile explicitly asked for the action itself,
as it might be necessary to perform some changes when the action is disabled.

CCBUG: 264730
FIXED-IN: 4.6.1

(cherry picked from commit 5dd9f08b1849800989778d4ca82f91b6977acfff)

M  +27   -0    powerdevil/daemon/powerdevilactionpool.cpp     
M  +2    -0    powerdevil/daemon/powerdevilactionpool.h     
M  +3    -0    powerdevil/daemon/powerdevilcore.cpp     

http://commits.kde.org/a5d5b61a/c514910cef68c614286be7135e0d22d9226dacfa
Comment 10 Dario Freddi 2011-02-03 19:44:48 UTC
*** Bug 265319 has been marked as a duplicate of this bug. ***
Comment 11 Dario Freddi 2011-02-07 13:04:37 UTC
*** Bug 265689 has been marked as a duplicate of this bug. ***
Comment 12 S. Burmeister 2011-02-10 22:16:13 UTC
Another side-effect of this bug is that the brigtness is not restored after the screen was powered off AND one waits longer than 10 minutes before moving the mouse.

If one moves the mouse before those 10 minutes the brightness is fully restored.
Comment 13 S. Burmeister 2011-02-10 22:18:10 UTC
Oh, and this bug did not only affect desktops but notebooks as well, i.e. their screen is powered off after 10 minutes although the profile states 360 minutes before it should happen.
Comment 14 S. Burmeister 2011-02-15 11:36:36 UTC
According to the openSUSE devs they backported all commits mentioned in this bug to their packages. Yet the bug is still there, so I do not think it was fully fixed.
Comment 15 lcn.mustard 2011-02-23 02:18:52 UTC
I don't if is the same problem , but:
I have the same problem. Just upgraded to kde4.6 and my Power management can't
find power profile or save new settings.
Platform Version 4.6.00 (4.6.0)
~$ kded4 > log.txt
KDE Daemon (kded) already running.
log.txt is blank
Mys powerdevil2profilesrc:
[Luciana]
icon=
name=Luciana

[Performance]
icon=preferences-system-performance

[test]
icon=
name=test

xset -q

xset -q
Keyboard Control:
  auto repeat:  on    key click percent:  72    LED mask:  00000002
  XKB indicators:
    00: Caps Lock:   off    01: Num Lock:    on     02: Scroll Lock: off
    03: Compose:     off    04: Kana:        off    05: Sleep:       off
    06: Suspend:     off    07: Mute:        off    08: Misc:        off
    09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
    12: Group 2:     off    13: Mouse Keys:  off
  auto repeat delay:  250    repeat rate:  30
  auto repeating keys:  00ffffffdffffbbf
                        fadfffefffedffff
                        9fffffffffffffff
                        fff7ffffffffffff
  bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  10/10    threshold:  4
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  0    cycle:  600
Colors:
  default colormap:  0x20    BlackPixel:  0    WhitePixel:  16777215
Font Path:  /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,built-ins
DPMS (Energy Star):
  Standby: 3600    Suspend: 5400    Off: 7200
  DPMS is Disabled
Comment 16 lcn.mustard 2011-02-23 18:37:27 UTC
Sorry! I do not believe this was fixed problem. I install it kde 4.6 final  and then the trouble started. With the bum I enable acpi and acpi-suport and disabled
DPMS in xorg. Nothing works. The monitor turns off after 10 minutes.
If any knows how to solve please tell because I'm about to format the HD to
remove kde4.6. When kde4.6.1 will be release for kubuntu? Sometimes people stop to talk because they have left this version and not because the problem was fixed.
Comment 17 lcn.mustard 2011-02-23 18:38:59 UTC
Created attachment 57476 [details]
powerdevil2profilesrc
Comment 18 Stan G. Kain 2011-02-23 19:23:19 UTC
I am in complete agreement here.  This problem is not resolved.  I have done fresh installs and whatever else I can think of and still, the monitor goes to sleep after a period of time and likewise, my wireless quits and the pop-up asks to re=enter they passkey.  If I do, it makes no difference.  Still just will indicate configuring network.

Between these two issues, the only way Kubuntu 11.04 is usable is if you reboot the system every 10 minutes or so.  After reboot, the monitor is awake and the wireless is working properly again.

zenarcher
Comment 19 Dario Freddi 2011-02-23 21:41:44 UTC
Please, PLEASE read. This bug is fixed IN 4.6.1 which means that version 4.6.0 is bugged, and there's nothing we can do to fix a released version. 4.6.1 will be out in a matter of days, and that version will carry the fix.
Comment 20 Dario Freddi 2011-03-05 17:31:36 UTC
*** Bug 261005 has been marked as a duplicate of this bug. ***
Comment 21 S. Burmeister 2011-04-08 14:10:18 UTC
(In reply to comment #19)
> Please, PLEASE read. This bug is fixed IN 4.6.1 which means that version 4.6.0
> is bugged, and there's nothing we can do to fix a released version. 4.6.1 will
> be out in a matter of days, and that version will carry the fix.

NOT fixed in KDE 4.6.2.
Comment 22 Beat Wolf 2011-04-08 14:17:10 UTC
reopened after last feedback
Comment 23 S. Burmeister 2011-09-30 13:42:43 UTC
See bug 272438 for profiles to reproduce.
Comment 24 Dario Freddi 2011-09-30 14:17:26 UTC
I think I understand why it does not work for you. Can you please check if your monitor supports DPMS suspend and/or standby?
Comment 25 S. Burmeister 2011-09-30 14:55:06 UTC
It's a DELL notebook. How do I check it?

Searching through the Xorg log I found:

[    21.069] (II) Loading extension DPMS
[    21.401] (II) intel(0): No DPMS capabilities specified
[    21.762] (==) intel(0): DPMS enabled
Comment 26 S. Burmeister 2011-09-30 14:56:21 UTC
ah, and it does not happen after killing the old profiles. Attaching working profile which you can use to diff the old ones.
Comment 27 S. Burmeister 2011-09-30 14:57:27 UTC
Created attachment 64099 [details]
powerdevil2profilesrc
Comment 28 S. Burmeister 2011-09-30 14:58:47 UTC
Created attachment 64100 [details]
powerdevilrc

working configs, see above for the link to the bug with the non-working profiles.
Comment 29 Dario Freddi 2011-09-30 17:48:55 UTC
@Sven: I think you might get the illusion this works, as the first occurrence of the timeout is when the screen gets dimmed - aka brightness goes to 0. What happens if you disable screen dimming? Does it work as expected?

The rationale behind my assumption before is that powerdevil behaves this way, to allow a faster monitor resume: when you set a timeout for screen poweroff, it turns the screen to standby at timeout, to suspend at timeout*1.5, and to power off to timeout*2. Of course, if your system does not support one of the first options, it's apparently going to power off the screen at a different timeout.

Grepping through the X log is the right way to do it, and the fact that your display doesn't have available capabilities is not helping. I'll wait for you to confirm that if you don't enable dimming you can still experience the issue, if so my assumption is right and I'll push a fix.
Comment 30 Dario Freddi 2011-09-30 20:36:05 UTC
*** Bug 275147 has been marked as a duplicate of this bug. ***
Comment 31 S. Burmeister 2011-09-30 22:10:46 UTC
It seems that disabling dimming with the broken profiles prevents the screen from going black after 10 minutes. I'll have to test if it works with the new profiles and dimming enabled.
Comment 32 Dario Freddi 2011-09-30 22:15:58 UTC
Can you please check if your system is capable of doing DPMS? Is "xset dpms force on" working? If it does, try also "xset dpms force suspend" and "xset dpms force standby"
Comment 33 S. Burmeister 2011-10-01 07:02:26 UTC
(In reply to comment #32)
> Can you please check if your system is capable of doing DPMS? Is "xset dpms
> force on" working? If it does, try also "xset dpms force suspend" and "xset
> dpms force standby"

dpms force on: no feedback in the commandline, nothing happens
force suspend, the display is turned off
force standby, the display is turned off.

Notice that the "monitor off after 10 minutes" is different, i.e. the screen becomes only black, compared to what suspend and standby do.
Comment 34 Dario Freddi 2011-10-01 11:28:17 UTC
Ok, I think I am losing track here then. Let's start from scratch: with the "bugged" profiles of the other bug, what happens?
Comment 35 S. Burmeister 2011-10-01 12:52:00 UTC
Sorry for the confusion!

The light was different so it looked like the screen would not power off after 10 minutes but just blank. I checked again and it does power off.

So what I see with the profiles from the other bug is:

In powersaving (Energiesparen) with dimming set to 5 minutes the display is powered-off after exactly 10 minutes although it is set to power off after 360 minutes.

the xset commands work, i.e. power off the display.

If I disable dimming the display is not disabled. This could be due to dimming playing a role or simply because the config file had bugs and is rewritten correctly.
Comment 36 S. Burmeister 2011-11-06 23:28:59 UTC
Same with the above mentioned config files and KDE 4.7.3.
Comment 37 Garth Johnson 2012-01-18 21:58:37 UTC
Bug exists in 4.7.97, also.
Comment 38 Dario Freddi 2012-01-18 22:19:39 UTC
I am closing this bug as it became a huge pot of different problems, and I don't know what people are referring to when they say "bug still exists". Please, to anybody who's experiencing an issue along those lines, open a new bug detailing YOUR problem so I can look into them. Thanks.
Comment 39 Garth Johnson 2012-01-19 02:33:46 UTC
(In reply to comment #38)
> I am closing this bug as it became a huge pot of different problems, and I
> don't know what people are referring to when they say "bug still exists".
> Please, to anybody who's experiencing an issue along those lines, open a new
> bug detailing YOUR problem so I can look into them. Thanks.

That's the second time I've seen this happen with this same bug.  This issue (the one that the original bug reporter refers to, about KDE powering the monitor off after 10 minutes regardless of settings) has been with me for about the last 3 releases of KDE, and because of this one single issue I have since sadly had to stop using it.  Is this not reproducible?  I would be happy to give you my hardware configuration or any other info that you needed.
Comment 40 Dario Freddi 2012-01-19 04:41:39 UTC
Garth, I know it's the second time, and still people keep commenting and don't follow my advice. Please, please help me helping you. Open a new bug detailing your problem as much as you can, your HW might indeed help, and we can start tracking the issue from there. To answer your question no, monitor power off has always worked perfectly here. Now please, let's stop commenting on this bug and let's focus on the issue(s).
Comment 41 S. Burmeister 2012-01-19 19:08:18 UTC
(In reply to comment #40)
> Garth, I know it's the second time, and still people keep commenting and don't
> follow my advice. Please, please help me helping you.

Sorry, but comment 23 stattes where to find the profilöes you have to use in order to reproduce the bug. I did not see a comment about you testing that so how do I have to understand the "Please, please help me helping you."?

Please, please use profiles provided months ago.

> Open a new bug detailing
> your problem as much as you can, your HW might indeed help, and we can start
> tracking the issue from there. To answer your question no, monitor power off
> has always worked perfectly here. Now please, let's stop commenting on this bug
> and let's focus on the issue(s).

Then, please, please…
Comment 42 Dario Freddi 2012-01-19 20:47:33 UTC
I probably should use my native language here because people don't seem to understand. I'll try with all caps first: DON'T COMMENT ON THIS BUG ANYMORE.
I am not stupid, the profile format changed and I cannot use those profiles anymore. Moreover, people provided infos about different issues making it really hard to track this bug. Can I at least be trusted to know how my software works? And btw, https://bugs.kde.org/show_bug.cgi?id=291926
Comment 43 S. Burmeister 2012-01-20 11:32:43 UTC
Bollocks! I can use those profiles and they get updated to whatever works with 4.8 and show the same behaviour. Don't bail out. Fix your bugs and don't ignore them until there are enough comments to claim that you cannot fix them because of too many comments.
Comment 44 Dario Freddi 2012-01-20 12:29:40 UTC
First of all, I remember you I am not paid for doing that, and I'd gladly avoid taking orders from somebody who's currently getting in the way of my (free) work and most of all, not paying me. Please fix your attitude if you want to help keeping a constructive discussion.

I linked you the new bug I am tracking for this issue, and I NEVER said I am not fixing this bug, which is something you totally made up - I said this specific bug report tracks too many different causes and hence is no longer useful for tracking this issue. Got the difference? If you can find the part where I say "I do not care about this bug and will never fix it" I will gladly offer you a beer, but I am afraid you won't get one, because I never said that.

Your profiles are 1) from an older KDE version 2) currently not enough and hardly useful for tracking the issue. Wonder why at this stage those information are insufficient? The bug described initially in this thread is probably fixed in 4.8 for the cause described in THIS report, but likely reappeared thanks to another change, and I was able to find that out thanks to Garth, who has been kind enough to follow my directions and giving out some concrete help. Now, would you still use a bug which has outdated, misleading, and confusing information for tracking this issue, which is proven to be different?

Now, please continue the discussion on the new bug (which is bug 291926) to make everyone's life easier (the bug needsinfo, maybe you can provide them), since I think I provided enough reasons why this issue should be disregarded. If bug 291926's symptoms does not match yours, you are more than welcome to open a new issue detailing your symptoms and possibly attaching a log of kded4, which at this stage is probably the only useful data, since I just double checked today there is apparently no issue in profile handling which might lead to such a behavior. The problem likely lies in faulty inhibition (which is 291926 case) or faulty initialization of the action (which is something I am unable to reproduce here).

Just to end that, I urge everybody to stop commenting on this issue once again, since we're wasting everyone's time here.
Comment 45 S. Burmeister 2012-09-18 12:12:18 UTC
For those who still experience this the following might work:

Edit ~/.kde4/share/config/kscreensaverrc and add:

DPMS-dependent=false

in the [ScreenSaver] section.