gta02 framebuffer decay on suspend

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
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
contents.

- -Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhBsA8ACgkQOjLpvpq7dMr48gCgidZxM5tCuGzoiUcVtp1QYFMY
rS0AoIgaPouOIB7rYmB43Rimw5OD0hmg
=IXY1
-----END PGP SIGNATURE-----