Re: [PATCH v3 09/33] v4l: Add subdev selections documentation

Laurent Pinchart
2012-03-02T17:54:32Z

Hi Sakari,

On Friday 02 March 2012 14:24:40 Sakari Ailus wrote:
> On Tue, Feb 28, 2012 at 12:42:26PM +0100, Laurent Pinchart wrote:
> > On Sunday 26 February 2012 23:42:19 Sakari Ailus wrote:
> > > Laurent Pinchart wrote:
> > > > On Monday 20 February 2012 03:56:48 Sakari Ailus wrote:

> > > >> +
> > > >>
> > > >> - Cropping behaviour on output pads is not defined.
> > > >> +
> > > >> +
> > > >> +
> > > >> + Order of configuration and format propagation
> > > >> +
> > > >> + Inside subdevs, the order of image processing steps will
> > > >> + always be from the sink pad towards the source pad. This is
> > > >> also
> > > >> + reflected in the order in which the configuration must be
> > > >> + performed by the user: the changes made will be propagated to
> > > >> + any subsequent stages. If this behaviour is not desired, the
> > > >> + user must set
> > > >> + <constant>V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG</constant> flag.
> > > >
> > > > Could you explain what happens when V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG
> > > > is
> > > > set ? Just stating that it doesn't follow the propagation behaviour
> > > > previously described could be understood in many different ways.
> > >
> > > Good point. How about this:
> > >
> > > "This flag causes that no propagation of the changes are allowed in any
> > > circumstances. This may also lead the accessed rectangle not being
> > > changed at all,
> >
> > "The accessed rectangle will likely be adjusted by the driver,"
>
> Why "likely"? I think it should say "may" instead, but this of course
> depends on what the user asks.

I'm fine with "The accessed rectangle may be adjusted by the driver" (or
s/may/can/, as adjusting the rectangle is part of the negotiation mechanism
and is thus more likely than not).

> > > depending on the properties of the underlying hardware.
> > > Some drivers may not support this flag."
> >
> > What should happen then ? Should the flag be ignored, or should the driver
> > return an error ?
>
> Only the SMIA++ driver supports this flag so far (as goes for the subdev
> selection interface).
>
> I think it should be ignored. Consider a situation that we add a new flag
> which most of the drivers are unaware of.
>
> As we're adding the flag right at the time the interface is introduced, we
> could also require that all drivers must support it. How about that? In that
> case I'd remove the last sentence of that paragraph.

I think I'd like that better. Otherwise applications would be forced to check
the returned rectangle to find out if the flag was taken into account.

--
Regards,

Laurent Pinchart