Version: (using KDE KDE 3.5.6) Installed from: Debian testing/unstable Packages On heavy load, when clicking on Lock & hibernate gets effectively the system into hibernation. The problem is that when resuming there could be a small amount of time (2-4sec) where the session is not locked. This is tested when not using uswsusp or hibernate scripts, when klaptop_acpi_helper forces the hibernation writing into /proc or /sys power interfaces. The problem is that the dcop call used for locking the system (send) is asynchronous (daemondock.cpp:500) so the hibernation starts without waiting for the locks is already done. This is filed after debian bug #416824 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416824
I propose a possible patch(currently untested) for this: --- daemondock.cpp (revisión: 650614) +++ daemondock.cpp (copia de trabajo) @@ -500,8 +500,11 @@ void laptop_dock::invokeLockHibernation() { DCOPClient* client = kapp->dcopClient(); + QCString dummyCS; + QByteArray dummyBA; if (client) - client->send("kdesktop", "KScreensaverIface", "lock()", ""); +// client->send("kdesktop", "KScreensaverIface", "lock()", ""); + client->call("kdesktop", "KScreensaverIface", "lock()", "", dummyCS, dummyBA, true); laptop_portable::invoke_hibernation(); } void laptop_dock::invokeStandby()
Well forget about the previous patch, after some more talk at #kde I got this better one (it even compiles :P ): -8<---- Index: daemondock.cpp =================================================================== --- daemondock.cpp (revisión: 650614) +++ daemondock.cpp (copia de trabajo) @@ -30,6 +30,7 @@ #include <klocale.h> #include <kpopupmenu.h> #include <dcopclient.h> +#include <dcopref.h> #include "kpcmciainfo.h" #include "daemondock.h" #include "portable.h" @@ -501,7 +502,7 @@ { DCOPClient* client = kapp->dcopClient(); if (client) - client->send("kdesktop", "KScreensaverIface", "lock()", ""); + DCOPRef("kdesktop", "KScreenSaverIface").call("lock"); laptop_portable::invoke_hibernation(); } void laptop_dock::invokeStandby() -->8------
The patch in comment 2 is currently being used in the Gentoo patchset. I would appreciate hearing back from the maintainer of the package on whether this is the best solution. I am told Debian are also using this patch. Thanks.
If you read in the Debian bug report at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416824 you can see this patch might not work.
OK, I'm the one to blame here. After some more researching I saw this patch was not working, even I think it did on 3.5.5. Anyway the problem is that it seems that you need to call attach() for the DCOPClient in order it to be useful at all. This is weird since I suppose that even the kde base code should call attach() and it does not. Here's a patch including this observations. Sorry for the nuissances. -8<---- Index: daemondock.cpp =================================================================== --- daemondock.cpp (revisión: 677152) +++ daemondock.cpp (copia de trabajo) @@ -30,6 +30,7 @@ #include <klocale.h> #include <kpopupmenu.h> #include <dcopclient.h> +#include <dcopref.h> #include "kpcmciainfo.h" #include "daemondock.h" #include "portable.h" @@ -501,7 +502,10 @@ { DCOPClient* client = kapp->dcopClient(); if (client) - client->send("kdesktop", "KScreensaverIface", "lock()", ""); + { + client->attach(); + DCOPRef("kdesktop", "KScreenSaverIface").call("lock"); + } laptop_portable::invoke_hibernation(); } void laptop_dock::invokeStandby() -->8------
Created attachment 20887 [details] Better patch (2rd try) I thought about this better option. Choose yourself. (Self reminder: think before write).
After some mail-listing and tests I went to find that none of the previous patches did the work properly. I was centered in using the DCOPRef object approach but this doesn't seem to work is a DCOPClient object is involved near. So the two options I thought are using DCOPClient as it is now, but adding the necessary changes to allow a DCOP call(synchronous) instead of a send call (asynchronous). First patch to follow. The other option is keep trying with the DCOPRef object and this involves adding the DCOPClient usage as I mentioned. Second patch to follow. I've tried both patches (now for real) and I saw it worked for me, but feedback is appreciated. As to what it more adequate to KDE I'm not sure, the DCOPRef approach seems cleaner and easier to me, but the DCOPClient one seems a little less(not much less, BTW) cleaner. So this is any KDE wise who has to take the decision in case this is deemed to be important. I also have to note that patches are just for the hibernate functionality, not for the suspend (to ram) functionality since the bug just covers the former functionality.
Created attachment 20947 [details] Patch to solve the problem using the DCOPClient approach. This patch uses the DCOPClient call() function(synchronous) to wait the desktop to be locked before invoking hibernate.
Created attachment 20948 [details] Patch to solve the problem using the DCOPClient approach. This patch uses the DCOPRef approach to make a synchronous call() that locks before invoking the hibernate functionality.
Created attachment 20949 [details] Patch to solve the problem using the DCOPRef approach. This patch uses the DCOPRef approach to make a synchronous call() that locks before invoking the hibernate functionality.
DCOPRef approached preferred :) You can probably remove the unused reply variable.
Thank you very much for the feedback, believe me when I say it's more than appreciated. I have no problem in doing as you say, but if you don't mind I will test it with those changes. The reason of including that variable is that this function has been a little tricky and I wanted to make sure that it was working. It worked like that but I was afraid it stopped working with slight modifications. I'll go for that right now... Regards,
Created attachment 20960 [details] DCOPRef patch with changes suggested. Here is the asked "one-liner" ;) Tested slilghtly, seems to work. Yet feedback is appreciated. HTH.
for me the DCOPRef approach doesn't work. The kde session is not locked after resume from hibernating. It works when using the "old" approach: client->send("kdesktop", "KScreensaverIface", "lock()", ""); I'm using suspend2/tuxonice with the hibernate scripts v1.96 under gentoo
Stephan: Could you tell us which exact version of kde are you trying with? and also if the command dcop kdesktop KScreensaverIface lock actually locks your desktop? Thanks.
I'm using kde 3.5.7 the command "dcop kdesktop KScreensaverIface lock" locks my desktop. If i activate the LockKDE command in the hibernate-script the desktop is also locked when resume is finished. Also the old method via 'client->send("kdesktop", "KScreensaverIface", "lock()", ""); ' in klaptopdaemon works. Only the DCOPRef method doesn't work.
OK if you don't get DCOPRef to work, let's forget about that. Doesn't matter much for such a simple call. Which patch works for sure, so that we can apply it to KDE? (there are multiple variants of the dcopclient send patch in this report).
Strange now it works also with the DCOPRef method. hmm maybe i have overseen a type-failure in one of the parameters when i copied the DCOPRef method to the sources. But i will recheck it with the last patch from Raúl.
OK i must have done a mistake when i copied the DCOPRef line. Because now it works also with the DCOPRef method. So this one-liner patch works for me now, too https://bugs.kde.org/attachment.cgi?id=20949&action=view
SVN commit 721296 by dfaure: Apply patch from 143859, fixing lock & hibernate. "The problem is that the dcop call used for locking the system (send) is asynchronous so the hibernation starts without waiting for the locking being already done" BUG: 143859 M +4 -3 daemondock.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=721296