org.freedesktop.PowerManagement

[David Zeuthen]

On Fri, 2007-03-30 at 09:23 -0400, William Jon McCann wrote:
> 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.

Yes, InhibitManual() sounds like it's broken by design; apps that update
firmware, system-wide things like yum, rpm, updatedb etc. should simply
use locks on the _mechanism_ (e.g. HAL) instead of using the session
interface. That will lock out session PM daemons too (if they are using
HAL)

(Of course, we haven't defined how locking on org.freedesktop.Hal.
Device.SystemPowerManagement will work just yet.. but I took it into
account with the new HAL locking API that went into HEAD earlier this
week. This is needed not only for this.. but also to make multiple
session-based PM daemons work for both fast-user-switching and
multi-seat.)

So, InhibitManual() should probably go and we should advise that
"system" apps simply lock the system mechanism. This makes a lot more
sense I think; Richard?

     David