[Kde-hardware-devel] PowerDevil prepareForSuspend signal

[Oliver Henshaw]

On 15 April 2013 17:42, Martin Briza <mbriza at redhat.com> wrote:
> I've come across this particular problem in suspension code while testing it
> in Fedora:
> If polkit requests authorization before suspension when locking the session
> on suspend is turned on, the session is locked before the user is asked for
> his password. This results in just locking the session and the password
> request typically timeouts.
> I've reported it here: https://bugzilla.redhat.com/show_bug.cgi?id=951174 .
> Possibly, it's reported in KDE bugzilla, too.

Odd that polkit is asking for credentials in the first place - I guess
something goes wrong when you switch user and back? Anyway, locking
the screen before being sure we have polkit authentication is also
reported at https://bugs.kde.org/show_bug.cgi?id=294712

> I've been thinking about the following solution and I've come to ask you
> what do you think about it and if it would be possible to fix it this way:
>
> While using login1 as the PowerDevil backend, the (in my opinion cleanest)
> solution would require adding a signal, for example "prepareForSuspend()"
> into the PowerDevil::BackendInterface.
> In suspendsession.cpp, we'd just have to move the locking code to the slot.
> moving the preparation (i.e. locking the session).
>
> The solution to the bug itself would be calling inhibit() from the login1
> dbus interface before calling suspend and closing the returned file
> descriptor after the screensaver is started. This would allow us to handle
> the PrepareForSleep signal of login1 which is emitted to notify the
> inhibiting applications to do all the actions required before suspension.
> The change to overall behavior of any other backend would be just emitting
> the signal right before suspending and waiting for return from the slot.

Quite possibly. It might be even better to have ksmserver take the
delay lock and listen to prepareForSleep to active the screenlocker.
That way we could have the screen lock even when something bypasses
powerdevil and tries to suspend directly. We could go even further and
lock the screen whenever the session becomes inactive (i.e. when
switching VT) - see https://bugs.kde.org/show_bug.cgi?id=309051 - this
might be controversial though.

This still leaves the problem of what to do when the lid is closed
though. With logind we can use the user_interaction boolean to specify
that the user can't enter a password with the lid closed. I think
something similar can be done with upower+polkit but it's less
elegant.

>
> Thank you for your opinions,
> Martin