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

[Jiří Svoboda <Jiri.Svoboda@seznam.cz>]

> 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.

YES - that works. How can I detect if this is necessary and when to use
DSFLIP_WAITFORSYNC?

> 
> > > 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.

I've tried it - result is the same as for my code - flip fails with
general failure (pannig not supported). Doesn't matter if
DSCAPS_VIDEOONLY is applied.

						JS



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