From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> To: Ezequiel Garcia <ezequiel@collabora.com> Cc: linux-media@vger.kernel.org, Hans Verkuil <hans.verkuil@cisco.com>, kernel@collabora.com, Nicolas Dufresne <nicolas.dufresne@collabora.com>, Tomasz Figa <tfiga@chromium.org>, linux-rockchip@lists.infradead.org, Heiko Stuebner <heiko@sntech.de>, Jonas Karlman <jonas@kwiboo.se>, Philipp Zabel <p.zabel@pengutronix.de>, Boris Brezillon <boris.brezillon@collabora.com> Subject: Re: [PATCH v6 03/16] media: v4l2-common: Support custom imagesize in fill_pixfmt() Date: Wed, 29 May 2019 08:28:09 -0300 [thread overview] Message-ID: <20190529082809.0b9f3553@coco.lan> (raw) In-Reply-To: <20190528170232.2091-4-ezequiel@collabora.com> Em Tue, 28 May 2019 14:02:19 -0300 Ezequiel Garcia <ezequiel@collabora.com> escreveu: > From: Boris Brezillon <boris.brezillon@collabora.com> > > Users can define custom sizeimage as long as they're big enough to > store the amount of pixels required for a specific width/height under a > specific format. Avoid overriding those fields in this case. > > We could possibly do the same for bytesperline, but it gets tricky when > dealing with !MPLANE definitions, so this case is omitted for now and > ->bytesperline is always overwritten with the value calculated in > fill_pixfmt(). > > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> > --- > Changes from v5: > * Overwrite bytesperline with the value calculated in fill_pixfmt() > > Changes from v4: > * New patch > > drivers/media/v4l2-core/v4l2-common.c | 58 ++++++++++++++++++++------- > 1 file changed, 43 insertions(+), 15 deletions(-) > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c > index b2d1e55d9561..fd286f6e17d7 100644 > --- a/drivers/media/v4l2-core/v4l2-common.c > +++ b/drivers/media/v4l2-core/v4l2-common.c > @@ -585,9 +585,9 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > pixfmt->num_planes = info->mem_planes; > > if (info->mem_planes == 1) { > + u32 sizeimage = 0; > + > plane = &pixfmt->plane_fmt[0]; > - plane->bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > - plane->sizeimage = 0; > > for (i = 0; i < info->comp_planes; i++) { > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > @@ -598,10 +598,21 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > aligned_width = ALIGN(width, v4l2_format_block_width(info, i)); > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > > - plane->sizeimage += info->bpp[i] * > - DIV_ROUND_UP(aligned_width, hdiv) * > - DIV_ROUND_UP(aligned_height, vdiv); > + sizeimage += info->bpp[i] * > + DIV_ROUND_UP(aligned_width, hdiv) * > + DIV_ROUND_UP(aligned_height, vdiv); > } > + > + /* Custom bytesperline value is not supported yet. */ > + plane->bytesperline = ALIGN(width, > + v4l2_format_block_width(info, 0)) * > + info->bpp[0]; > + > + /* > + * The user might have specified a custom sizeimage, only > + * override it if it's not big enough. > + */ > + plane->sizeimage = max(sizeimage, plane->sizeimage); No upper limit? That doesn't sound a good idea to me, specially since some (broken) app might not be memset the format to zero before filling the ioctl structure. Perhaps we could do something like: sizeimage = min (sizeimage, 2 * plane->sizeimage) or something similar that would be reasonable. > } else { > for (i = 0; i < info->comp_planes; i++) { > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > @@ -613,10 +624,19 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > > plane = &pixfmt->plane_fmt[i]; > - plane->bytesperline = > - info->bpp[i] * DIV_ROUND_UP(aligned_width, hdiv); > - plane->sizeimage = > - plane->bytesperline * DIV_ROUND_UP(aligned_height, vdiv); > + > + /* Custom bytesperline value is not supported yet. */ Supporting custom bytesperline seems too risky of breaking apps. So, I would drop this comment. > + plane->bytesperline = info->bpp[i] * > + DIV_ROUND_UP(aligned_width, hdiv); > + > + /* > + * The user might have specified a custom sizeimage, > + * only override it if it's not big enough. > + */ > + plane->sizeimage = max_t(u32, > + plane->bytesperline * > + DIV_ROUND_UP(aligned_height, vdiv), > + plane->sizeimage); > } > } > return 0; > @@ -627,6 +647,7 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > u32 width, u32 height) > { > const struct v4l2_format_info *info; > + u32 sizeimage = 0; > int i; > > info = v4l2_format_info(pixelformat); > @@ -640,8 +661,6 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > pixfmt->width = width; > pixfmt->height = height; > pixfmt->pixelformat = pixelformat; > - pixfmt->bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > - pixfmt->sizeimage = 0; > > for (i = 0; i < info->comp_planes; i++) { > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > @@ -651,11 +670,20 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > > aligned_width = ALIGN(width, v4l2_format_block_width(info, i)); > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > - > - pixfmt->sizeimage += info->bpp[i] * > - DIV_ROUND_UP(aligned_width, hdiv) * > - DIV_ROUND_UP(aligned_height, vdiv); > + sizeimage += info->bpp[i] * DIV_ROUND_UP(aligned_width, hdiv) * > + DIV_ROUND_UP(aligned_height, vdiv); > } > + > + /* Custom bytesperline value is not supported yet. */ > + pixfmt->bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * > + info->bpp[0]; > + > + /* > + * The user might have specified its own sizeimage value, only override > + * it if it's not big enough. > + */ > + pixfmt->sizeimage = max(sizeimage, pixfmt->sizeimage); > + Same comment applies here: We need to sanitize it from too big sizeimages. > return 0; > } > EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt); Thanks, Mauro
WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Ezequiel Garcia <ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> Cc: kernel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>, Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>, Tomasz Figa <tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Boris Brezillon <boris.brezillon-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>, Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>, Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, Nicolas Dufresne <nicolas.dufresne-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>, linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH v6 03/16] media: v4l2-common: Support custom imagesize in fill_pixfmt() Date: Wed, 29 May 2019 08:28:09 -0300 [thread overview] Message-ID: <20190529082809.0b9f3553@coco.lan> (raw) In-Reply-To: <20190528170232.2091-4-ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> Em Tue, 28 May 2019 14:02:19 -0300 Ezequiel Garcia <ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> escreveu: > From: Boris Brezillon <boris.brezillon-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> > > Users can define custom sizeimage as long as they're big enough to > store the amount of pixels required for a specific width/height under a > specific format. Avoid overriding those fields in this case. > > We could possibly do the same for bytesperline, but it gets tricky when > dealing with !MPLANE definitions, so this case is omitted for now and > ->bytesperline is always overwritten with the value calculated in > fill_pixfmt(). > > Signed-off-by: Boris Brezillon <boris.brezillon-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> > --- > Changes from v5: > * Overwrite bytesperline with the value calculated in fill_pixfmt() > > Changes from v4: > * New patch > > drivers/media/v4l2-core/v4l2-common.c | 58 ++++++++++++++++++++------- > 1 file changed, 43 insertions(+), 15 deletions(-) > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c > index b2d1e55d9561..fd286f6e17d7 100644 > --- a/drivers/media/v4l2-core/v4l2-common.c > +++ b/drivers/media/v4l2-core/v4l2-common.c > @@ -585,9 +585,9 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > pixfmt->num_planes = info->mem_planes; > > if (info->mem_planes == 1) { > + u32 sizeimage = 0; > + > plane = &pixfmt->plane_fmt[0]; > - plane->bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > - plane->sizeimage = 0; > > for (i = 0; i < info->comp_planes; i++) { > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > @@ -598,10 +598,21 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > aligned_width = ALIGN(width, v4l2_format_block_width(info, i)); > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > > - plane->sizeimage += info->bpp[i] * > - DIV_ROUND_UP(aligned_width, hdiv) * > - DIV_ROUND_UP(aligned_height, vdiv); > + sizeimage += info->bpp[i] * > + DIV_ROUND_UP(aligned_width, hdiv) * > + DIV_ROUND_UP(aligned_height, vdiv); > } > + > + /* Custom bytesperline value is not supported yet. */ > + plane->bytesperline = ALIGN(width, > + v4l2_format_block_width(info, 0)) * > + info->bpp[0]; > + > + /* > + * The user might have specified a custom sizeimage, only > + * override it if it's not big enough. > + */ > + plane->sizeimage = max(sizeimage, plane->sizeimage); No upper limit? That doesn't sound a good idea to me, specially since some (broken) app might not be memset the format to zero before filling the ioctl structure. Perhaps we could do something like: sizeimage = min (sizeimage, 2 * plane->sizeimage) or something similar that would be reasonable. > } else { > for (i = 0; i < info->comp_planes; i++) { > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > @@ -613,10 +624,19 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > > plane = &pixfmt->plane_fmt[i]; > - plane->bytesperline = > - info->bpp[i] * DIV_ROUND_UP(aligned_width, hdiv); > - plane->sizeimage = > - plane->bytesperline * DIV_ROUND_UP(aligned_height, vdiv); > + > + /* Custom bytesperline value is not supported yet. */ Supporting custom bytesperline seems too risky of breaking apps. So, I would drop this comment. > + plane->bytesperline = info->bpp[i] * > + DIV_ROUND_UP(aligned_width, hdiv); > + > + /* > + * The user might have specified a custom sizeimage, > + * only override it if it's not big enough. > + */ > + plane->sizeimage = max_t(u32, > + plane->bytesperline * > + DIV_ROUND_UP(aligned_height, vdiv), > + plane->sizeimage); > } > } > return 0; > @@ -627,6 +647,7 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > u32 width, u32 height) > { > const struct v4l2_format_info *info; > + u32 sizeimage = 0; > int i; > > info = v4l2_format_info(pixelformat); > @@ -640,8 +661,6 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > pixfmt->width = width; > pixfmt->height = height; > pixfmt->pixelformat = pixelformat; > - pixfmt->bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > - pixfmt->sizeimage = 0; > > for (i = 0; i < info->comp_planes; i++) { > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > @@ -651,11 +670,20 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > > aligned_width = ALIGN(width, v4l2_format_block_width(info, i)); > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > - > - pixfmt->sizeimage += info->bpp[i] * > - DIV_ROUND_UP(aligned_width, hdiv) * > - DIV_ROUND_UP(aligned_height, vdiv); > + sizeimage += info->bpp[i] * DIV_ROUND_UP(aligned_width, hdiv) * > + DIV_ROUND_UP(aligned_height, vdiv); > } > + > + /* Custom bytesperline value is not supported yet. */ > + pixfmt->bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * > + info->bpp[0]; > + > + /* > + * The user might have specified its own sizeimage value, only override > + * it if it's not big enough. > + */ > + pixfmt->sizeimage = max(sizeimage, pixfmt->sizeimage); > + Same comment applies here: We need to sanitize it from too big sizeimages. > return 0; > } > EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt); Thanks, Mauro
next prev parent reply other threads:[~2019-05-29 11:28 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-28 17:02 [PATCH v6 00/16] Add MPEG-2 decoding to Rockchip VPU Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 01/16] media: v4l2-common: Fix v4l2_fill_pixfmt[_mp]() prototypes Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 02/16] media: v4l2-common: Add an helper to apply frmsize constraints Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 03/16] media: v4l2-common: Support custom imagesize in fill_pixfmt() Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-29 11:28 ` Mauro Carvalho Chehab [this message] 2019-05-29 11:28 ` Mauro Carvalho Chehab 2019-05-29 11:43 ` Hans Verkuil 2019-05-29 11:43 ` Hans Verkuil 2019-05-29 11:58 ` Mauro Carvalho Chehab 2019-05-29 11:58 ` Mauro Carvalho Chehab 2019-05-29 12:16 ` Boris Brezillon 2019-05-29 12:16 ` Boris Brezillon 2019-05-29 12:26 ` Mauro Carvalho Chehab 2019-05-29 12:26 ` Mauro Carvalho Chehab 2019-05-29 12:29 ` Mauro Carvalho Chehab 2019-05-29 12:29 ` Mauro Carvalho Chehab 2019-05-29 12:31 ` Boris Brezillon 2019-05-29 12:31 ` Boris Brezillon 2019-05-29 12:31 ` Hans Verkuil 2019-05-29 12:31 ` Hans Verkuil 2019-05-29 12:39 ` Boris Brezillon 2019-05-29 12:39 ` Boris Brezillon 2019-05-29 14:04 ` Ezequiel Garcia 2019-05-29 14:04 ` Ezequiel Garcia 2019-05-29 14:06 ` Boris Brezillon 2019-05-29 14:06 ` Boris Brezillon 2019-05-29 14:17 ` Boris Brezillon 2019-05-29 14:17 ` Boris Brezillon 2019-05-29 14:47 ` Ezequiel Garcia 2019-05-29 14:47 ` Ezequiel Garcia 2019-05-29 13:54 ` Nicolas Dufresne 2019-05-29 13:54 ` Nicolas Dufresne 2019-05-29 14:02 ` Mauro Carvalho Chehab 2019-05-29 14:02 ` Mauro Carvalho Chehab 2019-05-28 17:02 ` [PATCH v6 04/16] rockchip/vpu: Use v4l2_apply_frmsize_constraints() where appropriate Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 05/16] rockchip/vpu: Open-code media controller register Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 06/16] rockchip/vpu: Support the Request API Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 07/16] rockchip/vpu: Rename rockchip_vpu_common.h into rockchip_vpu_v4l2.h Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 08/16] rockchip/vpu: Move encoder logic to a common place Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 09/16] rockchip/vpu: Provide a helper to reset both src and dst formats Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 10/16] rockchip/vpu: Prepare things to support decoders Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 11/16] rockchip/vpu: Add decoder boilerplate Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 12/16] rockchip/vpu: Add support for non-standard controls Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 13/16] rockchip/vpu: Add infra to support MPEG-2 decoding Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 14/16] rockchip/vpu: Add MPEG2 decoding support to RK3399 Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 15/16] rockchip/vpu: Add support for MPEG-2 decoding on RK3288 Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-28 17:02 ` [PATCH v6 16/16] rockchip/vpu: Add support for MPEG-2 decoding on RK3328 Ezequiel Garcia 2019-05-28 17:02 ` Ezequiel Garcia 2019-05-29 8:11 ` Hans Verkuil 2019-05-29 8:11 ` Hans Verkuil 2019-05-29 8:50 ` Jonas Karlman 2019-05-29 8:50 ` Jonas Karlman 2019-05-29 9:00 ` Hans Verkuil 2019-05-29 9:00 ` Hans Verkuil 2019-05-29 14:59 ` Ezequiel Garcia 2019-05-29 14:59 ` Ezequiel Garcia
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190529082809.0b9f3553@coco.lan \ --to=mchehab+samsung@kernel.org \ --cc=boris.brezillon@collabora.com \ --cc=ezequiel@collabora.com \ --cc=hans.verkuil@cisco.com \ --cc=heiko@sntech.de \ --cc=jonas@kwiboo.se \ --cc=kernel@collabora.com \ --cc=linux-media@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=nicolas.dufresne@collabora.com \ --cc=p.zabel@pengutronix.de \ --cc=tfiga@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.