G-P-M on the wrong track?!

[David Zeuthen]

On Wed, 2005-10-19 at 20:06 +0200, Matthias Grimm wrote:
> 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)

Not even done in the kernel - runtime power management as I understand
is still something left to implement. As an aside I spoke to Adam Belay
(brilliant guy who I believe is still interning at Novell's Cambridge
office) during the GNOME summit about this. 

Specifically we discussed how to notify userspace of device power
transitions and I think the conclusion was somewhat that userspace need
only to get notified for "selective suspend" (e.g. the user willfully
turning off a device from the UI), all else would be transparent to
userspace in so far that we don't need something to watch out for it.

As an example, Adam told me that the e1000 wired networking driver can
be enhanced insofar that it completely powers down and only powers up
when a cable is attached to the transceiver. Note that userspace
wouldn't need to care, we'd still have the physical device
(in /sys/devices) and we'd still have the logical device from e1000
(in /sys/class/net) even though only the tiny circuit for cable detect
is powered on. The power savings for this is about 1w which is very
significant.

So I think it's a mistake to care about this in user space, but, hey,
who knows, the kernel side isn't even there yet. The only real example
of "selective suspend" that I can think of is that e.g. NetworkManager
wants to at least power off your wireless radio when connected to a
wired network. This is something only software like NetworkManager can
do because it totally depends on the complete policy you have for
networking devices [1]. But for this I see no need for the power
management daemon to be involved - the NetworkManager daemon (or
whatver) does this by just using HAL (or directly by using e.g. sysfs).

[1] : and in the event NetworkManager does Internet Connection Sharing
from e.g. wired to wireless we obviously don't want this.

> 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)

We just do things right and no customer specific scripts are needed. Oh,
if you do want this HAL already supports it but I'd rather see things
getting done right without customer specific scripts.

> 13. change most of the behaviour described above depending on power
>     source (time to dim, time to sleep, etc.)

This, except comments inline above, is pretty much what gnome-power-
manager / gnome-hardware-manager and the KDE, XFCE equivalents should
do. This was discussed pretty early on when Richard announced he would
start this project.

Clearly you want this daemon in the desktop session so it can read
settings using the desktop configuration system. Because if you don't
read settings from there you miss out on the great features that e.g.
gconf offers

 - lockdown
 - machine/site-specific defaults 
 - reading from LDAP
 - and so forth

Suggesting to read settings from a file in e.g. /etc is the old UNIX way
and I think at this point many many people think that config files
in /etc just isn't what we need in 2005. I'm curious if you agree?

To actually carry out this policy g-p-m/g-h-m just asks HAL to do the
"dirty work", hehe, which amounts to 

 1. Suspend(), Hibernate, SetLowPowerMode(bool) methods
 2. Read battery and AC properties from device objects
 3. Get some button pressed events (including lid etc.)

Oh, and given that HAL abstracts every single physical and logical
device we can easily handle UPS'es and other devices with batteries
(such as wireless mice, ipods 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.

Specifically point 7. I see as a duty of the suspend/hibernate scripts
until all this mess is properly fixed in the kernel / X.org. In Fedora,
we do this in our pm-suspend/pm-hibernate script, SUSE does something
else I believe and distro XYZ might do something completely different.
The point is really that we can abstract all of this in HAL be a
well-defined method, Suspend(), that has the semantics you expect from
something like gnome-power-manager: suspend the box and only return when
it has resumed.

For all of the points:

I believe that we for some time have trapped ACPI buttons. I believe
that Richard has patches for the IMHO rather stupid kernel modules
(toshiba) that use vendor-specific interfaces. Thus, we'll end up with
the same nice abstraction we already use for ACPI buttons. What's wrong
with teaching HAL about this? 

Remember if I'm e.g. IBM/Dell/Toshiba/Sony/whoever I can just send a
patch to the HAL mailing list and get support (or fix my driver or the
kernel to do the right thing)

> 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. 

Well, 99.999% of the time people are logged in. For the very rare and
very uninteresting case where people are not logged in my proposal is to
run g-p-m / g-h-m from gdm as user nobody and without any UI. Oh, you
also want to run the screensaver, this is exactly the same problem. 

A future framework (in GNOME) could do this as well as making sure that
the GNOME power manager instance for the session currently being
displayed only enforces policy - you want this to handle fast user
switching etc. I talked about that right here

 http://mail.gnome.org/archives/desktop-devel-list/2005-July/msg00170.html

Oh, btw, maybe you even want some specific UI such as displaying amount
of battery left on the login screen. The point, really, is that you  can
reuse much of the same policy enforcing code and still reap the huge
benefits of reading settings from e.g. gconf (lockdown,
site/machine-specific defaults etc.). And you may do this without X if
you so desire but I frankly don't see the point.
 
> 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.

I'm not terribly opposed to the "put special button events such as 'Web
Browser' on uinput" idea, it's something we can easily add.

> > 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 :-)

Yea, I still think most of the things we want belong in the kernel. I
mean, ideally users should never tweak power management policy settings,
our defaults should just rock.

> > 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 :-).

Yea, it's great to see how things are improving thanks to people like
Richard and yourself. These days I take it for granted that my laptop
suspends when I close the lid and when it comes up it does all sort of
intelligent things like reattach to the network and stuff. Things that
you expect to happen because it works so well in the other operating
systems.

Cheers,
David