bttv 2.6.16: wrong VBI_OFFSET?

[Trent Piepho <xyzzy (at) speakeasy.org>]

On Tue, 25 Apr 2006, Michael Schimek wrote:
> Presumably 128 slipped in because the spec suggests an offset of 64
> fCLKx1 clocks. I think the spec is correct because changing the HSFMT
> bit and VBI_HDELAY gives the expected results. They just didn't mention
> another delay of 64 clocks. May I suggest the fix below.

The datasheet says that VBI_HDELAY starts at the trailing edge of /HRESET.
What your saying is that there is an undocumented extra delay of 64 pixels at
fCLK*1 after the tailing edge of /HRESET before VBI_HDELAY starts, correct?

It's surprising that the datasheet would totally miss the extra delay in
several places, bot in the text and in the figures.  It's also seems strange
that it's even there.  What is timing it?  Why have the delay at all?

What if there is an undocumented minimum value for VBI_HDELAY?  Maybe the chip
does some kind of back porch black level or color burst sampling, and can't
capture vbi until it's done?

Have you tried increasing VBI_HDELAY to 1, 2, 3, ..  64, 65, ..., 100 and so
on?  Does changing VBI_HDELAY always have the effect cutting of the first
VBI_HDELAY * 2 samples, relative to VBI_HDELAY=0?

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list