Screen saver needs implementation...

[jg]

The back light enable should be controlled by the X screen saver; it currently is not. The DCON has facilities to be able to disable the backlight and screen without requiring the system to be woken up.

[JordanCrouse]

The best thing to do is to start out slow - lets set up DPMS to blank on DPMSStandby and to sleep on DPMSSuspend. Then we can start playing with the timer later.

[JordanCrouse]

On second thought - I'm not sure this is the right course of action. The screensaver and DPMS interfaces are designed to support a myriad of monitors and devices through a common interface, so you could take, say, your handy-dandy Xscreensaver and control virtually anything with it.

Obivously, due to our unique power policy, we're not going to be able to just stick on a generic screensaver and be happy with that. There will be entire periods of time when the screen will have to stay on (in e-book mode, for example), and there will be other times when we will want the screen immediately put to sleep and still other times when we want the screen to go off after a while. There will be a third party entity (third party in that it is separate from X and the kernel) that will be making these decisions. Obviously, we could just have that entity call the DPMS extensions to control the monitor through X if we wanted to, but I think it is more correct to have it call the DCON controls directly, rather then using the X driver as a proxy (which, will just turn around and use those same controls).

This of course is contingent on the establishment of a solid power policy, which we'll need to guide us in tasks such as these.

[jg]

Power managers interact with dbus these days to set such policy: and they use the dpms interface for controlling the monitors and flatpanels they support. This is how things like Totem tell the desktop not to invoke the screen saver on them.

So yes, the policy is set in a power management daemon on modern X desktops already. But I see no reason to implement it behind X's back, as X needs to be able to immediately wake up the system and light up the screen on user input (I don't want to add the latency of talking to an external daemon to that operation, nor the failure case of the screen failing to go back on because the power manager daemon is wedged) in the dcon case we already have hardware support to turn the screen back on immediately without waiting the frame latencies to reassert Geode control over the screen.

It may be that the dcon portion of the X driver should directly substitute its functions for dpms functions that normally talk to DPMS monitors and flatpanels; but I think it does belong in X, not done behind X's back.

In short, I see no good reason to do a one-off OLPC hack from the standpoint of the application environment; the architecture is there already, and it is failsafe so long as the X server is running (much more likely than the rest of the environment).

[JordanCrouse]

I correct myself again - Jim is right that X automagically re-enables the screen on user input. That feature alone makes X the most compelling candidate for this. However, this will preclude anybody else from really "owning" the DCON sleep mechanism - we're not going to restrict access, but it should be understood that X can and will change the values without consulting anybody else.

[JordanCrouse]

X driver now supports DPMS for the DCON - it turns sleep on for every mode except for DPMSModeOn. There is some discussion as if we want to enable the DCON blank mode, if we do, that will be invoked for DPMSModeStandby.

Closing as fixed. X and other daemons can use the DPMS extension to affect change.