G-P-M on the wrong track?!

[Matthias Grimm]

On Mon, 17 Oct 2005 19:21:04 -0400
"John (J5) Palmieri" <johnp at redhat.com> wrote:

> > IMHO this must be the main aim: To get a generic powermanagement backend.
> 
> Don't use the word generic.  What we need is a solution that is specific
> to power management.  Sorry nit-picky, but whenever someone tries to
> come up with a "generic" solution things end up bloated and
> unfocused.   

Ok, use a word you like if the result is what we lined out.
   
> > We won't have one generic power management daemon in the first step. The
> > differences between architectures are to big for this approach but we could
> > generalize the interface to the desktop.
> > 
> > So the fist steps will be:
> >   - define a power management infrastructure in HAL which a power
> >     management daemon has to fill
> 
> HAL should do this directly.

No, I don't agree. If we did so, we could stick to the current
solution. My idea is to have a power management daemon that collects
all necessary data it needs to work and could therefore take machine
and architecture dependent specialities into account (even repair
broken BIOSs). Then it fills certain data fields in HAL to provide
usefull information to desktop applications.

This concept will also work if HAL is not installed and it is not fixed
to one power management daemon. There are a hand full PM daemons out
there and each of them could still be used as long it fills the defined
fields in HAL to support the desktop applications.
 
> >   - define a power configuration setup in HAL which the PM daemon
> >     should take into account. Options set in HAL overwrite default
> >     options of the PM daemon.
> 
> Are options set in HAL?  I don't think this is wise.  I'm more apt to go
> with whatever powersave does for configuration and build on that
> (assuming power save is the way to go).  Initially I would just say
> extract the code needed for the daemon and get things working the way
> they do now while defining a common D-Bus interface.

I don't think there are options set in HAL yet. But If HAL should be
the common interface to the desktop, why not? There must be a way for
desktop applications to influence PM daemons behaviour. Of course this
could also be done with a common dbus interface but this will cause
some more bus traffic when a new applications asks for currently valid
settings.

One idea I had is: The daemon stores limited and well defined options
into HAL which the desktop application could read and, if necessary,
overwrite. But this is only an idea. I'm pretty sure that I could also
live with the dbus approach.

> >   - define a set of and dbus signal and methods for commands a user
> >     might want send to a PM daemon.
> 
> Just mirror what G-P-M does now and look where it intersects powersave.

Had you ever had a look onto pbbuttonsd? It doesn't use dbus yet, but
uses a similar message system. If we try to define a common interface,
we should take not only i386 and ACPI into account. My machine is a
PowerBook G3 with debian ppc on it and I would like to use the common
interface as well ;-). 

 Best Regards
   Matthias