org.freedesktop.PowerManagement

[David Zeuthen]

On Wed, 2007-03-21 at 21:19 +0100, Oswald Buddenhagen wrote:
> > ===== Suspend ======
> > You have not got the permissions to suspend
> > Enter root password: [_______________]
> > 
> actually, i *am* going to. the login managers (can) do the same for
> complete shutdown, so there is no reason not to do so for "partial"
> shutdown (which also suspends network services, etc.).

In this case I would just make the login manager spawn the appropriate
program that implements the org.freedesktop.PowerManager D-Bus session
bus API and then the login manager calls into this policy manager and it
can pop up dialogs. So, if g-p-m or kpowersave both implements these
interfaces you can just start one of them.

Alternatively, you can implement these things yourself; a login manager
technically isn't part of the desktop session; e.g. it's normally a
trusted session where you are very careful about what programs you allow
to run.... As such, it's not really useful to have a D-Bus session bus
in the login manager; you normally, for security reasons among other
things, have very few programs running and historically these have had
little use for session-wide IPC.

Having said that... since code duplication is not always good... note
that the former is exactly what we're planning to do in Fedora 8 - we
want to run gnome-power-manager (g-p-m) or kpowersave (depending on the
user configuration) under GNOME's login manager (gdm) to handle power
management in the cases nobody is logged in. Ideally we can do this too
for kdm and other login managers.

(Btw, a really nice side effect here is that the user can use the g-p-m
configuration dialogs to handle such preferences - they are just copied
(somehow, it requires privileges) to the preference storage area of the
'gdm' user. Hence, normal users will probably get a "make these settings
system wide" button or something else magical. But now I'm drifting
off-topic. But I hope I've made the case for why this is useful clear.)

     David


> 
> > Either the user can suspend or not.
> > 
> quite simplicistic world view. :)
> 
> > > 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?
> > 
> ask the thin client user at the next desk to log out from this box.
> wait for a download to complete (okay, we miss quite a lot of
> infrastructure to actually detect such a situation).
> cancel/reschedule the cron job in ten minutes.
> i can go on forever ...
> 
> > > 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.
> >
> well, i figure. maybe a list of variants to start with. i haven't
> thought about this, yet.
> 
> > > > 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.
> > 
> i guess this is not what i'm saying, as i really have no idea what you
> are talking about. :}
> a policy brings together event sources, matches them against conditions
> and triggers actions. from may 2006 mail it should become clear that
> both the events and actions can be of very different kind, but still be
> subject to one policy. this also means one user interface, unless you
> want to make it completely incomprehensible (like the current dmps vs
> screensaver situation in kde). splitting the api by actions but still
> providing policy functions in them (fooAllowed) is just odd in that
> context, as all clients and all servers of these apis are the same two
> programs.
> 
> > 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.
> > 
> that makes your "standard" redundand, because a fully-fledged
> implementation would always opt for the latter (even if it would offer a
> simple frontend by default).
>