[Kde-hardware-devel] PowerDevil prepareForSuspend signal

[Martin Briza]

On Mon, 15 Apr 2013 19:49:44 +0200, Oliver Henshaw  
<oliver.henshaw at gmail.com> wrote:

> 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

This happens when more users are logged in and one tries to suspend the  
computer... but it depends on how restrictive the polkit rules are, of  
course.

>> 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.

In my opinion, it would be better to keep this in PowerDevil to have all  
the logic regarding power management in the same class, also allowing  
cleaner implementation for other backends. Anyway, I'm easy to be reasoned  
otherwise.

> That way we could have the screen lock even when something bypasses
> powerdevil and tries to suspend directly.

Listening to the signal since PowerDevil is initiated and setting the  
inhibition lock achieves exactly the same effect.

> 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 rather sounds like regular user switching detection to me - which is  
handled in kworkspace. The session would just listen to changes on its  
Active property on the login1 interface.
I don't understand how it relates to suspending 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.

Well, there's not only this problem with getting information about the  
user being able to interact but also if we use this to suspend the  
computer without authenticating him, it completely denies all need to  
enter the password on laptops - why would I authenticate when I can just  
close the lid?
But there could possibly be other things we want to do before the  
suspension and I think having a hook like this could come handy.

Thinking of other backends, I admit I don't know much about them, I  
(completely selfishly) came to discuss functionality provided by systemd.  
Whatever I proposed with regards to them are temporary placeholders to  
provide the same functionality as before the change and to be easily  
replaced.