[Nouveau] Syncing to vblank for interlaced video modes

[Dirk Thierbach]

On Mon, Jun 15, 2009 at 08:44:26AM +0100, Alistair Buxton wrote:
> 2009/6/15 Dirk Thierbach <dthierbach at gmx.de>:
> > On Sun, Jun 14, 2009 at 11:56:45PM +0100, Alistair Buxton wrote:
> >> Stupid question: Given the presence of a register which indicates the
> >> current field, why can't NVWaitVSync simply wait until the end of the
> >> second field, by doing whatever it does twice iff it is called during
> >> the first field?
> >
> > Because then you'd effectively halve the frame rate in interlaced
> > modes, unless you somehow queue all the information for the second
> > half-frame.

> That isn't a problem, because you show both fields at the same time,
> and let the video card cut them up. You still get 50 fields per
> second, same as source.

Ok, I think I understand now what you mean.

But that will only work in the very particular case that you're
displaying a video full-screen, with the *intention* to let the
hardware do the interlacing. Which doesn't match the usual usage
of Xv, for example. So you're introducing a special case without
marking it as a special case explicitely. That's a bad idea in
my book. KISS.

> mplayer and vlc both do it. 

But only when displaying video full-screen and they know the card
is in interlaced mode, I assume? Otherwise, that would be plain stupid,
because it will generate artifacts for every other use. Like displaying
the movie in a window.

> They can also split the fields and scale vertically as you describe
> (vlc calls it bob deinterlacing) but at extra CPU cost.

Not if Xv does the scaling via hardware.

> > If you just combine two adjacent half-frames, you get the typical
> > comb-style ragged edges on fast moving objects.
> 
> That's what happens on a none-interlaced display. On an interlaced
> display it will look fine of course. So I can't see any problems with
> this method.

See above. It's a very special case, it behaves different in that special
case, it will break if the client doesn't know it behaves different and
wants to use it for other purpose (say, displaying a non-interlaced
source on an interlaced display).

Why not use a method that works in all cases? Which is to give the
client explicit knowledge about which half-field is displayed
currently. Then the client can decide what to do.

- Dirk