Re: Moving DPMS to gnome-power-manager

[Richard Hughes <hughsient gmail com>]

On Thu, 2006-01-05 at 12:27 -0500, William Jon McCann wrote:
> Hi,
> 
> Following up from this discussion:
> http://mail.gnome.org/archives/screensaver-list/2005-November/msg00003.html
> 
> I think we've agreed to move the power management stuff into 
> gnome-power-manager.

Yes, I think a lightweight screensaver daemon shouldn't be logically
concerned with DPMS.

> So, what does this mean?
> 
>  From my list in the above thread, the GSPower API is used in the 
> following ways:
> 1. Power management is enabled/disabled and configured
> 2. Power management is activated/deactivated
> 3. Direct manipulation of power state
> 4. Monitoring power state
> 
> 
> I'm thinking that we make the following changes:
> 
> 1. Move the GConf keys and policy management to gnome-power-manager

Sure, good for me. I guess you mean the dpms_* keys currently in g-s.

> 2. Instead of activating display power management when the screensaver 
> starts, gnome-power-manager can activate it when the session goes idle 
> (in response to SessionIdleChanged).  This will allow it to work even 
> when the screensaver is disabled.

Yup, also okay.

> 3. Probably still need to do manually turn on the display when we get 
> "poked".  Or alternately, we can use a g-p-m D-Bus method to turn the 
> display power on.

DBUS method is good for me.

> 4. Maybe the best thing is for g-p-m to emit a signal when the display 
> power is changed.  g-s could then just watch for that.

So, we need a DPMS API for g-p-m:

typedef enum {
        POWER_MODE_ON,
        POWER_MODE_STANDBY,
        POWER_MODE_SUSPEND,
        POWER_MODE_OFF
} PowerMode;

void DpmsPowerSet (int PowerMode)
int DpmsPowerGet (void)

Or should we break out these individually like:

void DpmsPowerSetModeOn (bool);
bool DpmsPowerGetModeOn (void);

And presumably emit:

DbusStateChanged

Incidentally, what is the practical difference between
GS_POWER_MODE_STANDBY and GS_POWER_MODE_SUSPEND?

> There is also the question of what to do about HAL-less systems.  My 
> view is that people concerned about that will submit patches.

Sure, I'm sure g-p-m could build without hal (but it wouldn't do much)
with a few ifdef HAL's in the right place.

> Anything I'm missing?  Richard, what do you think?

Sure -- do you feel confident hacking on the g-p-m codebase, or do you
want me to implement this? I definitely need help with the API design.

Richard.