signalling suspend/resume events (deviceKit-power)
Dario Freddi
drf54321 at gmail.com
Tue Dec 8 15:14:51 GMT 2009
On Tuesday 08 December 2009 15:51:02 Richard Hughes wrote:
> 2009/12/8 Dario Freddi <drf54321 at gmail.com>:
> > But I think a better idea would be having the signal being streamed from
> > upower (since if the aim is providing an unique and future-proof system),
> > triggered from an hook in pm-utils. I think such a solution would be the
> > best of both worlds.
>
> You have to be careful with signals, as they are not blocking, I mean:
>
> user clicks suspend
> upower sends Suspending()
> _______________________
>
> pc is sleeping
> _______________________
>
> pc awakes
> upower sends Awakening()
> _______________________
>
> Applications get time to process the Suspending signal call.
> Applications get time to process the Awakening signal call.
>
> So you get a nice race.
Sure, that's why I'm most interested in the awakening one (I didn't really
make it clear in the first mail, sorry. I haven't really slept a lot last
night).
The idea is that an hypotetical AboutToSuspend signal would be streamed by the
daemon in the userspace (g-p-m or PowerDevil). That's also why I was skeptical
about the possibility of having the possibility to interrupt suspension, since
I believe this really belongs in the workspace.
The Awakening signal instead would be more useful and less dangerous. Let's
say that, in the end, the best solution for everyone could possibly be just
adding the Awakening signal.
>
> Richard.
>
--
-------------------
Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091208/ec9122e6/attachment.sig>
More information about the kde-core-devel
mailing list