org.freedesktop.PowerManagement

[Richard Hughes]

On Wed, 2007-03-21 at 20:02 +0100, Oswald Buddenhagen wrote:
> On Wed, Mar 21, 2007 at 05:56:33PM +0000, Richard Hughes wrote:
> > On Wed, 2007-03-21 at 18:27 +0100, Oswald Buddenhagen wrote:
> > > 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.
> > 
> that's not the point. i was talking about privilege elevation through a
> password dialog and similar.

That's not the job of a session power management interface. You're not
going to present to the user:

===== Suspend ======
You have not got the permissions to suspend
Enter root password: [_______________]

As that would be madness. Either the user can suspend or not.

> generalizing it, a simple "may/may not" answer might be insufficient, as
> the user might be able to change the situation.

How? Got any real-world use-cases?

> > 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.
> > 
> well, yes. but if you standardise something for which my only option is
> to ignore it, you have gained nothing.
> 
> > > 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.
> >
> then don't make it complicated. provide a series of hooks (through
> attribute lists and similar) that allow communicating with a policy
> framework.

Such as? It's easy to say, but putting into a generic interface is very
difficult. I really don't think we need anymore integration with the
backend as it's not suited for a session interface. The session
interface is mainly for the user interface and user interaction.

> > 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.
> > 
> i'm not that sure, obviously. they all meet at the mechanism to
> implement a policy. it seems silly to me to have a common policy
> framework in the deamons implementing the various power-related
> functions and on the client side glue code that brings together the
> policies of the separate apis again (it has to be presented to the user
> in a coherent way).

Sorry I don't understand - are you saying that we shouldn't split the
session and system stuff? If so, all the UI will have to abstract all
the hardware again, and we are back to abstracting HAL in each
application with no gain.

We need the session interface to present stuff that is trivial for
applications to process. Anything more, and they can query HAL directly
and do their own logic.

Thanks,

Richard.