bttv 2.6.16: wrong VBI_OFFSET?
- From: Edgar Toernig <froese (at) gmx.de>
- Date: Mon, 8 May 2006 18:26:03 +0200
Bug reports for AleVT start trickling in. Is there any
objection to send a patch to stable (at) kernel.org to revert
VBI_OFFSET for 2.6.16.15?
Ciao, ET.
---snip---------
To: stable (at) kernel.org
Subject: [BTTV] Revert VBI_OFFSET
2.6.16 broke VBI decoders by changing the VBI_OFFSET
reported to userspace. Revert the relevant change
until a proper solution is found.
Signed-Off-By: some maintainer...
---
The comment for VBI_OFFSET (see below) reflects the documentation
but unfortunately it's wrong. The actual offset depends on several
undocumented parameters. The previous value (244) worked for a
couple of years reasonable well for PAL but was incorrect for NTSC.
The new value (128) introduced in 2.6.16 is wrong for PAL and NTSC.
There's no consent yet on how a proper fix would look like.
--- linux-2.6.16/drivers/media/video/bttv-vbi.c 2006-05-08 13:52:14 +0200
+++ linux-2.6.16/drivers/media/video/bttv-vbi.c 2006-05-08 13:53:16 +0200
(at) (at) -31,11 +31,8 (at) (at)
#include <asm/io.h>
#include "bttvp.h"
-/* Offset from line sync pulse leading edge (0H) in 1 / sampling_rate:
- bt8x8 /HRESET pulse starts at 0H and has length 64 / fCLKx1 (E|O_VTC
- HSFMT = 0). VBI_HDELAY (always 0) is an offset from the trailing edge
- of /HRESET in 1 / fCLKx1, and the sampling_rate tvnorm->Fsc is fCLKx2. */
-#define VBI_OFFSET ((64 + 0) * 2)
+/* Offset from line sync pulse leading edge (0H) in 1 / sampling_rate: */
+#define VBI_OFFSET 244
#define VBI_DEFLINES 16
#define VBI_MAXLINES 32
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list