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)
Created attachment 56608 [details] powerdevil config (ui/conf)
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
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 :)
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
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 :)
*** Bug 264621 has been marked as a duplicate of this bug. ***
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
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
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
*** Bug 265319 has been marked as a duplicate of this bug. ***
*** Bug 265689 has been marked as a duplicate of this bug. ***
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.
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.
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.
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
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.
Created attachment 57476 [details] powerdevil2profilesrc
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
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.
*** Bug 261005 has been marked as a duplicate of this bug. ***
(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.
reopened after last feedback
See bug 272438 for profiles to reproduce.
I think I understand why it does not work for you. Can you please check if your monitor supports DPMS suspend and/or standby?
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
ah, and it does not happen after killing the old profiles. Attaching working profile which you can use to diff the old ones.
Created attachment 64099 [details] powerdevil2profilesrc
Created attachment 64100 [details] powerdevilrc working configs, see above for the link to the bug with the non-working profiles.
@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.
*** Bug 275147 has been marked as a duplicate of this bug. ***
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.
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"
(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.
Ok, I think I am losing track here then. Let's start from scratch: with the "bugged" profiles of the other bug, what happens?
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.
Same with the above mentioned config files and KDE 4.7.3.
Bug exists in 4.7.97, also.
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.
(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.
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).
(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…
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
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.
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.
For those who still experience this the following might work: Edit ~/.kde4/share/config/kscreensaverrc and add: DPMS-dependent=false in the [ScreenSaver] section.