org.freedesktop.PowerManagement

[Rob Taylor]

Richard Hughes wrote:
> On Wed, 2007-03-21 at 18:27 +0100, Oswald Buddenhagen wrote:
>> On Tue, Mar 20, 2007 at 09:50:20PM +0000, Richard Hughes wrote:
>>> I want to restart discussion on the previously discussed session power
>>> management interface: org.freedesktop.PowerManagement
>>>
>> instead of restarting it you might want to choose to continue it - that
>> would save us some time. ;)
> 
> Sure, things have moved on quite a bit with things like ConsoleKit and
> some of the new X stuff that is coming up.
> 
>> you can start by processing that one:
>> http://lists.freedesktop.org/archives/xdg/2006-June/008202.html
>>
>> in particular, your proposal is missing a way to express "you would be
>> allowed to shutdown/... if you proved to be in an authorized group
>> first". of course this example is a bit narrow-minded, but you get the
>> idea.
> 
> Well, it's up to the implementer of the API and the platform to define
> what conditions and precise stuff mean that a user is able to suspend.
> 
> I.e. if CanSuspend() returns true, then we should show the option in the
> UI, as Suspend() is likely to work. If we have not got an active
> console, or the admin has locked down the HAL interface or something,
> then CanSuspend() should return false as Suspend() will fail anyway, and
> there's no point the option being in a UI.
> 
> Does that make it a bit clearer? I really don't think we need to define
> shutdown states or anything so specific, I think that's more of a
> platform thing than a common abstraction.

Does it need a signal for the capabilities changing? e.g. if not on an
active console, or permissions have changed?


It might also make sense to just have a Capabilities bitfield rather
than seperate calls for Suspend, Hibernate, Reboot and Shutdown. You're
gonna call all of them at startup anyway, so makeing it one call reduces
bus round trip considerably.

>>> The inhibit stuff, the statistics stuff (and any other crazy random
>>> stuff) can wait until later, I would really like to standardize on
>>> something, so we can get some sort of standard sorted.
>>>
>> that's as wrong as it can get. you don't create apis which you know
>> might become obsolete in the next extension cycle.
> 
> Nothing becomes obsolete, I just wanted to start small, with a core set
> of methods and signals. We can discuss, and add to the API later when
> the core bits are being used, without breaking anything.
> 
> This sort of thing is traditionally really difficult to standardize on,
> and I don't want to make the job harder than it needs to be.

Sensible plan! The extensions can always be on a new interface.

>> even if you don't
>> want to finalize the bells and whistles yet, you should at least develop
>> a concept how to do it in a nice, consistent way.
> 
> Well, I really don't want to make a huge unwieldy specification that
> nobody is going to use. My primary motivation is to get simple stuff
> org.freedesktop.PowerManagement.Suspend() to work on both g-p-m and
> kpowersaved.
> 
> I also think it's quite important to keep the difference between a
> screensaver with idle detection, console detection, and power management
> user interaction for the sake of defining an API.
> 
> Does that answer some questions?
> 
> Thanks for the comments.
> 
> Richard.
> 


Thanks,
Rob Taylor
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg