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

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

[Wu, Aaron]

-----Original Message-----
From: Aaron Wu [mailto:Aaron.Wu-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org]
Sent: Tuesday, March 13, 2012 4:47 PM
To: linux-fbdev-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b@public.gmane.org; Wu, Aaron
Cc: Wu, Aaron
Subject: [PATCH] [#7001] framebuffer: old image of last app would retain for a while after starting new app

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.

Signed-off-by: Aaron Wu <Aaron.Wu-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
---
 drivers/video/bfin-lq035q1-fb.c  |    1 +
 drivers/video/bfin-t350mcqb-fb.c |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c
index c633068..676aa4e 100644
--- a/drivers/video/bfin-lq035q1-fb.c
+++ b/drivers/video/bfin-lq035q1-fb.c
@@ -399,6 +399,7 @@ static int bfin_lq035q1_fb_open(struct fb_info *info, int user)
                bfin_lq035q1_config_dma(fbi);
                bfin_lq035q1_config_ppi(fbi);
                bfin_lq035q1_init_timers(fbi);
+               memset(fbi->fb_buffer, 0, info->fix.smem_len);

                /* start dma */
                enable_dma(CH_PPI);
diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c
index d5e1267..37f2df1 100644
--- a/drivers/video/bfin-t350mcqb-fb.c
+++ b/drivers/video/bfin-t350mcqb-fb.c
@@ -216,6 +216,7 @@ static int bfin_t350mcqb_fb_open(struct fb_info *info, int user)
                bfin_t350mcqb_config_dma(fbi);
                bfin_t350mcqb_config_ppi(fbi);
                bfin_t350mcqb_init_timers();
+               memset(fbi->fb_buffer, 0, info->fix.smem_len);

                /* start dma */
                enable_dma(CH_PPI);
--
1.7.0.4

Re: [Linux-fbdev-devel] [uclinux-dist-devel] [PATCH] [#7001] framebuffer: old image of last app woul

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 513 bytes --]

On Thursday 15 March 2012 05:23:50 Wu, Aaron wrote:
> 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.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 191 bytes --]

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] [uclinux-dist-devel] [PATCH] [#7001] framebuffer: old image of last app woul

[Geert Uytterhoeven]

[ Corrected obsolete linux-fbdev-devel address ]

On Thu, Mar 15, 2012 at 20:08, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday 15 March 2012 05:23:50 Wu, Aaron wrote:
>> 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.

Indeed. Else can you no longer make a screenshot using "cat /dev/fb0 > file".

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Linux-fbdev-devel] [uclinux-dist-devel] [PATCH] [#7001] framebuffer: old image of last app woul

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 896 bytes --]

On Thursday 15 March 2012 15:22:34 Geert Uytterhoeven wrote:
> On Thu, Mar 15, 2012 at 20:08, Mike Frysinger wrote:
> > On Thursday 15 March 2012 05:23:50 Wu, Aaron wrote:
> >> 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.
> 
> Indeed. Else can you no longer make a screenshot using "cat /dev/fb0 >
> file".

ironically, that's one method we've documented for Blackfin platforms :)
http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:framebuffer
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Zhang, Sonic]

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

On Thursday 15 March 2012 05:23:50 Wu, Aaron wrote:
> 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.
-mike

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.

Sonic

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

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 1432 bytes --]

On Thursday 15 March 2012 23:34:08 Zhang, Sonic wrote:
> From: Mike Frysinger [mailto:vapier@gentoo.org]
>> On Thursday 15 March 2012 05:23:50 Wu, Aaron wrote:
>> > 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

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 191 bytes --]

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

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

[Zhang, Sonic]

-----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]
>> On Thursday 15 March 2012 05:23:50 Wu, Aaron wrote:
>> > 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

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

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 2145 bytes --]

On Friday 16 March 2012 01:05:10 Zhang, Sonic wrote:
> From: Mike Frysinger [mailto:vapier@gentoo.org]
>> On Thursday 15 March 2012 23:34:08 Zhang, Sonic wrote:
>>> From: Mike Frysinger [mailto:vapier@gentoo.org]
>>>> On Thursday 15 March 2012 05:23:50 Wu, Aaron wrote:
>>>>> 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

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 191 bytes --]

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel