Re: [gpm] Common system interface for PowerManagement



On Wed, 2006-10-04 at 18:22 +0200, Holger Macht wrote:
> Gnome-power-manager's and kpowersave's job as a policy decision maker is
> good, but it's only valuable when X is running. So a system level daemon
> which acts as a policy client before X comes up and which is started at a
> very early stage in the boot process needs to know when another client,
> such as gnome-power-manager, takes over the policy part or exits.
> 
> I'm currently facing this proplem with powersaved, which has to start up
> very early, but has to ignore some features like CPUFreq as soon as
> another client like gnome-power-manager or kpowersave start up. So I'm
> looking for a common solution all might agree on...
> 
> Therefore I propose a common interface on the system bus policy decision
> makers 'grab' with different priority.
> 
> It works as follows:
> 
>   1. System boots
>   2. System level daemon like powersaved starts up and grabs an interface
>      org.freedesktop.PowerManager (or similar) on the system bus with low
>      priority and the D-Bus flag DBUS_NAME_FLAG_ALLOW_REPLACEMENT
> 	      
>      Something like:
>  
>      dbus_bus_request_name(system_connection, "org.freedesktop.PowerManager",
> 	                   DBUS_NAME_FLAG_ALLOW_REPLACEMENT, &dbus_error);
> 
>   3. X starts up, a user logs in (or even in gdm) and gnome-power-manager
>      is started. g-p-m requests this name on the system bus with high priority:
> 
>      Something like:
> 
>      dbus_bus_request_name(system_connection, "org.freedesktop.PowerManager",
> 	                   DBUS_NAME_FLAG_REPLACE_EXISTING, &dbus_error);
> 
>   4. The system level daemon automatically releases the interface, gets
>      queued on it and from now on knows that there is another client, and
>      doesn't care about CPUFreq, etc. anymore.

There might be a small race here... though IIRC D-Bus can actually do
this for you (cf. REPLACE_EXISTING) if you pass the right option. Have
you experimented with this?

>   5. As soon as g-p-m exits, segfaults ;-), X shuts down or whatever, the
>      system level daemon automatically regrabs that interface and
>      therefore can care about CPUFreq and stuff until the client restarts
>      or another client starts up.
> 
> This behaviour would actually mean a oneliner in g-p-m to request the
> system interface. It even doesn't have to care about the return
> value. This would save me a lot of problems and patches ;-)

Notably it will work the other way around too. For Fedora I plan to
start g-p-m via an init script so if e.g. KDE's powersave applet can do
the same that'll work too when a Fedora user logs into KDE.. yes?

> What do you think?

Sounds good to me, I proposed something very similar right here

 http://bugzilla.gnome.org/show_bug.cgi?id=356174

with just using a wrapper in front of the daemon. If you're right about
no race when making the system bit release the interface when the
session bit requests it... then we probably don't need it.

Btw, this is reusable for other policy daemons too (g-v-m, nm-applet and
KDE equivalents) without too many code changes except for supporting an
option "--headless". But my proposal is mostly just an implementation
detail. 

Would be good with a generic spec proposed on xdg-list fd o about this
that defines the names

 org.freedesktop.PolicyManager.Power
 org.freedesktop.PolicyManager.Network
 org.freedesktop.PolicyManager.Volume
 ...

(prefer to use the prefix PolicyManager otherwise we'll clash with
org.freedesktop.NetworkManager when implementing this for the networking
bits). I think it might be as easy as just pasting your original email
in and generalizing it a bit further.

On a different but related note. Said spec could also define the
interfaces that were proposed here

 http://lists.freedesktop.org/archives/xdg-list/2006-May/008139.html

Would be good to get some consensus about those too.. though I'm not
exactly sure they are totally baked yet... But that's a different
discussion.

    David





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]