G-P-M on the wrong track?!

[Matthias Grimm]

On Sun, 16 Oct 2005 12:41:26 +0100
Richard Hughes <hughsient at gmail.com> wrote:

Hi,
and part III,

Power Manager
--------------------
> When I was designing g-p-m, I was going down the route that you
> explained. There was a system initscript that launched a daemon that
> spoke to HAL, and the daemon then spoke to g-p-m. This was so complex
> it was never going to work. Speaking to people, it became obvious to
> me (it was spelt out to me!) that this middle daemon was not required
> at all. The policy could be done in g-p-m as a user-session daemon.

You already split up g-p-m in two parts. One part becomes
the desktop part and everything else, you can't do without root
permissions, you graft on HAL. I thinks that is not very fair ;-) You
have still a daemon and a desktop application. Think about it.

> > Power management is too critical to lay it in user's hands. It is an
> > important system feature and must be handled by a system daemon
> > running with high privileges. No desktop program is able to fulfil
> > this task.
> 
> Why not? I'm a user, and I want to suspend my laptop after 10 minutes
> of inactivity. Assuming I'm logged in as a console user (i.e. sitting
> at the physical keyboard) I can set this to 10 minutes in g-p-p, and
> then g-p-m will use gnome-screensaver's information about my
> inactivity so that after 10 minutes, g-p-m tells HAL to suspend (hal
> calls the distro-specific scripts) and it "just works".

This approach reaches to short. your design expects that a user is
logged  in in X11, running gnome and gnome-screensaver to stick with
your example above. But you can't expect all people to work this way.

For instance I never use a screensaver. Nevertheless would g-p-m get
the idle information? Other users remotely log into their laptop and
expect that the power management will recognise this and allow working
even with closed lid. There are thousand methods people will use their
computer and the powermanagement must support them all.

And beside the simple suspend-to-ram example the daemon must handle much
more complex tasks such as controlling the LCD brightness depending on
an ambient light sensor, which raw signal is influenced by current the
LCD brightness and must be compensated before usage. Those and much more
tasks have to be implemented in HAL. Do you really think this makes
sense? Wouldn't it be better to put those functions in an seperate power
management daemon?

> >  part 2: a power management daemon that do the dirty work, provide
> >  data to HAL and receive orders from desktop programs through dbus.
 
> What "orders" would it take? What data does it provide? As soon as you
> start fleshing out the detail (i.e. formal design) it all gets
> horrendously complex.

Dbus signals to be defined as you defined the HAL API to set the LCD
brightness for instance. The design is not more complex as your current
approach. I already did something like this with pbbuttonsd and I'm sure
we are able to do it again, together. :-)
 
> > This concept has a lot of advantages:

> Why is that an advantage? On my system now, I can install g-p-m, a
> pretty recent HAL, and (potentially) remove:

[a whole bunch of daemons removed]

Yeah, it is always nice to get rid of some daemons :-) but you must not
forget that the programmers of this daemons had a problem to solve and
they focus only on that problem. They weren't interested in other
persons problems or in a generic solutions many people, even non
experienced users could use. As result this daemons didn't do very much.

Thats the doom of GNU/Linux: The hand-made scripts make the system
extremly flexible but unfathomable for normal users (that I am). Let us
find a middle way out of this dilemma.

> HAL does that job now. In KDE4 HAL plays a more prominent role.

Yes, I'm sure. But they also need the policy agent like g-p-m, for the
intelligence, don't they? They could use an independent power management
daemon without change but this is more the matter of distributors than
of desktop systems. The KDE people always have to implement the
configuration stuff themselves because of the Desktop Look&Feel but
don't have to care about policies and methods.

> > There are still a lot of questions to answer but I think this
> > concept is future proof and bring power management on Linux a step
> > forward. There are a lot of good ideas in G-P-M and a lot of highly
> > motivated and entusiastic people push it forward with breathtaking
> > speed
> 
> Urm... You trying to say I should get out more :-) I'm taking that as
> a compliment :-)

Yes, it is. :-) I would never despise someone else's work. All I want to
offer is ... lets say... some guidance ;-)

> There is a plan, but the plan keeps changing :-)

I see :-)

> > Also everything is eyed through the Gnome spectacles only but power
> > management is not a Gnome only issue.
> 
> Hence using HAL. HAL is cross platform and cross environment.

Sure, but we talk also about g-p-m here.

> > I have developed pbbuttons (power management daemon for Linus on
> > Apple
> > computers) for four years now and I would be pleased to join the
> > team
> > developing the new power management daemon I described above.
> 
> I've seen pbbuttons, and I'm quite impressed. There's lots of code
> that could be used by HAL directly (like the communicating with PMU),
> without the additional overheads of the another management daemon.

see above and in the mail regarding HAL.

> I don't want to be seen as obsoleting pbbuttons with g-p-m, as for
> powermac hardware, pbbuttons is by far generations ahead.

I wouldn't have a problem with this, if it is evolution, replace it with
something better, something more flexible. 

> The things is, pbbuttons is specific to PMU hardware which makes it
> unsuitable as a core GNOME application.

That's not true. PBButtons has a modular design and could also be used
on other platforms than powerpc. Only a low level ACPI module is
missing. There is some work in progress by a user but I don't know
exactly how far he is.

But that's not the point. Even I won't replace g-p-m with pbbuttonsd.
Furthermore I would like to combine the experience and knowledge of
both projects to create the generic power management architecture
everybody is dreaming of. Oh well ... or as close as possible to it :-)

 Best Regards
   Matthias