mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Kieran Bingham <kieran.bingham@ideasonboard.com>,
	linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Archit Taneja <architt@codeaurora.org>,
	Sean Paul <seanpaul@chromium.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] v4l: doc: clarify v4l2_mbus_fmt height definition
Date: Mon, 8 Jan 2018 16:32:47 +0100	[thread overview]
Message-ID: <20180108153247.GA23075@bigcity.dyn.berto.se> (raw)
In-Reply-To: <20180108151353.zn2ee2tbdq2yragp@valkosipuli.retiisi.org.uk>

Hi,

Thanks for your patch.

On 2018-01-08 17:13:53 +0200, Sakari Ailus wrote:
> Hi Kieran,
> 
> On Mon, Jan 08, 2018 at 02:45:49PM +0000, Kieran Bingham wrote:
> > The v4l2_mbus_fmt width and height corresponds directly with the
> > v4l2_pix_format definitions, yet the differences in documentation make
> > it ambiguous what to do in the event of field heights.
> > 
> > Clarify this by referencing the v4l2_pix_format which is explicit on the
> > matter, and by matching the terminology of 'image height' rather than
> > the misleading 'frame height'.

Nice that this relationship is documented as it have contributed to some 
confusion on my side in the past!

> > 
> > Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> > ---
> >  Documentation/media/uapi/v4l/subdev-formats.rst | 6 ++++--
> >  include/uapi/linux/v4l2-mediabus.h              | 4 ++--
> >  2 files changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst b/Documentation/media/uapi/v4l/subdev-formats.rst
> > index b1eea44550e1..a2a00202b430 100644
> > --- a/Documentation/media/uapi/v4l/subdev-formats.rst
> > +++ b/Documentation/media/uapi/v4l/subdev-formats.rst
> > @@ -16,10 +16,12 @@ Media Bus Formats
> >  
> >      * - __u32
> >        - ``width``
> > -      - Image width, in pixels.
> > +      - Image width in pixels. See struct
> > +	:c:type:`v4l2_pix_format`.
> >      * - __u32
> >        - ``height``
> > -      - Image height, in pixels.
> > +      - Image height in pixels. See struct
> > +	:c:type:`v4l2_pix_format`.
> >      * - __u32
> >        - ``code``
> >        - Format code, from enum
> > diff --git a/include/uapi/linux/v4l2-mediabus.h b/include/uapi/linux/v4l2-mediabus.h
> > index 6e20de63ec59..6b34108d0338 100644
> > --- a/include/uapi/linux/v4l2-mediabus.h
> > +++ b/include/uapi/linux/v4l2-mediabus.h
> > @@ -18,8 +18,8 @@
> >  
> >  /**
> >   * struct v4l2_mbus_framefmt - frame format on the media bus
> > - * @width:	frame width
> > - * @height:	frame height
> > + * @width:	image width
> > + * @height:	image height (see struct v4l2_pix_format)
> 
> Hmm. This is the media bus format and it has no direct relation to
> v4l2_pix_format. So no, I can't see what would be the point in making such
> a reference.

Well we have functions like v4l2_fill_pix_format() that do

    pix_fmt->width = mbus_fmt->width;
    pix_fmt->height = mbus_fmt->height;

So I think there at least is an implicit relation between the two 
structs. The issue I think Kieran is trying to address is in the case of 
TOP, BOTTOM and ALTERNATE field formats. From the v4l2_pix_format 
documentation on the height field:

   "Image height in pixels. If field is one of V4L2_FIELD_TOP, 
   V4L2_FIELD_BOTTOM or V4L2_FIELD_ALTERNATE then height refers to the 
   number of lines in the field, otherwise it refers to the number of 
   lines in the frame (which is twice the field height for interlaced 
   formats)."

But there are no such clear definition of the height field for 
v4l2_mbus_framefmt. This have cased some confusion for us which would be 
nice to clarify. I think it would be a good thing to add to the 
documentation if the height in v4l2_mbus_framefmt should describe the 
height of a frame or field. And if it should represent the frame height 
then v4l2_fill_pix_format() and v4l2_fill_mbus_format() should be 
updated to support converting from the two different formats for height.

> 
> >   * @code:	data format code (from enum v4l2_mbus_pixelcode)
> >   * @field:	used interlacing type (from enum v4l2_field)
> >   * @colorspace:	colorspace of the data (from enum v4l2_colorspace)
> 
> -- 
> Regards,
> 
> Sakari Ailus
> e-mail: sakari.ailus@iki.fi

-- 
Regards,
Niklas Söderlund

  reply	other threads:[~2018-01-08 15:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08 14:45 Kieran Bingham
2018-01-08 15:13 ` Sakari Ailus
2018-01-08 15:32   ` Niklas Söderlund [this message]
2018-01-08 15:48     ` Hans Verkuil
2018-01-08 16:11       ` Niklas Söderlund
2018-01-08 16:58         ` Hans Verkuil
2018-01-08 18:06       ` Kieran Bingham

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=20180108153247.GA23075@bigcity.dyn.berto.se \
    --to=niklas.soderlund@ragnatech.se \
    --cc=architt@codeaurora.org \
    --cc=hverkuil@xs4all.nl \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=sakari.ailus@iki.fi \
    --cc=seanpaul@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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®