[kde-workspace] /: block until the lock windows are shown; prevents sleeping before locking

[Oliver Henshaw]

This might be a little too concise, but hopefully it should be clear if you have
KSldApp::lock() in ksmserver/screenlocker/ksldapp.cpp up in front of you.

Hopefully I haven't left out any important details.

On 14 March 2013 11:18, Aaron Seigo <aseigo at kde.org> wrote:
> Git commit 62c2c398611b2e6ef6e1e38ed79bc9540fc02ec9 by Aaron Seigo.
> Committed on 14/03/2013 at 12:16.
> Pushed by aseigo into branch 'master'.
>
> block until the lock windows are shown; prevents sleeping before locking
>
> accomplished by:
>
> * synchronously calling desktopResized in the screen locker app
>     (this causes the locker windows to be created)
> * writing to stdout, and listening for readyRead on the ksmserver side
>
> this should probably go into the stable branch as well, but realy needs
> broad testing first given that it touches ksmserver, security, sleep, etc.
>

I'm sure this shouldn't be necessary because showLockWindow() should
have hidden the screen before startLockProcess() is called. But for
some reason this doesn't happen at all. This is true even if I sleep()
for 20 seconds after the showLockWindows() call so it can't simply be
a simple delay in getting the lock window to show itself, can it?

showLockWindows does seem to hide the screen at some point, because I
can see the black window if I sleep for a few seconds after the lock
process exits and before hiding the lock window when unlocking.

Sprinkling more sleeps around I can see that the screen stays visible
until UnlockApp::desktopResized() is called by the lock process. But,
as I say,  ksmserver should have hidden the screen before even
starting the lock process.

So what is going on?

> diff --git a/ksmserver/screenlocker/ksldapp.cpp b/ksmserver/screenlocker/ksldapp.cpp
> index 7f2e671..6a6fad8 100644
> --- a/ksmserver/screenlocker/ksldapp.cpp
> +++ b/ksmserver/screenlocker/ksldapp.cpp
> @@ -277,10 +277,13 @@ bool KSldApp::startLockProcess()
>      }
>      m_lockProcess->start();
>      // we wait one minute
> -    if (!m_lockProcess->waitForStarted()) {
> +    if (m_lockProcess->waitForStarted(60000)) {
> +        m_lockProcess->waitForReadyRead(60000);

This blocks for 60 seconds. I don't think the lockprocess is waiting
on powerdevil  (see explanation below) so it must be waiting on
ksmerver. Whatever it is, it happens before the
ScreenLocker::UnlockApp construction in
ksmserver/screenlocker/greeter/main.cpp

It blocks even if I return from KSldApp::lock() early (and continue
from startLockProcess() onwards on a timer) so that powerdevil isn't
still waiting for a reply from the dbus lock call when the lock
process starts. So surely ksmserver is the main candidate? I played
around with dbus-monitor and couldn't see any smoking guns, so perhaps
it's some other channel (xsmp?) or I just missed it.


The old screensaver had the lock process communicate that it was ready
by calling the org.kde.screensaver.saverLockReady() method over dbus;
krunner delayed replying to the Lock() dbus call until it was
notified. Perhaps that is the approach to take. I've rustled up some
code to attempt this but might not be able to test it until tomorrow.

But figure out what is going wrong with the lock window created by
ksmserver and none of this should be necessary.