Opened 8 years ago

Closed 8 years ago

#1429 closed defect (fixed)

Screen saver needs implementation...

Reported by: jg Owned by: JordanCrouse
Priority: high Milestone: BTest-4
Component: x window system Version:
Keywords: power Cc: jg, ajax
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no

Description

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.

Change History (6)

comment:1 Changed 8 years ago by jg

  • Keywords power added
  • Verified unset

comment:2 Changed 8 years ago by JordanCrouse

  • Status changed from new to assigned

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.

comment:3 Changed 8 years ago by JordanCrouse

  • Verified unset

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.

comment:4 Changed 8 years ago by 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).

comment:5 Changed 8 years ago by 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.

comment:6 Changed 8 years ago by JordanCrouse

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.