Screen refresh rate should be dynamic to save power.

[jg]

Up to 100mw of power can be saved by controlling the refresh speed of the screen. This is very significant in Ebook mode.

Whenever the X server transitions from not drawing to drawing, the refresh rate should be increased to its normal 50hz at the next vertical retrace (being slightly more clever than just going non-idle may be worthwhile; we can use the damage facilities, I suspect, to know if the screen has been touched). Whenever the X server goes idle, the refresh rate should be dropped to a frame rate of (tbd) at the next vertical retrace. This will require cooperation with the device driver.

[gnu]

Unfortunately, slowing down refresh involves slowing the dot-clock rather than just inserting lots of time between the end of the last pixel, and the beginning of the first pixel of the next frame, the way old CRTs had a very long vertical retrace period to account for electron beam movement. The slow dot-clock means that we are stuck with a longer-than-usual delay before we can get either changed pixels, or changed settings (CPU image versus DCON internal image) to the screen.

Perhaps this can be re-examined in a Gen 1.5 or Gen 2 design. Programming the CPU video for a high speed dot-clock but only a few frames per second, would probably allow the refresh rate to be rapidly ramped up at all times. (If the CPU video is in vertical retrace when you ask it to change, it can just end the vertical retrace and start a new frame immediately. If it's in mid-frame, it can switch to the new vertical retrace timing at the end of that frame, immediately scanning out the next frame. I don't know if our current CPU video chips can change their vertical retrace timing on the fly without glitching.)

[jg]

The power savings is from the lower frequency. So I don't think this idea works.

[kimquirk]

Moving to next software release, Trial-2.

[JordanCrouse]

As per #734, we'll be putting the DCON into a lower dotclock when the screen is frozen. Changing the GPU rate is a nasty trick, and I'm not entirely sure we can lock in the DOTPLL that slowly (I guess I should do the math). I recommend we do #734 immediately, and then move this out to opportunity to consider later. It shouldn't be anywhere near our current release path. We should be hanging about in the DCON source mode most of the time now, as per ajax's work.

[ajax]

One thing I'm not clear on is how tolerant the DCON (and display proper) is to changing its refresh rate at arbitrary times. If it's just a clocked FIFO then in principle there's no reason we need to wait for vblank, and we could go immediately to the lowest power mode as soon as we enter DCON.

The current GPU only applies mode switch on vblank, so there's no real win to be had there. But that's okay. If you're animating, you want full speed updates, and if you're not, you want to be in the lowest possible power mode as soon as possible.

[jg]

Mary Lou thinks that the LCD will be happy changing the dot-clock mid-frame, and it will likely be invisible. If the dcon doesn't care, the LCD won't either.

[JordanCrouse]

ACtually, I'm way more worried about the CPU - changing the DOTPLL is a difficult event - we have to turn off the entire engine, switch the PLL and let it sync - thats a time consuming process. You might say that we can just do it while the DCON has the ball - but if thats the case, why even bother changing the GPU refresh rate at all? Turn off the GPU, and set whatever rate we want on the DCON - as per #734. Dynamically changing the GPU refresh rate is likely to be way more intrusive and delicate then we would like it to be.