gta02 framebuffer decay on suspend
sean at mcneil.com
Sat May 31 22:14:49 CEST 2008
Andy Green wrote:
> 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, I understand. There is some confusion in the kernel, however, as
the GTA02 seems to use several devices and things from the GTA01 that
reference s3c2410. At one point, I think I couldn't even run the kernel
unless I specified gta01 support. I wasn't sure if the s3c2410
framebuffer was reused of if the glamo completely supersedes it. The
fact that the glamo has video memory made it obvious to me and explained
> 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
Thanks Andy. I will work on adding full screen refresh on resume to the
More information about the openmoko-kernel