By Date: <-- -->
By Thread: <-- -->

bttv 2.6.16: wrong VBI_OFFSET?

On Sun, 30 Apr 2006, Michael Schimek wrote:
> Well I *think* the leading edge of the /HRESET pulse coincides with the
> leading edge of the horizontal sync pulse (0H). The datasheet isn't clear
> about that. Perhaps it's 64 clocks late, or the /HRESET seen by the VBI

It certainly isn't clear, is it?  All the horizontal timing except VBI is 0H
relative.  For some reason, VBI is the only timing specified relative to
/HRESET.  One can only assume that the leading edge of /HRESET is at 0H.

> Although HSFMT changes give the expected results. VBI_HDELAY has only six
> bits. Perhaps some register contains an undocumented msb, or it's
> hardwired to 1? Video HDELAYs below 64 produce garbage, a coincidence?

An undocumented 7th bit that is set to 1, that does make some sense.  It does
seem reasonable that it would be possible to specify VBI_HDELAY values that
start VBI capture with the start of the video signal, but 0-63 isn't enough
for that, while 64-127 is.  Probably just a way for them to save a bit.

> It works as documented. Here are some pictures of the suspects:
> http://zapping.sf.net/bttv/

My bt878 datasheet defines HSFMT as a single bit, that sets /HRESET to 32 or 64
clk*1 pixels.  But you have HSFMT=3 and 2?  In picture 7, HSFMT=3 reduces
/HRESET's width by 48 pixels?  Do you have updated information with a 2-bit
HSFMT that allows for an /HRESET width of 16 pixels?

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