[Kde-hardware-devel] PowerDevil prepareForSuspend signal

[Martin Briza]

Hi everybody,

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.

The problem here lies of course in the fact the PowerDevil code in  
suspendsession.cpp locks the session first and then suspends the session  
without caring about anything that can happen in between these two actions.

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.

If this is not okay with you, it's always possible to define the signal  
only for PowerDevilUPowerBackend and using qobject_cast but that would be  
just nasty...

Writing this mail, I'm starting to think it would be possible to call  
Inhibit method when the session starts and just listen to the dbus signal.  
But that's just a detail, it would require adding the prepareForSuspend  
signal to the BackendInterface anyway...

Thank you for your opinions,
Martin