Re: [PATCH/RFC 7/9 v2] v4l: add an image-bus API for configuring v4l2 subdev pixel and frame formats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 10 Nov 2009, Laurent Pinchart wrote:

> On Friday 30 October 2009 15:01:27 Guennadi Liakhovetski wrote:
> > Video subdevices, like cameras, decoders, connect to video bridges over
> > specialised busses. Data is being transferred over these busses in various
> > formats, which only loosely correspond to fourcc codes, describing how
> >  video data is stored in RAM. This is not a one-to-one correspondence,
> >  therefore we cannot use fourcc codes to configure subdevice output data
> >  formats. This patch adds codes for several such on-the-bus formats and an
> >  API, similar to the familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt()
> >  API for configuring those codes. After all users of the old API in struct
> >  v4l2_subdev_video_ops are converted, the API will be removed.
> 
> [snip]
> 
> > diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> > index 04193eb..1e86f39 100644
> > --- a/include/media/v4l2-subdev.h
> > +++ b/include/media/v4l2-subdev.h
> 
> [snip]
> 
> > @@ -206,6 +207,8 @@ struct v4l2_subdev_audio_ops {
> > 
> >     s_routing: see s_routing in audio_ops, except this version is for video
> >  	devices.
> > +
> > +   enum_imgbus_fmt: enumerate pixel formats provided by a video data
> 
> Do we need to make that dynamic (and O(n)) or could we use a static array of 
> image bug frame formats ?

The current soc-camera uses a static array. It works for its users, but I 
do not know about others.

> >  source */
> >  struct v4l2_subdev_video_ops {
> >  	int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32
> >  config); @@ -227,6 +230,11 @@ struct v4l2_subdev_video_ops {
> >  	int (*s_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
> >  	int (*g_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
> >  	int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
> > +	int (*enum_imgbus_fmt)(struct v4l2_subdev *sd, int index,
> > +			       enum v4l2_imgbus_pixelcode *code);
> > +	int (*g_imgbus_fmt)(struct v4l2_subdev *sd, struct v4l2_imgbus_framefmt
> >  *fmt);
> > +	int (*try_imgbus_fmt)(struct v4l2_subdev *sd, struct v4l2_imgbus_framefmt
> >  *fmt);
> > +	int (*s_imgbus_fmt)(struct v4l2_subdev *sd, struct v4l2_imgbus_framefmt
> > *fmt); };
> 
> Obviously those calls will need to be moved to pad operations later.

Right.

> They will 
> be exposed to userspace through ioctls on the media controller device and/or 
> the subdevices, so the v4l2_imgbus_pixelcode type shouldn't be an enum.

Ok, will use __u32 for it then just as all other enum types...

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux