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

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:

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?


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

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