aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/media/video/em28xx
diff options
context:
space:
mode:
Diffstat (limited to 'drivers/media/video/em28xx')
-rw-r--r--drivers/media/video/em28xx/em28xx-core.c12
1 files changed, 8 insertions, 4 deletions
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)
782 782
783 em28xx_accumulator_set(dev, 1, (width - 4) >> 2, 1, (height - 4) >> 2); 783 em28xx_accumulator_set(dev, 1, (width - 4) >> 2, 1, (height - 4) >> 2);
784 784
785 /* If we don't set the start position to 4 in VBI mode, we end up 785 /* If we don't set the start position to 2 in VBI mode, we end up
786 with line 21 being YUYV encoded instead of being in 8-bit 786 with line 20/21 being YUYV encoded instead of being in 8-bit
787 greyscale */ 787 greyscale. The core of the issue is that line 21 (and line 23 for
788 PAL WSS) are inside of active video region, and as a result they
789 get the pixelformatting associated with that area. So by cropping
790 it out, we end up with the same format as the rest of the VBI
791 region */
788 if (em28xx_vbi_supported(dev) == 1) 792 if (em28xx_vbi_supported(dev) == 1)
789 em28xx_capture_area_set(dev, 0, 4, width >> 2, height >> 2); 793 em28xx_capture_area_set(dev, 0, 2, width >> 2, height >> 2);
790 else 794 else
791 em28xx_capture_area_set(dev, 0, 0, width >> 2, height >> 2); 795 em28xx_capture_area_set(dev, 0, 0, width >> 2, height >> 2);
792 796