From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> To: Nicolas Dufresne <nicolas.dufresne@collabora.com> Cc: Ezequiel Garcia <ezequiel@collabora.com>, linux-media@vger.kernel.org, Hans Verkuil <hans.verkuil@cisco.com>, kernel@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 11:02:33 -0300 [thread overview] Message-ID: <20190529110233.0ff81aff@coco.lan> (raw) In-Reply-To: <4ef64e22f4035fccf09fbb7f0be04a9778b1230d.camel@collabora.com> Em Wed, 29 May 2019 09:54:09 -0400 Nicolas Dufresne <nicolas.dufresne@collabora.com> escreveu: > Hi Mauro, > > Le mercredi 29 mai 2019 à 08:28 -0300, Mauro Carvalho Chehab a écrit : > > 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. > > We will really need this in the long run in many drivers in order to > allow import/export of DMABuf. Without such adaptive feature, we have a > software limitation that forces bouncing memory. I have already > discussed about adding this feature notably in vivid and uvcvideo on > IRC and in conference, which both have no restriction the memory > alignment, so should allow importing any kind of video layout. > > We already have a partial userspace implementation for this in > GStreamer and upstream driver submission should come when the IP is > considered stable enough. I understand the need. I'm not against an implementation for such feature, provided that it won't break anything. I guess one of the things we miss at V4L2 API is an indication from userspace about what it supports. I mean, just like we have the caps flags where the Kernel reports what it supports, we could have a similar "userspace caps" field. > Why I think it won't break userspace is that the correct way to use > these read-only members of V4L2 struct is to set these to 0, which is > also documented. Yeah, the apps I'm aware of usually call memset() before filling V4L2 structs. On those, adding this behavior would be ok. Yet, I'm not sure if 100% of (open source) apps do that. > Adding upper bound seems like a good idea though. Agreed. > > Thanks, Mauro
WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Nicolas Dufresne <nicolas.dufresne-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> Cc: 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>, kernel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org, Ezequiel Garcia <ezequiel-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 11:02:33 -0300 [thread overview] Message-ID: <20190529110233.0ff81aff@coco.lan> (raw) In-Reply-To: <4ef64e22f4035fccf09fbb7f0be04a9778b1230d.camel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> Em Wed, 29 May 2019 09:54:09 -0400 Nicolas Dufresne <nicolas.dufresne@collabora.com> escreveu: > Hi Mauro, > > Le mercredi 29 mai 2019 à 08:28 -0300, Mauro Carvalho Chehab a écrit : > > 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. > > We will really need this in the long run in many drivers in order to > allow import/export of DMABuf. Without such adaptive feature, we have a > software limitation that forces bouncing memory. I have already > discussed about adding this feature notably in vivid and uvcvideo on > IRC and in conference, which both have no restriction the memory > alignment, so should allow importing any kind of video layout. > > We already have a partial userspace implementation for this in > GStreamer and upstream driver submission should come when the IP is > considered stable enough. I understand the need. I'm not against an implementation for such feature, provided that it won't break anything. I guess one of the things we miss at V4L2 API is an indication from userspace about what it supports. I mean, just like we have the caps flags where the Kernel reports what it supports, we could have a similar "userspace caps" field. > Why I think it won't break userspace is that the correct way to use > these read-only members of V4L2 struct is to set these to 0, which is > also documented. Yeah, the apps I'm aware of usually call memset() before filling V4L2 structs. On those, adding this behavior would be ok. Yet, I'm not sure if 100% of (open source) apps do that. > Adding upper bound seems like a good idea though. Agreed. > > Thanks, Mauro _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2019-05-29 14:02 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 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 [this message] 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=20190529110233.0ff81aff@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.