Re: [PATCH] [#7001] framebuffer: old image of last app would retain for a while after starting new app

-----Original Message-----
From: Mike Frysinger [mailto:vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org]
Sent: Friday, March 16, 2012 11:55 AM
To: Zhang, Sonic
Cc: uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b@public.gmane.org; Wu, Aaron; linux-fbdev-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [PATCH] [#7001] framebuffer: old image of last app would retain for a while after starting new app

On Thursday 15 March 2012 23:34:08 Zhang, Sonic wrote:

From: Mike Frysinger [mailto:vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org]

quoted

On Thursday 15 March 2012 05:23:50 Wu, Aaron wrote:

quoted

Old image of last application would retain for a while when
starting a new application, this patch clear the frambuffer before
displaying every time the fb is opened.

i'm not sure the behavior you describe is wrong.  in fact, i'm pretty
sure it sounds correct.  if an app writes an image to the framebuffer
and then quits, that image should stay there indefinitely until
something else opens the framebuffer and draws their own image.

Before the second application draws its own image, the image of last
application has already been displayed on the LCD when the second
application opens the FB device(PPI is enabled when it is opened).
This is not a correct behavior.

sure it is.  if the app wants to clear the screen, it can do so.  generally it's going to anyways by drawing an entire frame.  having the frame buffer driver always clear the screen introduces wasted memory overhead as it does the memset(), and user-visible jank as the device transitions from an initial splash screen to the main userspace app.

this is a policy decision that doesn't really belong in kernel space.  and if it did, it should be agreed upon by all frame buffer users and not just changing a few drivers.
-mike

How can the application clean the screen before it opens the FB device?

Sonic

On Friday 16 March 2012 01:05:10 Zhang, Sonic wrote:

From: Mike Frysinger [mailto:vapier@gentoo.org]

quoted

On Thursday 15 March 2012 23:34:08 Zhang, Sonic wrote:

quoted

From: Mike Frysinger [mailto:vapier@gentoo.org]

quoted

On Thursday 15 March 2012 05:23:50 Wu, Aaron wrote:

quoted

Old image of last application would retain for a while when
starting a new application, this patch clear the frambuffer before
displaying every time the fb is opened.

i'm not sure the behavior you describe is wrong.  in fact, i'm pretty
sure it sounds correct.  if an app writes an image to the framebuffer
and then quits, that image should stay there indefinitely until
something else opens the framebuffer and draws their own image.

Before the second application draws its own image, the image of last
application has already been displayed on the LCD when the second
application opens the FB device(PPI is enabled when it is opened).
This is not a correct behavior.

sure it is.  if the app wants to clear the screen, it can do so.  generally
it's going to anyways by drawing an entire frame.  having the frame buffer
driver always clear the screen introduces wasted memory overhead as it
does the memset(), and user-visible jank as the device transitions from an
initial splash screen to the main userspace app.

this is a policy decision that doesn't really belong in kernel space.  and
if it did, it should be agreed upon by all frame buffer users and not just
changing a few drivers.

How can the application clean the screen before it opens the FB device?

why does it need to be before open ?  if the kernel does the memset or 
userspace does the memset, the frame still gets cleared.

in looking at the blackfin framebuffer drivers, i'm not sure they're correct.  i 
don't think the PPI/DMA should be shutdown when the last user space client 
closes it.  fb_release is for releasing all resources when tearing down the 
driver, and fb_blank is runtime management (turning off vsync/hsync and 
powering down the screen).
-mike