Version: (using KDE 4.2.1) OS: Linux Installed from: SuSE RPMs If one turns off the screensaver kde-wide, i.e. in systemsettings, dragonplayer re-enables it, if one stops playback. To reproduce just disable the screensaver in systemsettings > display and wait 10 minutes. The screensaver will not be enabled. Now open some DVD or video with dragonplayer and pause it. Wait 10 minutes and you will get the blank screen screensaver.
I'm seeing the same issue as described. Using opensuse 11 kde 4.2.1 QT 4.4.3 The only way I've found to avoid this is to set the screensaver time-out to a very high value or go to systemsettings > display and enable and then disable the screensaver after running dragonplayer.
I think the same happens with digikam 0.10 when it starts a slideshow.
Works for me. KDE 4.3.1 on Gentoo.
Same problem. Gentoo, KDE 4.3.1. I couldn't figure out for days what was causing this. The poster is correct that dragon player can produce this behavior. It seems to disable the screensaver when it opens, and re-enable it when closed, regardless of the previous state of the screensaver. I have tested it several times and it can be reproduced with 100% reliability. With the screensaver disabled in the panel: 1 - Before dragonplayer is opened the screensaver will not come on. 2 - Start dragon player and play a movie. The screensaver remains inactive. 3 - Close dragon player. The screensaver will now come on when the computer is idle. 4 - Play another movie in dragon player. The screensaver will again be deactivated. Each time dragon player is opened and closed the screensaver is toggled off and on.
(In reply to comment #2)> I think the same happens with digikam 0.10 when it starts a slideshow. Yes, it happens on other programs too, but dragon player is the first I've been able to confirm. The reason is, I rarely use dragon player and this has happened to me several times lately even though I haven't used dragon player in quite some time. Dragon player and other programs should remember the initial state of the screensaver and return it to that state on close, instead of blindly enabling it.
The following shell command also reproduces this bug with the screensaver turned off in the panel: dbus-send --dest=org.freedesktop.ScreenSaver --print-reply /ScreenSaver org.freedesktop.ScreenSaver.Inhibit string:"dragonplayer" string:"Watching a film" That alone points to the libraries. In kdemultimedia-4.3.1/dragonplayer/src/app/stateChange.cpp commenting out lines 124-131, and 136-144 fixes the bug. (However, oddly, uncommenting only 126 causes it to return as reported. That's this line: QDBusInterface screensaver("org.freedesktop.ScreenSaver", "/ScreenSaver", "org.freedesktop.ScreenSaver"); ) If you check the return value from 127, it's not valid when the screensaver is disabled in the panel, however it should be since the aforementioned shell command returns a valid cookie under the same conditions. (This is almost enough to make me suspect something isn't right in QT too.) There are a couple of obvious problems in stateChange.cpp. In 142 "Uninhibit" should be "UnInhibit". This shows up in dbus-monitor, meaning UnInhibit isn't being properly called. I fixed this, and it makes no difference except to get rid of the dbus error. In krunner/screensaver/saverengine.cpp, the Inhibit() method does not store the initial state of the screensaver as written, and UnInhibit() does not check it, so even if the dbus calls got this far and were in order, the screensaver would always end up enabled after a call to Inhibit() and a subsequent call on UnInhibit(), exactly as the report describes.
*** Bug 217642 has been marked as a duplicate of this bug. ***
As of SVN revision 1059572 it should only use KNotificationRestrictions(KNotificationRestrictions::ScreenSaver) for inhibiting the screensaver, which should handle this correctly.
SVN commit 1100542 by ossi: make UnInhibit not enable a disabled screensaver BUG: 186908 M +4 -2 saverengine.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1100542
*** Bug 211620 has been marked as a duplicate of this bug. ***
Could this please be backported or does the fix only work for trunk?
this is already on kde 4.4 http://websvn.kde.org/?view=revision&revision=1102694
(In reply to comment #12) > this is already on kde 4.4 > > http://websvn.kde.org/?view=revision&revision=1102694 Ah, ok. I only saw the commit in this report. Thanks for fixing this issue!
*** Bug 206475 has been marked as a duplicate of this bug. ***