[PATCH 5/5] staging/easycap: Fix bytesperline calculation

[Winkler, Tomas]

> -----Original Message-----
> From: Kirill Smelkov [mailto:kirr at mns.spb.ru]
> Sent: Monday, June 13, 2011 3:19 PM
> To: Greg Kroah-Hartman
> Cc: Winkler, Tomas; Mike Thomas; devel at driverdev.osuosl.org; linux-
> kernel at vger.kernel.org; Kirill Smelkov
> Subject: [PATCH 5/5] staging/easycap: Fix bytesperline calculation
> 
> As described above fillin_formats()
> 
> """
>     /*
>      *  THE 16-BIT easycap_format.mask HAS MEANING:
>      *    (least significant) BIT  0:     0 => PAL, 25 FPS;   1 => NTSC, 30 FPS
>      *                        BITS 2-4:   RESERVED FOR DIFFERENTIATING STANDARDS
>      *                        BITS 5-7:   NUMBER OF BYTES PER PIXEL
>      *                        BIT  8:     0 => NATIVE BYTE ORDER;  1 => SWAPPED
>      *                        BITS 9-10:  RESERVED FOR OTHER BYTE PERMUTATIONS
>      *                        BIT 11:     0 => UNDECIMATED;    1 => DECIMATED
>      *                        BIT 12:     0 => OFFER FRAMES;   1 => OFFER FIELDS
>      *                        BIT 13:     0 => FULL FRAMERATE; 1 => REDUCED
>      *     (most significant) BITS 14-15: RESERVED FOR OTHER FIELD/FRAME
> OPTIONS
>      *  IT FOLLOWS THAT:
>      *     bytesperpixel IS         ((0x00E0 & easycap_format.mask) >> 5)
>      *     byteswaporder IS true IF (0 != (0x0100 & easycap_format.mask))
>      *
>      *     decimatepixel IS true IF (0 != (0x0800 & easycap_format.mask))
>      *
>      *       offerfields IS true IF (0 != (0x1000 & easycap_format.mask))
>      */
> """
> 
> bytes-per-pixel is stored in bits 5-7 of calculated mask.
> 
> But when calculating bytes-per-line we were extracting wrong value instead
> of bytes-per-pixel, which was usually 2 times bigger -- e.g. for PAL YUV 422 I
> was getting ((mask3 & 0x00F0) >> 4) = 4 bytes instead of 2.
> 
> The error here is that even in comments there is a line saying
> 
>      *     bytesperpixel IS         ((0x00E0 & easycap_format.mask) >> 5)
> 
> but we were using
>                                     ((0x00F0 & easycap_format.mask) >> 4)
> 
> With 2 times bigger bytesperpixel and automatically bytesperline, the video
> was shown halfheight'ed, which is understandable if we look at video-
> memory layout:
> 
>     <------- bytesperline -------->
>     <- real bpl ->
> 
>     x0----------y0  x1-----------y1
>     x2----------y2  x3-----------y3
> 
>     xn----------yn  xn-----------yn
>     <garbage>
> 
> for each line, we should display width pixels, then move to next line with
> bytesperline, and oops, if bytesperline = 2*real-bytesperlin, we'll skip one
> line and move to next-next line, and so only half lines will be shown.
> 
> Initially I've debugged the problem with my video application[1], but I've
> checked that after this patch both rawv (mine app) and tvtime work
> correctly.
> 
> [1] http://repo.or.cz/w/rawv.git
> 
> P.S. why at all we use those mask/shifts? Why not use bitfields?

First of all  I have feeling this code history beyond this driver.  
Second there possible issues with bit fields related to endianity and efficiency. I'm not sure it applies also in this driver 
context and I agree it looks ugly here , yet I personally usually avoid using bit fields. 

> 
> Cc: Tomas Winkler <tomas.winkler at intel.com>
> Cc: Mike Thomas <rmthomas at sciolus.org>
> Signed-off-by: Kirill Smelkov <kirr at mns.spb.ru>


Acked-by:  Tomas Winkler <tomas.winkler at intel.com>

> ---
>  drivers/staging/easycap/easycap_settings.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/staging/easycap/easycap_settings.c
> b/drivers/staging/easycap/easycap_settings.c
> index 898559d..70f59b1 100644
> --- a/drivers/staging/easycap/easycap_settings.c
> +++ b/drivers/staging/easycap/easycap_settings.c
> @@ -567,7 +567,7 @@ int fillin_formats(void)
>  				default:
>  					return -3;
>  				}
> -				bytesperline = width * ((mask3 & 0x00F0) >>
> 4);
> +				bytesperline = width * ((mask3 & 0x00E0) >>
> 5);
>  				sizeimage =  bytesperline * height;
> 
>  				for (m = 0; m < INTERLACE_MANY; m++) {
> --
> 1.7.6.rc1

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.