Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration

[Philippe De Muyter]

On Mon, Mar 20, 2017 at 09:05:25AM +0000, Russell King - ARM Linux wrote:
> On Mon, Mar 20, 2017 at 09:55:12AM +0100, Philippe De Muyter wrote:
> > Hi Russel,
> > 
> > On Sun, Mar 19, 2017 at 10:49:08AM +0000, Russell King wrote:
> > > Add support for enumerating frame sizes and frame intervals from the
> > > first subdev via the V4L2 interfaces.
> > > 
> > > Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxx>
> > > ---
> > >  drivers/staging/media/imx/imx-media-capture.c | 62 +++++++++++++++++++++++++++
> > >  1 file changed, 62 insertions(+)
> > > 
> > ...
> > > +static int capture_enum_frameintervals(struct file *file, void *fh,
> > > +				       struct v4l2_frmivalenum *fival)
> > > +{
> > > +	struct capture_priv *priv = video_drvdata(file);
> > > +	const struct imx_media_pixfmt *cc;
> > > +	struct v4l2_subdev_frame_interval_enum fie = {
> > > +		.index = fival->index,
> > > +		.pad = priv->src_sd_pad,
> > > +		.width = fival->width,
> > > +		.height = fival->height,
> > > +		.which = V4L2_SUBDEV_FORMAT_ACTIVE,
> > > +	};
> > > +	int ret;
> > > +
> > > +	cc = imx_media_find_format(fival->pixel_format, CS_SEL_ANY, true);
> > > +	if (!cc)
> > > +		return -EINVAL;
> > > +
> > > +	fie.code = cc->codes[0];
> > > +
> > > +	ret = v4l2_subdev_call(priv->src_sd, pad, enum_frame_interval, NULL, &fie);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	fival->type = V4L2_FRMIVAL_TYPE_DISCRETE;
> > > +	fival->discrete = fie.interval;
> > 
> > For some parallel sensors (mine is a E2V ev76c560) "any" frame interval is possible,
> > and hence type should be V4L2_FRMIVAL_TYPE_CONTINUOUS.
> 
> For my sensor, any frame interval is also possible, but that isn't the
> point here.
> 
> /dev/video* only talks to the CSI source pad, not it's sink pad.  The
> sink pad gets configured with the sensor frame rate via the media
> controller API.  /dev/video* itself has no control over the sensor
> frame rate.
> 
> The media controller stuff completely changes the way the established
> /dev/video* functionality works - the ability to select arbitary frame
> sizes and frame rates supported by the ultimate sensor is gone.  All
> that needs to be setup through the media controller pipeline, one
> subdev at a time.
> 
So existing gstreamer applications using /dev/video* to control framerate,
and even gain and exposure won't work anymore :( ?

I had hoped to keep compatibility, with added robustness and functionality.

I seems like I'll stay with my NXP/Freescale old and imperfect kernel.

Best regards

Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles