Hans, > >Well, it is definitely not possible to do it in this manner since changing >the size of struct v4l2_buffer will break the API. Furthermore, something >like >this will only work if the DMA engine can handle strides. Is that the case >for your hardware? I don't think you mentioned what the hardware is you use. > In fact I was planning to write an RFC for this as well. DM365 Resizer allows setting separate buffer address for Y and C plane (For _NV12 pixel format) as well as line offsets. Similarly on the display side, VPBE provides separate registers for configuring this. Currently we have proprietary IOCTL to configure the C-Plane buffer address and is not the right way to do it. For planar pixel format like NV12, NV16 etc, where the hardware is capable of configuring different address for individual plane, current v4l2 API has limitations. So I suggest that Jun Nie work on a RFC &implementation that allows application to set buffer addresses for individual planes of planar pixel formats. Something like below for userptr case (I feel only userptr case to be supported in this case)... + struct v4l2_userptr_planar { + /* Number of planes in the pixel format. 2 or 3, + * 2 - for Y & CbCr, 3 for Y, Cb, & Cr + */ + __u32 num_planes; + /* Y or R */ + unsigned long userptr_yr; + /* Cb or G */ + unsigned long userptr_cbg; + /* Cr or B */ + unsigned long userptr_crb; + }; struct v4l2_buffer { __u32 index; enum v4l2_buf_type type; __u32 bytesused; __u32 flags; enum v4l2_field field; struct timeval timestamp; struct v4l2_timecode timecode; __u32 sequence; /* memory location */ enum v4l2_memory memory; union { __u32 offset; unsigned long userptr; + struct v4l2_userptr_planar userptr_p; } m; __u32 length; __u32 input; __u32 reserved; }; -Murali >Regards, > > Hans > >-- >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom >¢éì¹»®&Þ~º&¶¬–+-±éݶ¥Šw®žË›±ÊâmébžìfyØšŠ{ayºÊ‡Ú™ë,j ¢f£¢·hš‹àz¹®w¥¢¸ > >¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾ «‘êçzZ+ƒùšŽŠÝ¢j"?ú!¶i -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html