Same here on openSUSE 12.1. Worked with 4.7.x.

kded(15378) PowerDevil::Action::trigger: Unsatisfied policies, the action has been aborted

This regressions was still not fixed in RC2.

I would love to see a bit of a raised priority here, since not locking screens is a serious security issue for mobile devices. 

If the check is actually not needed, then why not disabling it in the meantime?

Interestingly, I'd seen this on and off testing rc1.  Sometimes it would work, sometimes not. for those experiencing this, did it always not work?  (if so, maybe our issues differ somehow).

Will be testing rc2 more today.

To further investigate, I need a full terminal log of kded4

Cool.  dumb question, how does one get a 'log of kded4' ?

Just the terminal output with all kdebugs enabled (use kdebugdialog) is sufficient. killall kded4, and restart kded4 piping its output somewhere

*** Bug 288577 has been marked as a duplicate of this bug. ***

Created attachment 67488 [details]
kded log

If I understood correctly this is the log you need.

Created attachment 67489 [details]
kded4 output as asked

There you go, thanks in advance for investigating

Thanks guys. Dimitris' output shows the problem:

kded(3202)/kio_xz RandrMonitorModule::checkInhibition: Active monitor list
kded(3202)/kio_xz RandrMonitorModule::checkInhibition: ("default")
kded(3202) PowerDevil::PolicyAgent::AddInhibition: Added inhibition with cookie  1
kded(3202) PowerDevil::PolicyAgent::addInhibitionTypeHelper: Added interrupt session

Aaaaaaleeeeeexx, can you please have a quick look? seems like something totally wrong is going on with krandr.

Apparently alex wasn't the default assignee, resetting.

*** Bug 289716 has been marked as a duplicate of this bug. ***

*** Bug 291085 has been marked as a duplicate of this bug. ***

Git commit 0d45d5fc99b931796b79042d1dbb8e17f974b5e3 by Alex Fiestas.
Committed on 14/01/2012 at 13:03.
Pushed by afiestas into branch 'KDE/4.8'.

Ignore "default" monitors as we do with LVDS

NVIDIA Binary Blob does not report the type of the screen and instead it
always report "default". Basically this patchs prevent the
checkInhibition code to always inhibit when used with the  binary blob.

M  +4    -1    kcontrol/randr/module/randrmonitor.cpp

http://commits.kde.org/kde-workspace/0d45d5fc99b931796b79042d1dbb8e17f974b5e3

I'm 99% sure this is fixed, but If possible I would appreaciate some test from:

-NVIDIA blob users
-NON laptop users

Thanks !

But you do know that it happens not only with nvidia?

I have just tried it on a Sony VAIO with Nvidia 230M and it's working as expected.
Thanks.

(In reply to comment #18)
> I have just tried it on a Sony VAIO with Nvidia 230M and it's working as
> expected.

Bear in mind that according to comment 4 and my personal experience as well it did work before as well – sometimes.

Do you have a laptop? If so,which GPU ?

I did some more commits that should cover more exceptions, such drivers without xrandr 1.2 support.
> (In reply to comment #18)
> > I have just tried it on a Sony VAIO with Nvidia 230M and it's working as
> > expected.
> 
> Bear in mind that according to comment 4 and my personal experience as well it
> did work before as well – sometimes.

My desktop does not have a lid which could send a signal. ;) So yes, I'm talking about a notebook.

Intel graphics. Always worked with <= 4.7.

hwinfo --gfxcard
09: PCI 02.0: 0300 VGA compatible controller (VGA)              
  [Created at pci.319]
  Unique ID: _Znp.96rjlAI3YhC
  SysFS ID: /devices/pci0000:00/0000:00:02.0
  SysFS BusID: 0000:00:02.0
  Hardware Class: graphics card
  Model: "Dell Inspiron 1420"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x2a02 "965 GM"
  SubVendor: pci 0x1028 "Dell"
  SubDevice: pci 0x01f3 "Inspiron 1420"
  Revision: 0x0c
  Driver: "i915"
  Driver Modules: "drm"
  Memory Range: 0xfea00000-0xfeafffff (rw,non-prefetchable)
  Memory Range: 0xe0000000-0xefffffff (ro,non-prefetchable)
  I/O Ports: 0xeff8-0xefff (rw)
  IRQ: 44 (383234 events)
  I/O Ports: 0x3c0-0x3df (rw)
  Module Alias: "pci:v00008086d00002A02sv00001028sd000001F3bc03sc00i00"
  Driver Info #0:
    XFree86 v4 Server Module: intel
  Driver Info #1:
    XFree86 v4 Server Module: intel
    3D Support: yes
    Extensions: dri
  Config Status: cfg=new, avail=yes, need=no, active=unknown

10: PCI 02.1: 0380 Display controller
  [Created at pci.319]
  Unique ID: ruGf.gYCMf0bjpI2
  SysFS ID: /devices/pci0000:00/0000:00:02.1
  SysFS BusID: 0000:00:02.1
  Hardware Class: graphics card
  Model: "Dell Inspiron 1420"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x2a03 "Mobile GM965/GL960 Integrated Graphics Controller"
  SubVendor: pci 0x1028 "Dell"
  SubDevice: pci 0x01f3 "Dell Inspiron 1420"
  Revision: 0x0c
  Memory Range: 0xfeb00000-0xfebfffff (rw,non-prefetchable)
  Module Alias: "pci:v00008086d00002A03sv00001028sd000001F3bc03sc80i00"
  Config Status: cfg=new, avail=yes, need=no, active=unknown

 rpm -qa | grep xorg
xorg-x11-driver-video-7.6-80.1.2.i586
xorg-x11-Xvnc-7.6_1.10.4-36.2.1.i586
xorg-x11-libXau-7.6_1.0.6-9.1.2.i586
xorg-x11-libxkbfile-7.6-9.1.2.i586
xorg-x11-server-7.6_1.10.4-36.2.1.i586
xorg-x11-libICE-7.6-11.1.2.i586
xorg-x11-libXfixes-7.6_5.0-3.1.2.i586
xorg-x11-libfontenc-7.6-9.1.2.i586
xorg-x11-7.6-67.3.1.i586
xorg-x11-libXp-7.6-5.1.2.i586
xorg-x11-driver-video-nouveau-0.0.16_20110720_b806e3f-2.1.2.i586
xorg-x11-libXrender-7.6_0.9.6-9.1.2.i586
xorg-x11-xauth-7.6-67.3.1.i586
xorg-x11-libXpm-7.6-9.1.2.i586
xorg-x11-libX11-ccache-7.6-7.1.1.noarch
xorg-x11-libSM-7.6-10.1.2.i586
xorg-x11-driver-video-intel-legacy-2.9.1-13.1.2.i586
xorg-x11-driver-input-7.6-41.38.2.i586
xorg-x11-libXt-7.6_1.0.9-14.1.2.i586
xorg-x11-libXv-7.6-9.1.2.i586
xorg-x11-libs-7.6-25.1.2.i586
xorg-x11-libxcb-7.6_1.7-11.1.2.i586
xorg-x11-libX11-7.6-23.1.2.i586
xorg-x11-fonts-core-7.6-16.1.2.noarch
xorg-x11-driver-video-radeonhd-1.3.0_20100512_80ba041-5.1.2.i586
xorg-x11-fonts-7.6-16.1.2.noarch
xorg-x11-libXdmcp-7.6-10.1.2.i586
xorg-x11-libXext-7.6_1.2.0-5.1.2.i586
xorg-x11-libXmu-7.6-10.1.2.i586
xorg-x11-libXprintUtil-7.6-5.1.2.i586

Well it should be fixed now, I have a similar netbook (Dell XPS1330) and it is working fine.

I still have same issue or release KDE 4.8 on laptop with external display.

This bug is really resolved? May you reopen it please?

It worked once for me and then quit working on KDE 4.8. I am on a Lenovo W510 (Nvidia Graphics 280.13). Still broken for me too.

Kubuntu 11.10 with the Backports PPA.

I do believe this is a configuration error at this point. In my 'guest' account, it all works correctly.

I still experience this bug too. It appeared to be fixed in RC2 but now it's back in 4.8 final. I tried deleting power management config files in .kde4/share/config which didn't help. Arch Linux 64bit, KDE 4.8 from testing repository.

Just updated to 4.8 and still having this problem.

kded(1544) PowerDevil::Action::trigger: Unsatisfied policies, the action has been aborted

What configuration should I change to solve this?

As it seems obvious that this issue is not fixed in 4.8.0 (x+1 users  on y+1 distros) could the developer or the original reporter please re-open this bug and add "regression" to the summary since that would be an accurate description for this bug.

Same should apply to all other powerdevil bugs that were "fixed" by pointing to this bug being "resolved".

People experiencing this bug in 4.8 final: please attach a log of kded4 to find out if we are still talking about the krandr issue or something else is going on. If it's still krandr I'll take care of reopening the bug, otherwise we might want to move the issue elsewhere to another report depending on what's going on.

@Alexander, madcat: unfortunately this is not a configuration problem

@Alex, just to be sure, can you please check if your commit has made it into the 4.8.0 tag? Maybe it's just an issue with tarballs, although I'm not experiencing the bug on 4.8.0 final (NVIDIA blob)

P.S.: Other reports should NOT be reopened. The whole purpose of closing a bug as a duplicate is to avoid tracking the same issue in multiple spots, since a duplicate bug should not have been reported in the first place. The duplicate itself already tracks its status through the master bug if the parent is reopened, and people who reported the duplicate are automatically added to the master bug, so they're not losing track of what's happening.

@Runet: what you are experiencing is actually a feature. If you have an external monitor connected to your laptop, suspension is always prevented when closing the lid, so that you can use your external monitor without having to keep the lid open.

I'm going to need the kded4 log and the xrandr command output.

Tested on 3 different machines with 3 different distros and with 2 different types of drivers and it worked fine :(

(Intel + Kubuntu 12.04, ATI + Arch, Intel + Arch)

Ah, if someone with this problem wants to help it fixed quickly, I'm on IRC freenode.org nick "afiestas".

I'm actually talking about the Bug 289716 (namely about the second paragraph), it was marked as duplicate of this one.

The part about the power button is actually the very same issue, for how inhibition is structured, and the description of your problem confirms that. Simply, the "suspend session" action refuses to trigger whenever you press the power button since it's inhibited.

For the DPMS issue you are experiencing, it is very likely because of this problem, but might as well not be. Let's get back to that when this problem is solved for everyone; in case it persists we'll reopen and rename your bug - trying to track it now is just adding more variables to the boilerplate. But be assured we'll be on it eventually, if it doesn't disappear together with this bug

All right, I haven't been able to figure out where the kded4 logs go to. Where do they get logged to?

Unfortunately the only way is to kill the current kded process and pipe the output of a newly started kded to a file. Note that you need to enable KDebug outputs for those information to be meaningful (you can do that using an app named kdebugdialog)

Call me crazy, but there's some interesting things going on. Here's the situation so far:

Updated to 4.8 RC1 and my suspending when closing the lid quit working.
Updated to RC2 and still had the same problem.
Update to 4.8 Final and expected my problem to go away. It didn't.

Removed my ~/.kde/share/config/kpowersettings (not quite right, but it was something along those lines). Still no go.
Removed my ~/.kde/share/config/krander and things seemed to be right. It would suspend the first time I tried it in a session, but additional lid closes did nothing.

What finally has worked was enabling debug, interestingly enough. I enabled it and couldn't reproduce. I disabled it and still cannot reproduce. Why? I dunno.

I have the same problem on Kubuntu 11.10, KDE 4.8.0 on MacBook Pro (opensource ati video drivers). The only option that works with lid closing is to disable the display.

(In reply to comment #30)
> @Runet: what you are experiencing is actually a feature. If you have an
> external monitor connected to your laptop, suspension is always prevented when
> closing the lid, so that you can use your external monitor without having to
> keep the lid open.

I think, this is incorrect. I also have an external display attached, but if I wanted to leave it active when closing the lid, I would select "Do nothing" in the system settings. Instead, I want to lock the screen on this event, and it doesn't work.

*** Bug 292970 has been marked as a duplicate of this bug. ***

Can this bug be reopened?

BTW, I tried to save the kded4 log but I don't have such process and starting one fails with D-Bus errors. Is there any other way I can get this log?

@Lastique: urgh. Then you are not experiencing this bug but a more serious issue about KDED4 not running at all. You should really hear from your distributor since you appear to have a broken installation.

Git commit 4c98afbd97f190e740ac7127f9af99b5333a741a by Alex Fiestas.
Committed on 02/02/2012 at 16:07.
Pushed by afiestas into branch 'KDE/4.8'.

Adding eDP port as "laptop port" just like LVDS

eDP are just like LVDS but more modern, so they should be
considered as a laptop screen and inhibit when only it is
available.

This will fix the inhibition problem probably for the rest
of the affected users.

amichair thanks for the debugging :)

M  +1    -1    kcontrol/randr/module/randrmonitor.cpp

http://commits.kde.org/kde-workspace/4c98afbd97f190e740ac7127f9af99b5333a741a

Can anyone still affected with this bug attach the output of xrandr? if your laptop screen is called eDP then the commit 4c98afbd97f190e will fix it.

If not, come on! give us good kded outputs so we can fix this bug, do the follow:

1-killall kded4; sleep 1; kded4 --nofork (we will need this output)
2-Enable all screens
3-Close the lid
4-Disable external screen
5-Close the lid
6-Attach the kded output here.

Thanks again to our amazing users for the feedback provided :)

(In reply to comment #42)
> @Lastique: urgh. Then you are not experiencing this bug but a more serious
> issue about KDED4 not running at all. You should really hear from your
> distributor since you appear to have a broken installation.

Sorry, I misinterpreted the situation. I did have the kded4 process and I killed it. However, as I said, I could not start it again. I got the following error:

kded(2333): KUniqueApplication: Cannot find the D-Bus session server:  "//bin/dbus-launch terminated abnormally with the following error: Autolaunch error: X11 initialization failed.

(In reply to comment #46)
> (In reply to comment #42)
> > @Lastique: urgh. Then you are not experiencing this bug but a more serious
> > issue about KDED4 not running at all. You should really hear from your
> > distributor since you appear to have a broken installation.
> 
> Sorry, I misinterpreted the situation. I did have the kded4 process and I
> killed it. However, as I said, I could not start it again. I got the following
> error:
> 
> kded(2333): KUniqueApplication: Cannot find the D-Bus session server: 
> "//bin/dbus-launch terminated abnormally with the following error: Autolaunch
> error: X11 initialization failed.

This is actually even worse. If your session bus is not running you should be experiencing a variety of problems. Recheck your installation, your problem might be fixed once you do that - otherwise, have a look at Alex's comment.

Mmm you have to start the kded appliction with your user not with root (just in case you did that)

Here is my output:

gkourtev@gkourtev-laptop:~$ kded4 --nofork
Failed to read classid file: Object not found
QDBusObjectPath: invalid path "/modules/muon-notifier"
kded(2593): The kded module name ' "muon-notifier" ' is invalid! 
kded(2593)/kmix sink_input_cb: Ignoring sink-input due to it being designated as an event and thus handled by the Event slider 
Agent registered 
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
Object::connect: No such signal QDBusAbstractInterface::Changed()
/usr/bin/python: can't find '__main__' module in ''
kded(2593)/kmix sink_input_cb: Ignoring sink-input due to it being designated as an event and thus handled by the Event slider 
kded(2593)/kmix sink_input_cb: Ignoring sink-input due to it being designated as an event and thus handled by the Event slider 
kded(2593)/kmix sink_input_cb: Ignoring sink-input due to it being designated as an event and thus handled by the Event slider 
kded(2593)/kmix sink_input_cb: Ignoring sink-input due to it being designated as an event and thus handled by the Event slider 
Unregistering object 
Agent registered

Is that the entire output ? try enabled everything with the word "kded" in kdebugdialog (execute that)
(In reply to comment #49)
> Here is my output:
> 
> gkourtev@gkourtev-laptop:~$ kded4 --nofork
> Failed to read classid file: Object not found
> QDBusObjectPath: invalid path "/modules/muon-notifier"
> kded(2593): The kded module name ' "muon-notifier" ' is invalid! 
> kded(2593)/kmix sink_input_cb: Ignoring sink-input due to it being designated
> as an event and thus handled by the Event slider 
> Agent registered 
> Connecting to deprecated signal
> QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
> Object::connect: No such signal QDBusAbstractInterface::Changed()
> /usr/bin/python: can't find '__main__' module in ''
> kded(2593)/kmix sink_input_cb: Ignoring sink-input due to it being designated
> as an event and thus handled by the Event slider 
> kded(2593)/kmix sink_input_cb: Ignoring sink-input due to it being designated
> as an event and thus handled by the Event slider 
> kded(2593)/kmix sink_input_cb: Ignoring sink-input due to it being designated
> as an event and thus handled by the Event slider 
> kded(2593)/kmix sink_input_cb: Ignoring sink-input due to it being designated
> as an event and thus handled by the Event slider 
> Unregistering object 
> Agent registered

I'm getting this bug too.  Sleep on laptop lid closed works several times and then quits working.

My computer is a Lenovo ThinkPad W520 and I'm running openSUSE 12.1 (x86_64) using KDE 4.8.00 (4.8.0 "release 462") from the KDE SC 4.8 (Core packages) and KDE SC 4.8 (Extra) repositories.

The error I get in ~/.xsession-errors is "kded(1440) PowerDevil::Action::trigger: Unsatisfied policies, the action has been aborted".

When it does this I can press Alt-F2 and run kill 'pidof plasma-desktop' (with backticks of course).  Then I press alt-F2 and type dbus-launch plasma-desktop.  Sleep on lid close will work again for a while.  Kind of ugly, but at least I don't have to log out and back in again.

Created attachment 68545 [details]
kded and xsession logs

I finally managed to save logs from kded4. I also attached xsession logs in case there is something interesting there. The test was done with the "lock screen" on close lid setting in the System Settings.

Created attachment 68546 [details]
kded and xsession logs

Sorry, these logs did not contain the test with the external monitor detached. The newly attached logs also contain this test.

> 1-killall kded4; sleep 1; kded4 --nofork (we will need this output)

The funny or strange thing is that after executing this code on lid close the system sleeps like it should on my Thinkpad T420 Intel HD 3000 system :P

(In reply to comment #53)
> Created an attachment (id=68546) [details]
> kded and xsession logs
> 
> Sorry, these logs did not contain the test with the external monitor detached.
> The newly attached logs also contain this test.

Do you have an external screen connected and activated in a DisplayPort? if so is normal that the laptop doesn't go to sleep since you may want to use only the external screen while the laptop is closed.

(In reply to comment #55)
> Do you have an external screen connected and activated in a DisplayPort? if so
> is normal that the laptop doesn't go to sleep since you may want to use only
> the external screen while the laptop is closed.

See my comment #39. Also, I tried with the screen detached, it doesn't work too.

(In reply to comment #56)
> See my comment #39. Also, I tried with the screen detached, it doesn't work
> too.

Can you attach the log in that situation? also would be nice if you could try removing the external screen via the KDE tools and the command line.

by the command line it would be something like:
xrandr --output Display_Link1 -off

Created attachment 68641 [details]
kded and xsession logs - external monitor disabled in KDE

Re-collected logs with external screen disabled in the KDE display settings. As before, locking the screen on lid close did not work.

I tried also to disable the screen via xrandr command line but it didn't work - xrandr always showed some errors and didn't disable the screen.

BTW, my last logs also contained the same test, but I physically detached the screen rather than disabling it in the KDE display settings.

Do you have the battery plasmoid? can you try removing it?
> Created an attachment (id=68641) [details]
> kded and xsession logs - external monitor disabled in KDE
> 
> Re-collected logs with external screen disabled in the KDE display settings. As
> before, locking the screen on lid close did not work.
> 
> I tried also to disable the screen via xrandr command line but it didn't work -
> xrandr always showed some errors and didn't disable the screen.
> 
> BTW, my last logs also contained the same test, but I physically detached the
> screen rather than disabling it in the KDE display settings.

Created attachment 68650 [details]
kded logs

I removed the battery monitor plasmoid and disabled the external screen in KDE display settings. Then it worked (at least once, I didn't try more).

However, with external screen enabled, closing the lid either doesn't do anything (the external screen is not locked and still works), or simply disables the external monitor (when the lid is opened again, the screen enables, not locked). I'm attaching kded logs for this last test (with external screen enabled).

(In reply to comment #60)
> Created an attachment (id=68650) [details]
> kded logs
> 
> I removed the battery monitor plasmoid and disabled the external screen in KDE
> display settings. Then it worked (at least once, I didn't try more).
> 
> However, with external screen enabled, closing the lid either doesn't do
> anything 

That's exactly the featur we have implemented... I guess that having it enabled by default is not as good as we thought.

(In reply to comment #54)
> > 1-killall kded4; sleep 1; kded4 --nofork (we will need this output)
> 
> The funny or strange thing is that after executing this code on lid close the
> system sleeps like it should on my Thinkpad T420 Intel HD 3000 system :P

I second that. After issuing those commands, everything works just fine...

Created attachment 68690 [details]
xrandr output

xrandr output

Created attachment 68691 [details]
kded4 output

kded4 output.
Shows the working times and the last 2 lines is none working.

I have this bug on KDE4.8 and it worked as it should in 4.7.4
I tried "1-killall kded4; sleep 1; kded4 --nofork (we will need this output)"
and everything worked for some hours but then it stopped working.
I didn't apply your patch since my monitor doesn't seem to be eDP.
Graphics card lspci:
"VGA compatible controller [0300]: ATI Technologies Inc RS780M/RS780MN [Radeon HD 3200 Graphics] [1002:9612]
        Subsystem: Toshiba America Info Systems Device [1179:ffb0]
        Kernel driver in use: fglrx_pci"
Toshiba laptop with no extra screen attached only built in.

Sorry for spaming when i uploaded my attachment i misunderstood the comment field.

Created attachment 68701 [details]
kded4 output try 2

I uploaded wrong log before this is the right one.

(In reply to comment #66)
> Created an attachment (id=68701) [details]
> kded4 output try 2
> 
> I uploaded wrong log before this is the right one.

Can you remove the battery plasmoid?

Created attachment 68740 [details]
kded4 output try 3

With battery plasmoid removed.

Thanks everyone for the info provided so far. It's by now blatantly clear that KRandr was just part of the issue. We need to find out which application(s) are playing the bad guy, or if we have a more serious bug in the agent (which I see unlikely given the logic). For this purpose, I urge those who can to apply this commit http://commits.kde.org/kde-workspace/1f68e12cd8ac310f75eb7f8d62b0a7afe8aad601 to their copy, and send us a kded4 log. This will help in making clear which application or service is killing your suspend.

kded(1515) PowerDevil::PolicyAgent::AddInhibition: DBus service  ":1.285"  is requesting inhibition
kded(1515) PowerDevil::PolicyAgent::AddInhibition: Added inhibition with cookie  2  from  "ApperSentinel"  with  ""
kded(1515) PowerDevil::PolicyAgent::addInhibitionTypeHelper: Added interrupt session

kded(1515) PowerDevil::PolicyAgent::AddInhibition: DBus service  ":1.102"  is requesting inhibition
kded(1515) PowerDevil::PolicyAgent::AddInhibition: Added inhibition with cookie  1  from  "ktorrent"  with  "KTorrent is running one or more torrents"
kded(1515) PowerDevil::PolicyAgent::addInhibitionTypeHelper: Added interrupt session
kded(1515) PowerDevilDPMSAction::onUnavailablePoliciesChanged: Restoring DPMS features after inhibition release

After I killed off both of these, I was able to suspend. I'm not sure how KTorrent should handle inhibition (maybe a configuration option, or default to uninhibit?) but the current status sucks. ApperSentinel is a little different, I guess since it's using packagekit. Would hate to inhibit while updating a system and things explode horribly.

There we go. Yes, ApperSentinel IMHO is doing the right thing here, whereas KTorrent definitely not. Just out of curiosity, are you downloading torrents or does this happen even when KTorrent is idle? Probably this behavior should be configurable in KTorrent and disabled by default

I have one download active but with 0 seeds, so it's not doing anything. I have a number of uploads running but IMO inhibiting based on upload count is Bad™. Shall I open an issue with KTorrent?

It looks like ApperSentinel is always running and sets the inhibit even when it is idle (I don't see a system tray icon or any activity for it. That should probably have an issue opened as well as it should only inhibit when there is activity.

Definitely. Inhibition should be made just when suspending the session might be dangerous or getting in the way of the user while he's in front of the screen. Thanks for opening issues for both components, which apparently are not behaving correctly.

Open issues added to Depends On. If anyone else finds anything else that is inhibiting, please open an issue and add this bug to the Blocks section at the very bottom of the bug report.

For me it was ktorrent as well.
Killing ktorrent made it work again.
The only other application adding Inhibition was vlc, but thats correct since i enabled option "Inhibit the power management daemon during playback".
kded(2899) PowerDevil::PolicyAgent::addInhibitionWithExplicitDBusService: Added inhibition from an explicit DBus service,  ":1.102" , with cookie  2  from  "vlc"  with  "Playing some media."

So i am of to 294021

I guess i rushed into conclusion.
How has powerdevil changed the way it honor this since 4.7.4 since there it worked as it should.
Before applications pinged there alive and Inhibition worked when i closed my lid.
But now it doesn't with the same setup.
I played with vlc in older kde4 and there it works when i close my lid during playback but with same versions of vlc in kde4.8 it doesn't.
I don't say that the new way is wrong but maybe it needs an option for the old way (with old way as default), or every application "pinging i'm alive" will cause this malfunction.

For everybody using ktorrent: 

The behavior that ktorrent inhibits sleeping when torrents are running can be turned of in the settings of ktorrent. (Configure KTorrent -> Application -> Suppress sleep when torrents are running)

@Nille: by now lid close works as an implicit event, differently from 4.7. We are looking into making this behavior configurable as I reckon some people, like you, expect their laptop to suspend nonetheless.

(In reply to comment #79)
That would make me happy :)
I use it so it doesn't suspend while i use the application but when i close the lid it should suspend.
Make it configurable would be the best solution.
A big thanks from me :D

I just came over here while experiencing the same issue. In my case too, KTorrent was the culprit. 

But, my point is, should one 'rogue' application be able to control the event handling of the system especially in a potentially negative way? 

The powerdevil settings should be supreme. They can receive the requests from any application running, should they respond to the request should be based on some kind of configuration. The best would be to create a policy. Each application has some priviliges. Like KTorrent is not able to inhibit locking of screen, but an Okular Presentation Mode is. This should be configurable by the user. And like the power management kill switch in the battery management widget, we can have a event management kill switch. If that switch is enabled, all these application specific policies can be followed. If it is disabled, then some system-wide policy can be followed which can either listen to all applications or listen to none. 

If it is required, I am willing to help develop code for this.

I am afraid a per-application policy mechanism would not work, and most of all defeats the whole purpose of an inhibition system, which allows *external* applications to be able to follow requirements on the system - or in case you wanted to cover this case, the UI and the mechanism would be too complex. Also, we are not talking about controlling the events of the system but just to prevent implicit actions to be undertaken, which is quite different and something you can find in pretty much every power management infrastructure around - we have to trust applications on doing the right thing.

The only doable thing in the context of what you said is to prevent any application from inhibiting, but I don't like this and I fail to see where it would be useful. For 4.8.1 we got a string exemption to configure RandR and lid close behavior, which should pretty much fulfill any possible request. This way lid close can be treated as an explicit event again, in fact fixing the subject of this bug and everything which follows. Once those two things are in, there is no longer a reason for preventing any application from suspending, as if this behavior annoys you, you either have to suspend manually or close the lid - the only action which will be prevented will be suspension after a certain amount of idle time.

In the meanwhile I'm changing the component to Solid again, as apart from the depends bugs this requires a couple options to be added to be 100% fixed, as stated above.

Hi, I have this issue on:

- System with kde 4.8 final
- Intel graphics
- No external monitor (though I periodically attach and detach an external monitor, I see the issue when I do not have the external monitor)

and I see the 

kded(22291) PowerDevil::Action::trigger: Unsatisfied policies, the action has been aborted

in the xsession errors

Please *RISE* priority. It is the second time that I almost FRY my laptop in the bag, I completely drain the battery and I get the laptop switching down without syncing. This is a situation that may lead to damaged hardware (due to the excessive heat) and/or in data loss (due to hard disks heating too much or un-synced switch off).

Also, if you want to have policies in place that inhibit the expected behavior (the one that is reported in the power devil dialog, namely to suspend on lid close), please be so kind to document that. IMHO there is nothing worse than having a system that makes you some promise through its user interface (I'll suspend on lid close, full stop) and that then ignores that promise and behaves differently (maybe sometimes I'll not suspend on lid close and I am not telling you in what cases muwhahaha!!!).

Also please update update bug title. This should be

powerdevil 4.8 final: regression: does not react on lid close events due to policies

@Sergio, this issue has already been fixed in faulty applications for 4.8.1 as you can see in comments above and in "DEPENDS" bugs. I am waiting for the approval of a string exemption for 4.8.1 to introduce an option to configure whether lid close should be considered an explicit event or not, restoring the explicit behavior as default, to close this bug. However updating Apper/KTorrent should be enough already for fixing this behavior on your machine.

P.S.: Dramatizing bug titles doesn't actually help in solving them, and this bug has been on top of our priority list since 4.8.0

*** Bug 294361 has been marked as a duplicate of this bug. ***

Thanks Dario for your explanation. Sorry for giving the idea of overreacting.

Yet, my intent was not to dramatize the bug title, but to assure that it is meaningful. When people consider upgrading, particularly to .0 versions, they tend to look at bug archives. This is why having correct bug titles is important. If the title says RC1, people tend to think that this is a bug that only appeared during the development cycle and not in the final version. Furthermore, it is quite common to search "regression" before upgrading, to see what the known regressions are. Hence, when something is known to be a regression it is useful to make it stand clear.

For some bugs, this is particularly important. When you manage convincing people to use a desktop or an os that is not the one their laptop came with, the last thing you want is them thinking that you gave an advice that lead to damaging their hardware or to data loss.

@Sergio: no problem. Although, you're missing part of the picture - if what you said was true, we'd have to change the bug title for every bug reported against a version which still is there in the next one. It's instead useful to know when a certain bug/regression/etc started to track the cause, strange enough, by changing the title you would remove information instead of improving them! And the status "reopened" is usually useful for tracking multiple appearances of the same bug. In the same fashion, we might go as far as saying that this was more a bug on its own than a regression, since it was caused by external applications.

That said, it's obvious that bug descriptions might be misleading from an user's point of view sometimes, but remember that the first target of a bug are developers and triagers, and the format should be as friendly as possible to them - *especially* for bugs like these with lots of comments and with a very high priority. The main expectation from an user should be not to have bugs more than being able to track issues on a bug tracker easily ;) though I reckon that in this specific case giving out more information might be very useful - I'll probably blog about this very soon to help spreading the news.

*** Bug 293334 has been marked as a duplicate of this bug. ***

This bug happens on my Asus Eeepc 1201T with ATI HD3200 (opensource drivers), too.

Ps. To anyone submitted a comment, please vote for this bug!

@Luca, voting doesn't help, and this bug is already 90% solved. Please read previous comments.

Git commit 1a493878fc65ea97872bd5b425c04b8f695f8f40 by Dario Freddi.
Committed on 22/02/2012 at 01:38.
Pushed by dafre into branch 'KDE/4.8'.

Merge branch 'lid-close-option' into KDE/4.8

Exemption for added strings for 4.8 granted.

CCMAIL: kde-i18n-doc@kde.org
REVIEW: 104001
FIXED-IN: 4.8.1

Signed-off-by: Dario Freddi <drf@kde.org>


http://commits.kde.org/kde-workspace/1a493878fc65ea97872bd5b425c04b8f695f8f40

Thanks to anyone involved who provided infos for fixing this bug - you've been really amazing. Tomorrow or the day after I'll blog on Planet KDE explaining all the action taken to fix this behavior and the newly added option for preventing applications from messing with your lid if you do not want to (which is from 4.8.1 the default behavior).

For those of you not following the planet: http://drfav.wordpress.com/2012/02/22/fixing-lid-close-suspension-in-4-8-1/

Thanks!!!

I have a quite similar problem but only since I upgraded to 4.8.1 and not in 4.8.0.

I am running openSuSE 12.1 with openSuSE kde4.8.1 rpms installed.
My problem is I can no longer hibernate my desktop. The machine hangs when I try and it always worked well nearly 100% when using 4.8.0 and before. My system also has an nvidia card and I am using the nvidia driver. 

The difference to this bug is, that the hibernation is not implicit eg by closing the lid of a laptop but its explicit by selecting hybernate in the KDE menu. I also tried to call pm-hibernate with the same result.

The result is, that the system is in a undefined state. The desktop remains visible, I can sometimes still close some apps like firefox but KDE is hanging and the only thing I can do is turn power off completely.

The thing I found striking and thats why I post this as a comment to this bug is, that it first happend with 4.8.1 exactly the version where this bug should have been fixed. 

Any idea

Thanks
Rainer