Hi Guennadi,
On Tuesday 05 October 2010 17:30:21 Guennadi Liakhovetski wrote:
> On Tue, 5 Oct 2010, Sakari Ailus wrote:
> > Laurent Pinchart wrote:
> > > The header defines the v4l2_mbus_framefmt structure which will be used
> > > by the V4L2 subdevs userspace API.
> > >
> > > Change the type of the v4l2_mbus_framefmt::code field to __u32, as enum
> > > sizes can differ between different ABIs on the same architectures.
> > >
> > > Signed-off-by: Laurent Pinchart <[email protected]>
[snip]
> > > +/**
> > > + * struct v4l2_mbus_framefmt - frame format on the media bus
> > > + * @width: frame width
> > > + * @height: frame height
> > > + * @code: data format code
> > > + * @field: used interlacing type
> > > + * @colorspace: colorspace of the data
> > > + */
> > > +struct v4l2_mbus_framefmt {
> > > + __u32 width;
> > > + __u32 height;
> > > + __u32 code;
> > > + enum v4l2_field field;
> > > + enum v4l2_colorspace colorspace;
> > > +};
> >
> > I think this struct would benefit from some reserved fields since it's
> > part of the user space interface.
>
> IIUC, this struct is not going to be used in ioctl()s, that's what struct
> v4l2_subdev_mbus_code_enum is for. But in this case - why don't we make
> the "code" field above of type "enum v4l2_mbus_pixelcode"?
The v4l2_mbus_framefmt structure isn't used directly as an ioctl argument, but
it's embedded in the v4l2_subdev_format structure, used as an ioctl argument,
so its size matters.
The v4l2_subdev_format structure has reserved fields right after the
v4l2_mbus_framefmt member so there's some room for expansion. As for the
enums, I've reused the ones already in use in the V4L2 API, but I can replace
them with __u32.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
