G-P-M on the wrong track?!

[Matthias Grimm]

On Mon, 17 Oct 2005 23:29:14 -0400
David Zeuthen <david at fubar.dk> wrote:

> You overestimate how complicated power management should be. Really,
> look at the interface HAL provides
> 
>  Suspend()              # put the system into low power mode
>  Hibernate()            # suspend to disk
>  SetLowPowermode(bool)  # called when transitioning to/from AC
> 
> and that's it. Note also we have hooks for different distros to plug in
> their implementation for they want to suspend. That's it. Maybe we'll
> add some selective suspend features to specific devices at some point
> but I doubt it. Maybe we'll add some methods to control laptop displays.
> But that's about it.

Ok. It seems that we have a slightly different understanding what
powermanagement is. I must confess that I often talked about a power
management daemon but in fact I meant a "Laptop" daemon. To get this in
line I analysed pbbuttonsd and divided its functions in two groups:
power management and laptop specific "nice to have" functions.

Power Management Functions
 1. dim the LCD backlight after some idle time
 2. put the machine to sleep after some more idle time
 3. don't perform 1. and 2. if a program is running that doesn't expect
    user interaction (compiler run, long download, view a DVD, etc.).
 4. put the machine to sleep on user request
 5. perform suspend-to-disk on user request
 6. check the battery regularly and warn the user if it is low
 7. put the machine in a safe state if the battery is critically low
 8. put the machine in a safe state if the lid is closed
 9. adapt CPU frequency policy depending on current power source
10. Switch off not used hardware (mostly done in kernel, difficult
    task for user space programs, therefore only very basic support for
    this is implemented in pbbuttonsd)
11. turn off HD spinning after some idle time and change kernel VM to
    support this (laptopmode script).
12. launch customer specific scripts at certain events (change of power
    source, lid close/open, change of power policy
    (powersafe/performance), etc)
13. change most of the behaviour described above depending on power
    source (time to dim, time to sleep, etc.)

Powerbook specific "nice-to-have" functions
 1. Connecting special keys with usefull functions (brightness, volume,
    eject CD, etc)
 2. Setting of keyboard illumination and LCD backlight depending on an
    ambient light sensor
 3. Reading not supported keys from the hardware and make them usable
    (in the future forward them to uinput)
 4. configure special hardware components which allows multiple modes
    (Trackpad and keyboard)
 5. Change the hardware modes (trackpad) on the fly through keys (see 1.)
 6. Activate the external video output through keys (see 1., speciallity
    of some Rage and Radeon graphic chips used in Apple Powerbooks)
 7. save hardware modes (see 5.) so that they survive suspend-to-ram.

Most of the points in the first group and point 2. of the second one
should only run once per machine, so I think the user session, where it
will be lauched once per user is not the right place. Beside this some
of the functions should also work if no user is logged in or even
depend on X. 

Most if the points in group 2 are hardware components that could be
represented by HAL and controlled by a desktop GUI (only setting and
reading of properties). 

> Oh, we also report about hardware like special laptop buttons but I
> assume that you are not unhappy about that. If you are, I'd be happy to
> address your concerns.

I always saw keyboard handling as kernels business and the new input
layer seems to work very well. If a key emits a keycode it could
easily be connected to any function with a whole bunch of already
existing desktop programs. Everything would be fine if the kernel
supported every possible key, but it doesn't and therefore sometimes
user space programs must fill the gap.

> Btw, it is my view that anything else related to power management should
> be handled in-kernel, e.g. run time power-management (dynamically
> adjusting power management of certain devices, e.g. suspend a USB
> thumbdrive using USB PM).

It does already a lot of that stuff, but some task are still left to be
done by user space programs :-)

> I cannot believe that this thread has gotten so big about something as
> petty and trivial as HAL offering *three* method calls to applications
> like g-p-m. What's the real issue here?

I was surprised too, but in fact I learned a lot. Basically I wanted
only to understand why G-P-M does things like it does them and what
role HAL has to play. I have developed pbbuttons for four years now and
got a certain view of PM and laptop issues in this time. I saw G-P-M
with its nice GUI and thought how I could adapt pbbuttons to
benefit from this project. A closer look to it showed some major
differences in design which I wanted to discuss because I still want to
benefit from G-P-M, and of course from HAL :-).

 Best Regards
   Matthias