DirectFB - Home of the pragmatist Roadmap


[directfb-dev] Re: Flipping troubles - videolayer, crtc2
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-dev] Re: Flipping troubles - videolayer, crtc2



Quoting Jiri Svoboda (jiri.svoboda@seznam.cz):
> > > > Setting backbuffer to main memory disregards the FlipBuffer()
> > > > command, but instead calls dfb_back_to_front_copy(), which is 
> > > > essentially a blit command.  Is the blit for YUV planars 
> > > > fixed in 0.9.11?  Maybe this is the reason why flipping from 
> > > > a system backbuffer does not work.
> > > > 
> > > 
> > > After upgrading to latest CVS with YV12 BitBlt support the "new" 
> > > implementation with backbuffer in system memory works OK.
> > > 
> > > So let me summarize (all is for videolayer):
> > > 1) front buffer & back buffer in video memory, frame 
> > written directly 
> > > to back buffer by sw -> has big troubles, looks like wrong 
> > buffer is 
> > > obtained or displayed
> > 
> > The flip on the BES will take effect during the next vertical 
> > retrace. Please try dfb->WaitForSync(dfb) after flipping or 
> > DSFLIP_WAITFORSYNC as a flag for Flip().
> 
> Flip is always performed with DSFLIP_WAITFORSYNC.
> 	DFBCHECK (primary->Flip (primary, NULL, DSFLIP_WAITFORSYNC));

This causes Flip() to wait until the vertical retrace before flipping
is performed by the driver. The flipping of the BES happens on the
next vertical retrace (one whole frame later because Flip waited before).
In case of the BES you should flip without DSFLIP_WAITFORSYNC and maybe
do a dfb->WaitForSync() afterwards.

> > The vsync handling during flipping (before/after) should be 
> > cleaned up. There should be a unique API for the different 
> > behaviours with different hardware. DSFLIP_ONSYNC_WAITING 
> > (waits until flip is executed on vsync), 
> > DSFLIP_ONSYNC_SCHEDULED (returns immediately but flips on 
> That would be nice :-) I will be able to render next frame immediately
> and not waste cpu time. But it leads to tripple buffering (1-displayed
> (old front buffer),2-wainting to be displayed (actual frontbuffer),3-new
> backbuffer).

As described above, Flip on the BES without flags behaves like this option.
Adding tripple buffering support looks like a candidate for the TODO file ;)

> Let me say that case 1 is working for primary surface (for mga CRTC1)
> created with flipping flag via
>  dsc.flags = DSDESC_CAPS | DSDESC_PIXELFORMAT;
>  dsc.caps  = DSCAPS_PRIMARY | DSCAPS_VIDEOONLY | DSCAPS_FLIPPING;
>  ....
>  dfb->CreateSurface( dfb, &dsc, &primary ); 
> 
> But this has troubles on CRTC2 of mga - surface is created, but flip
> fails because panning is not supported by framebuffer. This is not very
> nice - in previous versions creating such a surface failed   on
> CreateSurface. This was better in my opinion, beacause if I'm allowed to
> create such a surface I should be also allowed to flip it otherwise
> don't let me create it.

Did you try "df_andi --dfb:fbdev=/dev/fb1"?
You may add DSCAPS_VIDEOONLY to df_andi's setup code.

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH


-- 
Info:  To unsubscribe send a mail to listar@directfb.org with 
"unsubscribe directfb-dev" as subject.



Home | Main Index | Thread Index


directfb.org / Development / Old Archives