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

[Ville Syrjälä <syrjala@sci.fi>]

On Mon, Jun 17, 2002 at 10:28:50AM +0200, Denis Oliver Kropp wrote:
> Quoting Jiri Svoboda (jiri.svoboda@seznam.cz):
> > > 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).

Shouldn't dfb_fbdev_wait_vsync() be called after the flip in this case. It
would make the BES behave just like any other layer. It would require some
additional flag so that Surface_Flip_Layer() would do the right thing.

> In case of the BES you should flip without DSFLIP_WAITFORSYNC and maybe
> do a dfb->WaitForSync() afterwards.

Expecting all application developers to include some hw specific kludges,
are we? :)


Also what's with the waitretrace() function. MDA/CGA specific and it get's
called regardless of dfb_config->pollvsync_after (is it a bug or
intentional?). For something like the Matrox CRTC2 it's simply wrong.

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

Panning not supported?
$ grep fb_pan_display /usr/src/linux/drivers/video/matrox/matroxfb_crtc2.c 
	fb_pan_display:	matroxfb_dh_pan_display,

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


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