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
_______________________________________________
Kde-hardware-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-hardware-devel
