Re: [gpm] Re: Gnome 2.16 Module Proposal: GNOME Power Manager

[Matthew Garrett <mjg59 srcf ucam org>]

On Mon, Apr 10, 2006 at 06:02:53PM +0200, Holger Macht wrote:

> Ubuntu guys would also take it IMHO if there would be a gnome
> client for it. 

We'll take it if there's a gnome client /and/ it provides the same 
degree of useful functionality as g-p-m currently does. But I think 
we'll have the opportunity to discuss that later this week :)

> And power management is something real complex. It's not just popping up
> some notifications. It's definitely worth to reside in an own daemon like
> NetworkManager which has root privileges and can do CPU frequency scaling,
> throttling, harddisk adjustments, runtime device power management, battery
> management, proper suspend implementation, CPU hotplugging and a lot more.

Woah, hold on there. There's several issues involved here. Hal 
already provides mechanisms to trigger suspend, and it doesn't seem 
illogical to provide functionality like runtime device power management 
in there as well. If I select a wired network in NetworkManager, it 
makes sense for the device to be powered up. If it's going to be talking 
to hal to find out what capabilities the device has /anyway/, I think it 
makes sense for hal to be the basic interface for managing the power 
state. Otherwise NetworkManager has to start talking to the powersave 
daemon as well, which seems awkward.

I'd much rather have a user-level powersave daemon that collates 
available information (such as asking Networkmanager whether any devices 
are up or not) and makes policy decisions that are enacted via hal than 
have policy management and enactment more tightly coupled.

> Furthermore, we support all kind of systems, not only laptops. It's even
> very useful on servers. The daemon also cares about shutting down or
> suspend the system if battery runs low, even if no client is running. We
> have a notification architecture that just works in every environment:

Now, that's a slightly separate problem - that is, the fact that most 
DBus applications are focused on the "User logged in" case. David 
Zeuthen's been working on that, and I think there's a more elegant 
solution than "Run as root, and fall back to a default policy if there's 
no client".

>       - No client running but KDE installed: Daemon notifies user through
>         kdialog
>       - No client running but GNOME installed: Daemon notifies user
>         through zenityugly

And I'm really not sure that the "No client" case is one that needs to 
be concentrated on - if people disable chunks of their desktop, then 
they're going to lose functionality.

-- 
Matthew Garrett | mjg59 srcf ucam org