Re: gnome-screensaver, new api calls requested :-)

[William Jon McCann <mccann jhu edu>]

Hi Richard,

I'm going to take this onto the screensaver list.

Richard Hughes wrote:
> I come with a request for more new stuff :-)
>
> Some laptops turn off the lcd backlight automatically when you close the
> lid, and I think about 90% of laptops fall into this category.
>
> The other 10% need some DPMS magic. I've been told the usual way of
> doing this would be to use "xset dpms force off" when the lid is shut,
> and "xset dpms force on" when the lid is opened.
>
> Knowing you have full control of DPMS in g-s, I was wondering if you
> could implement one or two more API calls (sorry!) something like:
> setDPMSPower (bool state) so instead of calling xset (which is a bit
> hackish) I could just use a simple DBUS method to do the state change.

Ah, but *should* we have full control of DPMS in g-s?  I'm not sure.


Let's look at what we do right now in gnome-screensaver.

All of the power management stuff is contained in the GSPower class. 
This is basically a singleton that is used only within the GSMonitor 
class.  The API for the GSPower class is very simple:

http://cvs.gnome.org/viewcvs/gnome-screensaver/src/gs-power.h?rev=1.2&view=markup

First, some terminology.  In gnome-screensaver, I use the term "enabled" 
to indicate a policy decision and the term "active" to indicate an 
operational state.

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

In more detail:

1. Power management must be enabled via a GConf key in order for it to 
be used.  When enabled, the times to be used to enter the different 
power management states can also be set via GConf keys.  These states 
are: standby, suspend, off.

2. Power management is activated when the screensaver activates (aka 
blanks).  Power management is deactivated when the screensaver 
deactivates (aka unblanks).  Activation reduces to: verifying that DPMS 
capabilities exist, syncing up the timeout values, and calling 
DPMSEnabled().

3. What I mean by direct manipulation is that we force DPMS into a 
certain state instead of letting the timers determine the state changes. 
 This is only used to force the display to turn on when the Poke DBus 
method is used.  The Poke DBus method is a way to simulate user activity 
which, in this case, will turn the screen on and pop up the unlock dialog.

4. We poll the system to detect changes in power management state.  The 
primary reason for this is to detect when the system transitions from 
the "on" state to one of the not-"on" states.  When this happens we stop 
running the visual themes on the screensaver window since they won't be 
seen.

Or at least that is how it is supposed to work.  :)


Does any of that really need to be in gnome-screensaver?  Let's see.

1. The UI for power management policy is part of gnome-power-manager. 
So, it probably makes sense to move these GConf keys to it as well.

2. When the screensaver activates a signal is sent over the session bus. 
 This signal could be handled by any program that listens for it.  This 
is inherently a racy thing.  However, the action in response to the 
signal is to set timers that in most sane cases would not act immediately.

3. Forcing the screen to be on isn't necessarily a control issue.  If 
control of the DPMS moved to another application that application could 
provide an interface for changing the state.

4. Monitoring the state doesn't require control.  If another application 
controlled the state then either the state could still be polled as it 
is now or the other application could emit a signal when the state 
changes.  Again, this could be racy.  However, we only use this for 
turning themes off when the screen isn't completely on.  We don't 
support turning the themes back on when the screen comes back on [1].


It seems to me that we aren't doing anything in gnome-screensaver that 
we couldn't do anywhere else.  The reason that the screensaver controls 
power management is mostly historical - there wasn't a better place for 
it at the time.

Now that you have created gnome-power-manager it seems like it might be 
the right home for this.

What do you think?

Jon


[1] The reason is that it doesn't have to.  In the case where the 
display turns on and the screensaver doesn't deactivate the display will 
eventually turn off again.  This case would almost always be the result 
of an accident.  For example, the keyboard or mouse of an inactive 
system was hit.