org.freedesktop.PowerManagement

[Lubos Lunak]

On Saturday 31 of March 2007, David Zeuthen wrote:
> On Sat, 2007-03-31 at 10:07 +0200, Lubos Lunak wrote:
> > I'm still not quite sure Inhibit() even belongs to PM interface, I
> > cannot think of a single case when an app would want to block suspend
> > but would not want to block logout, so it'd always have to block both
> > of them. However the SM semantics (at least as they're in XSMP)
> > wouldn't allow blocking PM suspend by blocking SM logout. Not that I
> > have any better idea.
>
> There are at least two classes of applications
>
> a.  Apps that want to cancel logout; this could be some number-crunching
>     application that just operates on local files that lives in the
>     home directory of the user. These apps don't care if the system is
>     suspended/hibernated, but they do want to cancel logout.
>
> b.  Apps that depends on entities/services external to the session; e.g.
>     networking and devices. This includes 1) disc burning (you get a
>     coaster if you suspend the box); 2) downloading files (may take
>     hours so you don't want the box to suspend because the session
>     becomes idle); 3) probably other examples.
>
> Apps in class b. justify the Inhibit() method; they want to more than
> just block logout; their operation depends on external entities that may
> disappear if the system e.g. suspends / hibernates.
>
> So I think it's like this:
>
>  - Apps in class a. should just use XSMP (or Inhibit() on the proposed
>    org.fd.SM D-Bus interface); and
>
>  - Apps in class b. should use Inhibit() on the org.fd.PM D-Bus
>    interface.
>
> And as you note b. surely implies a. so the
>
>  - org.fd.PM spec needs to say that PM daemon implementing this
>    interface should/must use XSMP to delay and possibly cancel logout
>    if, and only if, someone is inhibiting the PM actions.
>
>  - the docs for Inhibit() needs to specify that the PM daemon will
>    delay/cancel logout via XSMP on behalf of the caller. This is
>    important because application authors need to know that they don't
>    have to do this themselves.

 It's a question if they don't. They still should if there's no org.fd.PM, 
which especially with the removal of shutdown/reboot from it is a quite 
possible case. Also, if developers of such apps would be bothered enough to 
handle this via org.fd.PM in the future, then they've already bothered to do 
this now using XSMP; and vice versa.

 But, given that I don't have any better idea, I'm not going to argue about 
this, if you think this is fine in org.fd.PM, ok.

> Sounds about right?
>
> > > Specifically, as you mention, existing PM
> > > daemons like gnome-power-manager, kpowersave etc. would just provide
> > > both "interfaces" until something better comes along to provide
> > > org.freedesktop.SessionManagement, e.g. for GNOME it . Notably we can
> > > extend this interface later on.
> >
> >  Yes. A session management providing merely shutdown/reboot/logout is
> > vastly insufficient and would basically just use the XSMP-provided
> > functionality (plus whatever starts the shutdown/reboot afterwards). I
> > originally suggested the org.fd.ShutdownManagement name because of this
> > but if this is meant to be extended somewhen in the future than I think
> > it can be called
> > org.fd.SessionManagement.
>
> Maybe we just punt org.fd.SessionManagement and tell apps in class a. to
> just use XSMP?

 XSMP doesn't have any support for shutdown/reboot. But if the aim of this all 
is just to create org.fd.PM interface than this is indeed an option :).

> I mean, at _some_ point someone will write a spec for 
> org.fd.SM or similar so apps can migrate from XSMP to something better
> and I don't think we should make it harder for them by defining parts of
> their interface in advance.

 I was first tempted to say that there can't be anything wrong about plain 
logout()/shutdown()/reboot(), but there actually can be - the shutdown done 
by clicking the shutdown button somewhere is quite clearly different from 
shutdown invoked e.g. from "shutdown-after-finishing-burning" DVD app (when 
there's an editor with unsaved changes the sooner should ask, the latter 
should somehow avoid that).

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz