On 15 April 2013 17:42, Martin Briza <[email protected]> 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 _______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
