org.freedesktop.PowerManagement

Richard Hughes hughsient at gmail.com
Thu Mar 29 11:50:36 PDT 2007


On Thu, 2007-03-29 at 20:42 +0200, Holger Macht wrote:
> On Thu 29. Mar - 16:25:51, Richard Hughes wrote:
> > On Thu, 2007-03-29 at 17:24 +0200, Holger Macht wrote:
> > > On Thu 29. Mar - 16:08:05, Richard Hughes wrote:
> > > > On 29/03/07, Holger Macht <hmacht at suse.de> wrote:
> > > > >1. Shouldn't we add a "time until wakeup" argument to the suspend call? I
> > > > >   imagine a vcr application calling suspend with this argument to wakeup
> > > > >   and start recording. Yes, something we can add later on.
> > > > 
> > > > Yes, but I don't know a single laptop this works correctly for. You
> > > > could argue the same about Standby, Hibernate and Shutdown. Maybe
> > > > another method TimedSleep or something?
> > > 
> > > Isn't it possible to define optional arguments?
> > 
> > With the raw DBUS I think yes, but using the bindings no, if I
> > understand correctly.
> 
> The problem I see is that it's nearly impossible to add such an argument
> after people actually start using it. An optional argument would be best
> IMO. If that's not possible because the bindings don't support it and
> nobody is willing to fix this up, I think we should go with the "0 seconds
> means disabled" thing David is proposing.

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

> > > > >2. You are calling one section "compulsory basic interface". So in case
> > > > >   you don't have a real power management application such as g-p-m or
> > > > >   kpowersave on the desktop, but 	 of course still need the shutdown and
> > > > >   reboot interfaces, someone else (the desktop base) has to implement all
> > > > >   of the others too? That seems unfeasible to me. Or am I getting
> > > > >   something wrong here?
> > > > 
> > > > Hmm. I figured they could all be just stubs that return NoHardware or
> > > > PermissionDeniedByPolicy or something like that. Maybe an error of
> > > > NotImplemented should be added to the spec. A stub in python is only a
> > > > few lines of code, and then we stop lazy XFCE (joke!) people from not
> > > > implimenting the whole base spec.
> > > 
> > > NotImplemented would be the only correct return value, but from my point
> > > of view, the interfaces wouldn't be compulsory anymore ;-)
> > 
> > Point taken. NotImplemented should be added the the 0.2 spec anyway IMO.
> > 
> > > I thing it has to be split and staggered in a more detailed way to become
> > > sensible because shutdown and reboot have an exceptional position and must
> > > be treated in a different way.
> > 
> > How do you mean split? You mean say that Shutdown() is optional but
> > Suspend() is compulsory?
> 
> Actually I still think that Shutdown() and Reboot() is misplaced here ;-)
> Those methods are available on _every_ system no matter if it will always
> be able to do any other power management related tasks. So they should be
> provided by someone who will be there also always.
> 
> I actually wonder why nobody else from the desktop people comment on
> this. I also wonder why this problem with shutdown and reboot didn't came
> up before and got defined somewhere else in the past. They seem important
> to me ;-) This should be of interest all desktops. I see three
> possibilities here:
> 
>  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.

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

>  3. We and/or the desktop people define those two methods somewhere else
>     to be mandatory. This way we could leave them optional in the o.f.pm
>     spec application. This would be my preference.

I don't think we should specify per-method to be compulsory, but
per-interface seems sane. What does everybody else think? Cheers.

Richard.




More information about the xdg mailing list