org.freedesktop.PowerManagement

[David Zeuthen]

On Fri, 2007-03-30 at 14:52 +0100, Richard Hughes wrote:
> > 1. Other desktop
> >  - Desktop User A runs a software update tool or similar
> >   - Tool does Desktop Session A.pm.InhibitManual()
> >  - Desktop User A goes away while it runs
> >  - Desktop User B logs in
> >  - Desktop User B selects Power Off from the desktop menu
> 
> We don't let the user switch when there is a manual inhibit.

Of course we do; it's what the user wants. The answer here is simply
that Desktop User B is in charge. Of course, the desktop environment
provided by Desktop User B should tell Desktop User B that other users
are logged in and if she wants to continue shut down.

(BTW, the HAL mechanism might not allow Shutdown() for User B if other
users are logged in unless they auth or maybe not even at all depending
on permissions (this is the PolicyKit stuff).)

> > 3. Unwanted
> >   - Something calls InhibitManual
> >  - User A is late for a plane
> >  - Closes laptop lid
> >  - Desktop PM agent explains that powering off the system would be bad
> 
> Then we have policy. For instance, macbook hardware literally melts if
> you shut the lid when inhibited, and so g-p-m just ignores the inhibit
> on lid close if on a macbook. CD is a coaster, but hey, macbook is not
> molten :-)

Yes, that's the right thing to do. 

> >   I think it is similar in a fairly
> > deep way.  You can yank the USB key out and you can yank the AC power
> > cord out.  Both can be discouraged using "norms" but neither can be
> > prevented.  Also, presumably gnome-mount already asks HAL to "lock"
> > the device it is operating on so that someone doesn't click Unmount
> > etc.
> 
> I believe so.
> 
> > So, instead of ManualInhibit perhaps the application can set a lock on
> > the Computer device or similiar.  The advantage of doing this directly
> > to HAL instead of proxying it though desktop.PM is that it should be
> > simpler to get signals when the lock is broken.
> 
> If this stuff goes though the system layer it causes pain - plus I'm not
> sure logically inhibits go in the HAL layer, although you could argue
> they are like glorified locks. DavidZ, what is your view on this?

I think it's fine to have the one Inhibit() function (the one you call
InhibitAuto()) but it should note that there are no _guarantees_; e.g.
either if the user in front of the computer closes the lid / shuts down
or happily ignores the dialog either saying (if it's the same session)

 The application $APP  because $REASON

           [Cancel] [Shut down anyway]


or (if another session is active via f-u-s)

 There are other users logged in. They may lose their work if you
 shutdown the system.

                                      [Cancel] [Shut down anyway]

This is just fine; and you really don't want Desktop User B to see why
Desktop User A have called Inhibit (might be an information leak [1]).
Typically our society (some anyway) will make Desktop User B find
Desktop User A to ask what's up.

So I think the morale is this: The only guarantee that we give callers
of Inhibit() is that it _may_ show a dialog confirming the users action
but in some cases like "laptop lid close" that won't even happen.

Sounds about right?

      David

[1] : Let me put this in terms we can all understand: Suppose A=nerd
user, B=girlfriend of A. Support that A is burning a DVD and now B logs
in. B wants to reboot. You don't want B to see a dialog

 The user A is running an application that prevents Shut Down:
 Burning DVD "<some sketchy title of a movie>"

                                      [Cancel] [Shut down anyway]

if you consider the relationship between A and B.