gta02 framebuffer decay on suspend

Andy Green andy at
Sat May 31 22:07:43 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> Somebody in the thread at some point said:
|> | The longer I have a gta02 suspended to ram, the more decay I see in the
|> | framebuffer when I resume. Is there a way to force a refresh of this in
|> | hardware registers or at the device layer? Is this the glamo or the 410
|> | framebuffer?
|> This is Glamo internal memory not getting refresh.
|> On resume, X should redraw; for true framebuffer nobody takes
|> responsibility for it.  We can dump the framebuffer to CPU RAM in
|> suspend and spam it back on resume, but it will delay both actions.
|> -Andy
| I'm not using X. I'm using something else. So it must be the glamo with
| video RAM from our comment as it looked like the 410 used ram for the
| framebuffer already.

What is it you mean by "410" here?  The GTA02 has s3c2442.

Yes if nothing understands it needs to render the framebuffer contents
again after resume, you will see random decayed crap from internal Glamo
memory that has not been refreshed.

It's best that on resume you invalidate the whole graphical region and
provoke a fresh redraw from whatever is responsible for framebuffer

- -Andy

Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list