|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: Flipping troubles - videolayer, crtc2
> Quoting Jiri Svoboda (firstname.lastname@example.org): > > > > > 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 email@example.com with "unsubscribe directfb-dev" as subject.