G-P-M on the wrong track?!
John (J5) Palmieri
johnp at redhat.com
Mon Oct 17 16:21:04 PDT 2005
On Mon, 2005-10-17 at 19:24 +0200, Matthias Grimm wrote:
> On Mon, 17 Oct 2005 11:58:35 -0400
> "John (J5) Palmieri" <johnp at redhat.com> wrote:
> > This is all stuff that is just better if we all collaborate on one
> > solution. The client are different but on the backend it seems
> > worthwhile. Powersave should really be moved to fd.o if we do go down
> > that road but that is a different issue.
> 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
> 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.
> - 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.
> - 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.
For the rest of your mail, let's take it one step at a time. That first
step would be getting the right mix of HAL and daemon.
John (J5) Palmieri <johnp at redhat.com>
More information about the hal