signalling suspend/resume events (deviceKit-power)

[Victor Lowther]

On Dec 8, 2009, at 9:43 AM, Tobias Arrskog  
<topfs2 at xboxmediacenter.com> wrote:

> To bring more to the discsussion regarding uses of events at both  
> wakeup and suspends.
>
> On suspend apps can close sockets and signal disconnects properly to  
> servers (even if the server in itself probably should handle a wrong  
> disconnect it's nice to support it nicely).

Hmmm... I know that my common suspend use case involves closing the  
lid and putting my laptop in my backpack, so I want suspend to happen  
as quickly and reliably as possible, and waiting for network  
connections to cleanly shut down strikes me as creating another set of  
failure points. I would rather rely on userspace network apps cleaning  
up after themselves at resume if needed.

> On resume sockets could get reopened.
> In XBMC, LIRC comes to mind as a perfect candidate, it tends to need  
> reinitiate and we want suspend to behave transparently as shutdown,  
> so resume needs to look like a startup so we rescan and such.
>
> On Tue, Dec 8, 2009 at 4:36 PM, Tobias Arrskog <topfs2 at xboxmediacenter.com 
> > wrote:
> Sure I agree, I just made it quick (more as a proof of concept for a  
> patch I was working on).
>
> But glad to see that there is more than me that needs it atleast :D
>
>
> On Tue, Dec 8, 2009 at 4:34 PM, Richard Hughes <hughsient at gmail.com>  
> wrote:
> 2009/12/8 Tobias Arrskog <topfs2 at xboxmediacenter.com>:
> > I posted a patch a few weeks ago, It might have been overlocked or  
> just
> > uggly :)
> > Basically it did a dbus-event from pm-utils.
> > http://lists.freedesktop.org/archives/devkit-devel/2009-November/000527.html
>
> No, you need to define the signal in the DeviceKit-power introspection
> document and emit the signal from within DKp. I think doing this as
> pm-utils level is the wrong layer.
>
> Richard.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091208/c40ecd05/attachment.htm>