org.freedesktop.PowerManagement

[Richard Hughes]

On Fri, 2007-03-30 at 09:23 -0400, William Jon McCann wrote:
> Hey Richard,
> 
> On 3/30/07, Richard Hughes <hughsient at gmail.com> wrote:
> > On Fri, 2007-03-30 at 11:44 +0200, Danny Kukawka wrote:
> > > IMO it make no sense that KPowersave or any other powermanager on the
> > > desktop are only proxies to the real shutdown method of the desktop.
> >
> > It really does. Just think about gnome-format taking a manual inhibit,
> > and then starting to format a USB key.
> >
> > User clicks shutdown on the shortcut in the menu, and gets warned that
> > doing so is probably a bad idea.
> >
> > You just can't do that without a smart proxy (with inhibits) that
> > interfaces to the core desktop method.
> 
> On this one point... I think you've actually given a counter-example.
> Let's look at this a little closer.

Sure.

> By "manual inhibit" we are talking about the InhibitManual method on
> the session power-management interface.  While InhibitAuto "holds
> back" going into Sleep when the session is idle, InhibitManual (as it
> is designed now) tries to prevent the user from explicitly putting the
> computer to sleep etc.  Ignoring problems with the semantics of the
> name for now...

I know, I suck at naming... [quote:davidz]

> You've said in a few places that the use-case that this method was
> designed for is a variation on what you say above: something is
> modifying the system in a way that a sleep/wake, shutdown/restart, etc
> cycle will irrevocably break the system.
> 
> Does it satisfy this use case?  Actually, no it doesn't.  What about
> these cases:
> 
> 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.

> 2. No desktop
>  - Unattended/scheduled job runs something that modifies the system
>  - User A clicks Power off

Hmm. Classic system to session problem. You mean something like
updatedb?

> 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 :-)

> And there are a few others but I hope you get the point.

Yes.

> There is an important distinction between InhibitAuto and
> InhibitManual:  Auto is session policy and Manual is system policy.
> 
> And what does an application that consumes this interface need?
>  - a simple way to block changes on devices they operate on
>  - a way to get a notification if the block is broken
> 
> In the example you give for gnome-mount, how is a power change any
> different from removing the device?

We can solve 1 out of 2 cases, we can't control the user just pulling
the USB drive like we can't stop them switching the power off at the
wall - but they are not common cases we can easily solve.

>   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?

Richard.