[libcamera-devel] [PATCH 1/2] libcamera: v4l2-format: Add V4L2DeviceFormat
Jacopo Mondi
jacopo at jmondi.org
Fri Feb 1 11:07:12 CET 2019
Hi Laurent,
On Wed, Jan 30, 2019 at 12:39:41PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Mon, Jan 28, 2019 at 04:11:36PM +0100, Jacopo Mondi wrote:
> > Add a V4L2DeviceFormat class aimed to be used to provide format configuration
> > requests to a V4L2Device.
> >
> > Signed-off-by: Jacopo Mondi <jacopo at jmondi.org>
> > ---
> > src/libcamera/include/v4l2_device.h | 14 ++++++++
> > src/libcamera/v4l2_device.cpp | 56 +++++++++++++++++++++++++++++
> > 2 files changed, 70 insertions(+)
> >
> > diff --git a/src/libcamera/include/v4l2_device.h b/src/libcamera/include/v4l2_device.h
> > index c67ebbf..c70959e 100644
> > --- a/src/libcamera/include/v4l2_device.h
> > +++ b/src/libcamera/include/v4l2_device.h
> > @@ -53,6 +53,20 @@ struct V4L2Capability final : v4l2_capability {
> > }
> > };
> >
> > +class V4L2DeviceFormat
>
> Should this be named V4L2Format ?
>
As I expect a V4L2SubdeviceFormat, I would keep this as
V4L2DeviceFormat.
> > +{
> > +public:
> > + uint32_t width;
> > + uint32_t height;
>
> I would have gone for unsigned int instead of uint32_t as the exact
> integer type isn't really relevant, but uint32_t is fine too. You should
I went for the lenght-specific type because the v4l2 structures has
length specified. If not that relevant I can change back to unsigned
int maybe?
> however include stdint.h to ensure that v4l2_device.h stays
> self-contained.
I recall I had to add it, then it's not here anymore...
>
> > + uint32_t fourcc;
> > +
> > + struct {
> > + uint32_t size;
> > + uint32_t bpl;
> > + } planesFmt[3];
> > + unsigned int planes;
>
> I would have named the first field planes and the second numPlanes or
> planesCount.
>
or planesNum?
> > +};
> > +
> > class MediaEntity;
>
> Should we keep all forward declarations at the top of the file ?
> Otherwise we'll likely end up with duplicated forward declarations at
> some point.
>
I will change this library-wide.
> > class V4L2Device
> > {
> > diff --git a/src/libcamera/v4l2_device.cpp b/src/libcamera/v4l2_device.cpp
> > index 408f9b9..d6143f2 100644
> > --- a/src/libcamera/v4l2_device.cpp
> > +++ b/src/libcamera/v4l2_device.cpp
> > @@ -80,6 +80,62 @@ LOG_DEFINE_CATEGORY(V4L2)
> > * \return True if the device provides Streaming I/O IOCTLs
> > */
> >
> > +/**
> > + * \class V4L2DeviceFormat
> > + * \brief The V4L2 device image format and sizes
> > + *
> > + * Describes the image format and image sizes to be programmed on a V4L2
>
> "This class describes ...3
>
> It would be fine for the \brief text, but the documentation body should
> be made of full sentences.
>
> > + * video device. The image format is defined by fourcc code as defined by
>
> s/fourcc code/a fourcc code/
>
> Or maybe "a fourcc" (or "a 4CC" or "a FOURCC" ?), as the last C in
> fourcc stands for code already.
>
> > + * the V4L2 APIs with the V4L2_PIX_FMT_ macros, a visible width and height
>
> s/V4L2_PIX_FMT_/V4L2_PIX_FMT_*/
>
> > + * and a variable number of planes (1 to 3) with variable sizes and line
> > + * strides.
>
> I wouldn't say variable as they don't really vary. Maybe "and one to
> three planes with configurable line stride and total size for each
> plane" ?
>
ack
> > + *
> > + * Formats defined as 'single planar' by the V4L2 APIs are represented with
> > + * V4L2DeviceFormat instances with a single plane
> > + * (V4L2DeviceFormat::planes = 1). Semi-planar and multiplanar formats use
> > + * 2 and 3 planes respectively.
>
> I would add one paragraph here to explain that line and plane padding
> may not be separately configurable, depending on the device (devices
> that don't support the MPLANE API have a fixed relationship between
> padding for different planes), and how this works in that case (do we
> ignore padding information for planes > 0 ? do we require them to be
> specified an in sync, and return an error otherwise ?).
>
I'm not sure I got you here.
Why devices that do not support MPLANE should care about planes > 1 ?
> > + * V4L2DeviceFormat defines the exchange format between components that
> > + * receive image configuration requests from applications and a V4L2Device.
> > + * The V4L2Device validates and applies the requested size and format to
> > + * the device driver.
>
> Shouldn't we define the class as a way to pass format information to
> V4L2Device, without caring about what's on the other side (and thus
> without mentioning it's an exchange format) ?
>
> > + */
> > +
> > +/**
> > + * \var V4L2DeviceFormat::width
> > + * \brief The image width
>
> The image width in pixels
>
> > + */
> > +
> > +/**
> > + * \var V4L2DeviceFormat::height
> > + * \brief The image height
>
> In pixels here too.
>
> > + */
> > +
> > +/**
> > + * \var V4L2DeviceFormat::fourcc
> > + * \brief The pixel encoding scheme
> > + *
> > + * The fourcc code, as defined by the V4L2 APIs with the V4L2_PIX_FMT_ macros,
>
> s/APIs/API/
> s/V4L2_PIX_FMT_/V4L2_PIX_FMT_*/
>
> > + * that identifies the image format pixel encoding scheme.
> > + */
> > +
> > +/**
> > + * \var V4L2DeviceFormat::planesFmt
> > + * \brief The per-plane size information
>
> I'd mention "memory size" instead of just "size" to make it clear this
> doesn't refer to the size in pixels.
>
> > + *
> > + * Images are stored in memory in one or more data planes. Each data plane
> > + * has a specific size and line length, which could differ from the image
>
> s/size/memory size/ here too.
>
> > + * visible sizes to accommodate line or plane padding data.
> > + *
> > + * Only the first V4L2DeviceFormat::planes entries are considered valid.
>
> You could also write "\ref planes".
>
> > + *
>
> Extra blank line.
>
Thanks, please clarify the question I didn't get and I'll send a
fixups series on top of this.
Thanks
j
> > + */
> > +
> > +/**
> > + * \var V4L2DeviceFormat::planes
> > + * \brief The number of valid data planes
> > + */
> > +
> > /**
> > * \class V4L2Device
> > * \brief V4L2Device object and API
>
> --
> Regards,
>
> Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20190201/b9ecc512/attachment.sig>
More information about the libcamera-devel
mailing list