lkml.org 
[lkml]   [2017]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration
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@armlinux.org.uk>
> > > ---
> > > 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

\
 
 \ /
  Last update: 2017-03-20 10:25    [W:0.261 / U:5.876 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site