Re: [RFC 0/4] Sub-device configuration models

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

 



Hi Mikhail

On Mon, Oct 21, 2024 at 05:29:33PM +0300, Mikhail Rudenko wrote:
>
> Hi, Sakari!
>
> On 2024-10-11 at 10:55 +03, Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> wrote:
>
> > Hello everyone,
> >
> > I've been recently working (with others) on sub-device streams support as
> > well as on internal pads. The two can be used to make sub-device
> > configuration more versatile.
> >
> > At the same time, the added interfaces are much more useful if we require
> > specific semantics of those interfaces, so that the user space knows
> > exactly what e.g. a given selection target signifies. However, as the same
> > selection rectangle could be used for a different purpose on a non-raw
> > sensor device, we need a way to tell how should the user space determine
> > how to use a given interface.
> >
> > I'm proposing to solve this problem by introducing sub-device
> > configuration models, and by the common raw sensor model, also present in
> > this patchset, in particular.
> >
> > This has been (and will, for some time, continue to be) the reason why I
> > have reviewed few sensor driver related patches lately. As we're
> > introducing a new interface, it's beneficial to be able to use that
> > interface right from the start, rather than trying to later on offer
> > compatibility support, which is almost always a fair amount of work with
> > less than desirable results in the driver.
> >
> > With this solved, I believe we can enable the use of the streams UAPI.
> >
> > Comments are welcome.
> >
> > The compiled documentation can be found in
> > <URL:https://www.retiisi.eu/~sailus/v4l2/tmp/meta-format/output/userspace-api/media/v4l/dev-subdev.html#sub-device-configuration-models>
> > and the patches here
> > <URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=metadata>, i.e.
> > they're on top of the metadata set.
>
> I've read the updated documentation you shared, and have a question
> concerning binning configuration. IIUC binning should be configured via
> set_selection(V4L2_SEL_TGT_COMPOSE). But I also see some existing

set_selection(V4L2_SEL_TGT_COMPOSE) on the internal image pad, stream
#0

> drivers configure binning via set_fmt() (imx296) or both set_fmt() and
> set_selection(V4L2_SEL_TGT_COMPOSE) (imx274). What will be the right way

Existing drivers have adopted creative solutions to allow control of
the binning factor but all of them are somewhat non-compliant with the
specs (we went in great lenght in looking at these in the media summit
2 years ago). We didn't have internal pads at the time.

> to add binning support to a driver I care about (ov4689), which
> presently does not implement any binning configuration at all?

Now that you can use internal pads, I would follow what is described
in patch 3/4 of this series.

Thanks
  j

>
> --
> Best regards,
> Mikhail
>




[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