V4L/DVB: em28xx: reduce cropping for VBI area

It turns up we can reduce the starting line for the active area, which results
in more data being captured when under PAL (while the full VBI capture window
still stays properly encoded).

This work was sponsored by EyeMagnet Limited.

Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

diff --git a/drivers/media/video/em28xx/em28xx-core.c b/drivers/media/video/em28xx/em28xx-core.c
index a41cc55667783e610db233b963605ff85e8909b3..258041d0be9ece8167a6bbfced746f611e93e2fd 100644 (file)
--- a/drivers/media/video/em28xx/em28xx-core.c
+++ b/drivers/media/video/em28xx/em28xx-core.c
@@ -782,11 +782,15 @@ int em28xx_resolution_set(struct em28xx *dev)
 
        em28xx_accumulator_set(dev, 1, (width - 4) >> 2, 1, (height - 4) >> 2);
 
-       /* If we don't set the start position to 4 in VBI mode, we end up
-          with line 21 being YUYV encoded instead of being in 8-bit
-          greyscale */
+       /* If we don't set the start position to 2 in VBI mode, we end up
+          with line 20/21 being YUYV encoded instead of being in 8-bit
+          greyscale.  The core of the issue is that line 21 (and line 23 for
+          PAL WSS) are inside of active video region, and as a result they
+          get the pixelformatting associated with that area.  So by cropping
+          it out, we end up with the same format as the rest of the VBI
+          region */
        if (em28xx_vbi_supported(dev) == 1)
-               em28xx_capture_area_set(dev, 0, 4, width >> 2, height >> 2);
+               em28xx_capture_area_set(dev, 0, 2, width >> 2, height >> 2);
        else
                em28xx_capture_area_set(dev, 0, 0, width >> 2, height >> 2);