I can only guess what you're talking about, but I assuem that this error message comes from kpowersave. 

I'm talking about this line:

KMessageBox::error(this, i18n("Suspend failed"));

from

void KMenu::slotSuspend(int id)

Andras: 
It's because kpowersave makes a dbus call to suspend which does not return until you resume.  Since the call timeout on dbus is 6 hours, kpowersave sees this error.  AFAIK the kpowersave guys are aware of it.

I see, this is why it happened only when I resumed in the morning. :-) I just wonder why Danny told me to assign this bug to the KDE guys. Or maybe I just misunderstood it.

Maybe I oversaw something, but I checked out kdebase3 via getpac and I can't find where the KDE menu call KPowersave for suspend. 

last comment in kdebase3.changes:
-------------------------------------------------------------------
Sat Nov 25 13:32:52 CET 2006 - coolo@suse.de

- correctly handle media mounted on startup (#223413)
-------------------------------------------------------------------

I can only find the error message togehter with code where KDE suspend via HAL directly. I can't find the dcop call. Because of this the problem is in KDE (or liblazy) and not in KPowersave.

Btw. Didn't we agreed to call as first KPowersave to suspend before fallback to HAL/D-Bus directly? I can't find this in kdebase3.

Reassign and CC Holger ... he can maybe say more about liblazy.

(In reply to comment #5)
> Maybe I oversaw something, but I checked out kdebase3 via getpac and I can't
> find where the KDE menu call KPowersave for suspend. 

The kickoff menu doesn't call kpowersave at this point in time yet.

> liblazy) and not in KPowersave.
> 
> Btw. Didn't we agreed to call as first KPowersave to suspend before fallback to
> HAL/D-Bus directly? I can't find this in kdebase3.

Yes, we agreed on this but it's not in because noone did it yet.

> Reassign and CC Holger ... he can maybe say more about liblazy.

We realized that liblazy is not suitable for calling a sleep mode in HAL because it has a fixed tiemout set (about 25 seconds). I can change this because I already did it for the powersave cmd line client. But it would be really helpful if some of the KDE guys could test it once finished.

But I will only do the old ksmserver menu stuff. Afterwards, I will reassign this bug back.

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

I'll attach a new patch agains the ksmserver shutdowndlg.cpp how it would look like in the build environment (after Re) which adds a function which sends a sleep request to hal, with INT_MAX as timeout and ignoring timeout errors.

I have no idea what's going on but KApplication::dcopClient()->send("kpowersave" ...) always returns true, regardless whether kpowersave is running or not. This seems to be a bug, no?

So at current point in time, with the attached patch, suspend only works if kpowersave is running. Reassigning because of this error and the kickoff stuff that still has to be done.

Created attachment 107023 [details]
ksmserver patch for the shutdown dialog

hm ... you can maybe try instead of the current dcop code this:

DCOPRef dcop_ref = DCOPRef( "kpowersave", "KPowersaveIface" );
DCOPReply reply = dcop_ref.call("do_suspendToRAM()");
if ( !reply.isValid() ) {
  // error case
}

Holger: a) send() is "send and forget". if you want to wait for a reply, use call(). 

b) it tries to start the process if it isn't already there iirc. 

why does it return a boolean then and why isn't it documented in the class reference?

Well, can you (or any other kde developer) please fix this when you are looking at the kickoff stuff? You surely have better possibilities then me to test this all.

The function send() works very similar to call(), only that it returns a simple bool on whether the signal could be sent or not - the "send and forget" part is only implied by not having a way to retrieve the return value :)

it is too late for RC3, we'll try to implement and test it after GA. 

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

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

liblazy uses send() instead of call() if passed a NULL DBusError, which we weren't doing.  Hopefully fixed in stable now.