org.freedesktop.PowerManagement

[William Jon McCann]

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.

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

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

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

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

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

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

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.

Jon