org.freedesktop.PowerManagement

[Holger Macht]

On Thu 29. Mar - 15:22:42, David Zeuthen wrote:
> On Thu, 2007-03-29 at 19:50 +0100, Richard Hughes wrote:
> > Sure, I think I'm agreeing with you. Do we need such an argument for
> > Hibernate and Standby? I'm not thinking ACPI, I'm thinking ARM (and the
> > future).
> 
> Maybe Standby(), definitely not, by definition, Hibernate(). Keep in
> mind that the actual mechanism used might be very different from what
> you expect. So some embedded device might have what technically is
> SuspendToDisk but it's PM session daemon might advertise as suspend.
> 
> Please at least _try_ to keep the interface simple and come up with use
> cases before adding useless API like "time to wake up after suspend":
> Holger did for Suspend() (a mythical VCR app) and I think that's fine
> although it's a bit far fetched / academic in some way,

Ok, after thinking a little bit more about this, I think we should not add
the wakeup argument. And this for one reason: I think it is useful and I
think we should express it in the spec somehow, but not as an argument. In
regard to the rare amount of systems where it is supported, by using an
argument, we actually have no way to check if the system actually supports
it properly. We would just advertise that applications can use it, but
have no clue if it will do its job. So we should add an additional method
(TimedSleep whatever) in a future version as Richard already proposed.

> For the record, I also think it's pointless to advertise Standby() as by
> doing that you now force applications developers to make a choice
> between two very similar mechanisms (ACPI S1 vs. ACPI S3). That's a bit
> stupid I think, _we_ don't want app authors to even care about that.
> It's just a slippery slope.
> 
> (as an aside we don't even advertise Standby() in the HAL mechanism; the
> thinking is that HAL's Suspend() implementation might choose to do ACPI
> S1 if ACPI S3 is known not to be working on the system)

I basically agree with that. We don't need Standby() IMHO.

Danny, I think if there are systems where standby is actually working and
suspend to ram is not, Suspend() should do S1 behind the back of all
applications. And if there are systems where both S1 and S3 are working,
S3 should be preferred anyway. ACPI standby is really dead these days.

> The key here is to keep the interface as simple as possible. No needless
> API. Thanks.
> 
> > >  1. Either we keep shutdown and reboot mandatory like the other o.f.pm
> > >     methods, then all desktops have to make sure that _all_ those methods
> > >     are actually always implemented in the desktop session no matter of
> > >     any power management application. At least they have to return
> > >     NotSupported or the like.
> > 
> > My favourite.
> 
> You can't force something like that. There are still plenty of people,
> at least in my office (Red Hat), running twm. But that's fine;
> applications trying to use the D-Bus session bus will just receive an
> error that either a) there is no message bus; or b) there is no o.fd.P
> service.
> 
> > >  2. We all, desktop and power management people, agree that a power
> > >     management application is compulsory in every desktop session.
> > 
> > Well, the said application could literally be an 80 line python file.
> 
> What's the point? Just state that apps simply must be able to cope with
> either a) no session bus; or b) no org.fd.P service. There's nothing new
> in that; apps need to cope with errors.

The point is that you still might want to provide clever Shutdown() and
Reboot() methods for applications without the need to expose all the other
power management methods.

Regards,
	Holger