From: Devin Heitmueller Date: Fri, 22 Jan 2010 05:05:24 +0000 (-0300) Subject: V4L/DVB: em28xx: reduce cropping for VBI area X-Git-Url: https://git.karo-electronics.de/?a=commitdiff_plain;h=1744feab9a2241f2adf03be5ef8ecbd279f5944b;p=linux-beck.git 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 Signed-off-by: Mauro Carvalho Chehab --- diff --git a/drivers/media/video/em28xx/em28xx-core.c b/drivers/media/video/em28xx/em28xx-core.c index a41cc5566778..258041d0be9e 100644 --- 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);