org.freedesktop.PowerManagement

[Richard Hughes]

On 22/03/07, Holger Macht <hmacht at suse.de> wrote:
> On Tue 20. Mar - 21:50:20, Richard Hughes wrote:
> > I want to restart discussion on the previously discussed session power
> > management interface: org.freedesktop.PowerManagement
> >
> > I'll outline something rough (and similar to what is already being used
> > in gnome-power-manager) and we can argue / discuss about names or
> > features.
> >
> > If we get the obvious bits sorted, then we can work on descriptions, API
> > subtleties and that sort of thing.
>
> I fully agree on this. Let's get something small and stable and we can
> discuss details later on.
>
> > == Methods ==
> > void Suspend (void)
> > void Hibernate (void)
>
> ACK.

Cool.

> > void Reboot (void)
> > void Shutdown (void)
> >
> > gboolean AllowedSuspend (void)
> > gboolean AllowedHibernate (void)
> > gboolean AllowedReboot (void)
> > gboolean AllowedShutdown (void)
>
> Just curious why we need this Reboot and Shutdown related methods in this
> API at all.
>
> Yes, generally they're somehow related to Suspend and Hibernate, but isn't
> this something that should be available regardless of power management?
> I'm not quite sure how this is handled in KDE and GNOME these days. The
> desktop has to provide these methods with no regard on any power
> management applications. If there's no gnome power manager or kpowersave,
> you still want the user to shutdown or reboot, no? Shouldn't they be in
> the desktop base somewhere?

I do see your argument, but I think they "fit" here. Say we just have
a distro update program that just puts up a dialogue "Updates
installed, restart?" then this simple program can fire a method off to
o.f.pm, which in turn can talk with the desktop environment and close
down applications and save state. Then the session pm service can call
o.f.Hal to actually do the restart.

This way we can integrate a common "restart" API call on top of very
different session saving technologies, e.g. what GNOME and KDE use
now.

> > int GetBacklightBrightness (void)
> > SetBacklightBrightness (int)
>
> ACK.

Cool. This lets the session service do some quite nifty stuff like
dimming on idle.

> > boolean GetLowPowerMode (void)
>
> This method, is it the same as the one exported by HAL? I mean, the one
> that comes from pm-utils?

No, it's a user preference version of it. Imagine this method
returning false when we are on AC, or > 50% on battery, but returning
true when <50% of battery. That point where the system is "low" is
probably best defined in the session, so KDE can make it configurable,
and gnome can hardcode something semi-sane. ;-)

>  If so, I think we shouldn't duplicate it
> here. In the future, KDE 4 or gnome 3.x should be tied as close as
> possible to HAL IMHO.

Agree. I can't even start most of GNOME without HAL anymore...

> So every application in either desktop session
> should have a very easy way to query capabilities on HAL provided by the
> desktop anyway. Why the duplication?
>
> > boolean GetAcState (void)
>
> Just to clarify that I understand that this one isn't a duplication of HAL
> and that you might have more than one AC adapter or an UPS and the desktop
> application providing the API has to logically sum them up.

Sure, agree.

> > string GetDescription (void)
>
> Can you give an example of what this method might return?

Well, it depends on the user preferences, the desktop envirnment and the locale.

Typically it would be something like:

"Computer is running on battery power\n
1 hour 17 minutes remaining"

But this is obviously down to the user preference settings, and what
the DE want's to show the user. For OLPC it might just be something
like "Battery 50%", but it's something that any random application can
use as a general description of the power state of the machine.

This is not critical to the spec, and I don't mind punting it for now
if there is not agreement.

> > string GetIcon (void)
>
> Can you elaborate a bit on this please? It still seems to be misplaced to
> me. Shouldn't those icons be defined by the theme? And shouldn't one be
> able to query its details anyway?

Sure, again see above. It's just a random icon we can present to the
user, which probably should have it's names defined in the icon naming
specification or something.

At the moment, I've got this returning a string like
"gpm-charging-080" which is a g-p-m specific icon.

Again, we can punt this for now if you want; there are much more
important things to decide on.

> > == Signals ==
> > int BrightnessChanged
> > boolean AcStateChanged
> > boolean LowPowerModeChanged
> > string DescriptionChanged
> > string IconChanged
> >
> > 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.
>
> ACK. I also think that some of the discussions taken place here are going
> too much into detail. We should really agree on a minimum set and can
> extend it later on.

Sure, either to the base interface, or just adding extra interfaces
(org.freedesktop.PowerManagement.Ui?).

Thanks for your help with this, it's really appreciated.

Richard.