On Mon, Nov 11, 2002 at 07:10:09PM +0200, Ville Syrj�l� wrote: > Pass address instead of value to FBIO_WAITFORVSYNC. Now get_user() should > be happy and we get protection from bogus values.
OK. Cool.
But can you explain the implication of this part of the patch:
> @@ -398,14 +400,13 @@
>
> static void crtc2_wait_vsync( MatroxDriverData *mdrv )
> {
> + int vdisplay = (dfb_config->matrox_ntsc ? 486/2 : 576/2) + 2;
> #ifdef FBIO_WAITFORVSYNC
> dfb_gfxcard_sync();
> - ioctl( dfb_fbdev->fd, FBIO_WAITFORVSYNC, 1 );
> -#else
> - int vdisplay = (dfb_config->matrox_ntsc ? 486/2 : 576/2) + 2;
> + ioctl( dfb_fbdev->fd, FBIO_WAITFORVSYNC, &one );
> +#endif
> while ((mga_in32( mdrv->mmio_base, C2VCOUNT ) & 0x00000FFF) != vdisplay)
> ;
> -#endif
> }
I see that the:
while ((mga_in32( mdrv->mmio_base, C2VCOUNT ) & 0x00000FFF) != vdisplay)
;
is no longer in the "no FBIO_WAITFORVSYNC" code path. I know zilch
about the Matrox hardware, but I am guessing that
mga_in32( mdrv->mmio_base, C2VCOUNT ) & 0x00000FFF)
returns the scanline that the card is currently drawing and that the
loop is meant to halt processing until the card has finished drawing
the field (to provide vsynced output for kernels no supporting
FBIO_WAITFORVSYNC).
If I am correct so far, then in the FBIO_WAITFORVSYNC codepath, isn't
the loop effectively a NOOP by the time the ioctl( dfb_fbdev->fd,
FBIO_WAITFORVSYNC, 1 ) returns? If it's not then there was a huge
delay returning from the ioctl and waiting for the loop to complete
would put us at the completion of the _next_ field no (i.e. now we are
a field behind)?
Maybe I am way off base.
Thanx for all the great work Ville!
b.
BTW: did you get the copy of my patch that fixes the OSD flicker in
MPlayer with all of the crtc2/dfbmga work you have done? I posted to
mplayer-eng-dev but it has not been approved yet. I think I will go
repost from my mplayer alias.
--
Brian J. Murrell
msg01050/pgp00000.pgp
Description: PGP signature
