expanding the inhibit spec

[Simon McVittie]

On 08/01/14 07:08, Ryan Lortie wrote:
> Eventually, if we are convinced that it is widely useful, we may want to
> add an additional API to deal with (what I consider to be the separate
> case of) delaying the suspend process for a short while:
> 
>   Delay (in  s what,
>          out h fd);
> 
> with "what" limited to "sleep" and the following semantics for the fd
> (from the client's viewpoint):
> 
>  - reads a \1 byte when suspend wants to occur
>  - replies by writing a \1 byte to say "okay.  i'm ready"
>  - reads a \0 byte when suspend has come back
>  - can close at any time to cancel the delay
> 
> This allows us to avoid having a PrepareToSleep() signal that must be
> emitted (in particular, when it must be emitted in the "welcome back"
> case in order for clients to re-establish their delays).

Having implemented "delay logout until we've tried to disconnect IM
connections" in telepathy-mission-control, in terms of the logind API
(which only has Inhibit and PrepareToSleep), I'm not sure that a
separate Delay API is really needed. You can get the same effect just as
easily by inhibiting suspend, and responding to PrepareToSleep by doing
whatever async thing you need to do (disconnecting IM connections or
saving files or whatever), then when that finishes, releasing the
inhibit "lock".

AIUI, logind already has a system-policy timeout after which it will
ignore inhibit "locks" (or at least those opened by unprivileged
processes) and suspend anyway.

For the concrete use-cases I've seen for this (apps prompting to save
documents, Telepathy disconnecting IM connections), we don't necessarily
even need the "welcome back" handling - the app could just get a new
inhibit fd when it goes back from "clean" to "dirty" state (the user
edits the document, or Telepathy reconnects the IM connection).

    S