[Nouveau] Syncing to vblank for interlaced video modes

[Alistair Buxton]

On 15 June 2009 14:14, Jamie Smith <hutts at internode.on.net> wrote:
> Hi Again,
>
> It seems I've triggered off much more discussion than I originally thought I would provoke.  I forgot to actually state what I was proposing to do, but it appears that people have worked it out.
>
>> >> > 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?
>
> Yes, this is what I'm proposing.  A server option that modifies the behaviour of the sync code so that if a) the option is set and b) the current video mode is interlaced, then wait until after the second field has been drawn before flipping pages/updating buffers etc.

[snip debate about whether this is a good idea]

I have been thinking about this problem recently and I have come to
the conclusion that it isn't necessary to change the vblank interrupt
frequency or add any special hooks to let the player know which field
is being shown. No drivers changes should be needed at all. It only
requires that players are more smart about how they display interlaced
content to the screen.

At the moment, every player I know of, when interlacing is disabled,
just does simple weaving. This is bad as when you display it on an
interlaced screen there is no way to know which field will get
displayed first. But there is a better way. If, each time the player
receives a vblank interrupt, it draws the next field into the display
(ie updating every other line on the framebuffer, and leaving the
other lines alone) then each field is in the framebuffer for 1 whole
frame, and no matter which framebuffer field is currently shown, the
next one will always contain the correct next field.

Effectively it is weaving, but instead of weaving each frame's field
pair, the frame rate is doubled by weaving every sequential field pair
even if they belong to different frames. So, assuming lower-field
first, it would produce frames composed like:
(1L,nothing),(1L,1U),(2L,1U),(2L,2U),(3L,2U),(3L,3U)...

Why it works is kind of hard to explain without a diagram so I have made one:

http://al.robotfuzz.com/~al/nouveau/path7109.png

Anyway, since no driver changes are needed, this is now offtopic. But
does anyone know a player that can do what I am describing? Or maybe
this method of playback has a special name I am not aware of?

-- 
Alistair Buxton
a.j.buxton at gmail.com