While running v4l2-compliance tests on vivid I suddenly got errors due to
a call to vmalloc_user with size 0 from vb2.
Digging deeper into the cause I discovered that this was due to the fact that
struct v4l2_plane_pix_format defines bytesperline as a __u16 instead of a __u32.
The test I was running selected a format of 4 * 4096 by 4 * 2048 with a 32
bit pixelformat.
So bytesperline was 4 * 4 * 4096 = 65536, which becomes 0 in a __u16. And
bytesperline * height is suddenly 0 as well. While the vivid driver may be
a virtual driver, it is to be expected that this limit will be hit for real
hardware as well in the near future: 8k deep-color video will already reach
it.
The solution is to change the type to __u32. The only drivers besides vivid
that use the multiplanar API are little-endian ARM and SH platforms (exynos,
ti-vpe, vsp1), so this is safe.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
</entry>
</row>
<row>
- <entry>__u16</entry>
+ <entry>__u32</entry>
<entry><structfield>bytesperline</structfield></entry>
<entry>Distance in bytes between the leftmost pixels in two adjacent
lines. See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>__u16</entry>
- <entry><structfield>reserved[7]</structfield></entry>
+ <entry><structfield>reserved[6]</structfield></entry>
<entry>Reserved for future extensions. Should be zeroed by the
application.</entry>
</row>
u32 bl_width = divup(width, blk->width);
u32 bl_height = divup(height, blk->height);
u32 sizeimage = bl_width * bl_height * blk->size;
- u16 bytesperline = bl_width * blk->size / blk->height;
+ u32 bytesperline = bl_width * blk->size / blk->height;
plane->sizeimage += sizeimage;
plane->bytesperline = max(plane->bytesperline, bytesperline);
*/
struct v4l2_plane_pix_format {
__u32 sizeimage;
- __u16 bytesperline;
- __u16 reserved[7];
+ __u32 bytesperline;
+ __u16 reserved[6];
} __attribute__ ((packed));
/**