[libcamera-devel,1/4] media: docs: Describe pixel array properties

9217 diff mbox series

The V4L2 selection API are also used to access the pixel array
properties of an image sensor, such as the size and position of active
pixels and the cropped area of the pixel matrix used to produce images.

Currently no clear definition of the different areas that compose an
image sensor pixel array matrix is provided in the specification, and
the actual meaning of each selection target when applied to an image
sensor was not provided.

Provide in the sub-device documentation the definition of the pixel
matrix properties and the selection target associated to each of them.

Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
---
 .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
 1 file changed, 81 insertions(+)

Hi Jacopo,

Thanks for the patchset.

This improves selection documentation quite a bit. Please see my comments
below.

On Wed, Aug 05, 2020 at 12:57:18PM +0200, Jacopo Mondi wrote:
> The V4L2 selection API are also used to access the pixel array
> properties of an image sensor, such as the size and position of active
> pixels and the cropped area of the pixel matrix used to produce images.
> 
> Currently no clear definition of the different areas that compose an
> image sensor pixel array matrix is provided in the specification, and
> the actual meaning of each selection target when applied to an image
> sensor was not provided.
> 
> Provide in the sub-device documentation the definition of the pixel
> matrix properties and the selection target associated to each of them.
> 
> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> ---
>  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
>  1 file changed, 81 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> index 134d2fb909fa4..c47861dff9b9b 100644
> --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
>  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
>  the image size either up or down. :ref:`v4l2-selection-flags`
>  
> +.. _v4l2-subdev-pixel-array-properties:
> +
> +Selection targets for image sensors properties
> +----------------------------------------------
> +
> +The V4L2 selection API can be used on sub-devices that represent an image
> +sensor to retrieve the sensor's pixel array matrix properties by using the
> +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> +
> +Sub-device drivers for image sensor usually register a single source pad, but in
> +the case they expose more, the pixel array properties can be accessed from
> +any of them.

Is this a hypothetical case or are there examples?

Also note that camera sensor drivers may expose more than one sub-devices,
only one of which represents the pixel array.

> +
> +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> +the immutable properties of the several different areas that compose the sensor
> +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> +units. The logical disposition of pixels is defined by the sensor read-out
> +starting point and direction, and may differ from the physical disposition of
> +the pixel units in the pixel array matrix.
> +
> +Each pixel matrix portion is contained in a larger rectangle, with the most

s/larger\K/ or equal/

s/most//

> +largest being the one that describes the pixel matrix physical size. This
> +defines a hierarchical positional system, where each rectangle is defined

s/,//

> +relatively to the largest available one among the ones exposed by the
> +sub-device driver. Each selection target and the associated pixel array portion
> +it represents are below presented in order from the largest to the smallest one.
> +
> +Pixel array physical size
> +^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The image sensor chip is composed by a number of physical pixels, not all of
> +them readable by the application processor. Invalid or unreadable lines might
> +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> +they might be tagged with an invalid data type (DT) so that the receiver
> +automatically discard them. The size of the whole pixel matrix area is
> +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> +defined as position (0, 0). All the other selection targets are defined
> +relatively to this, larger, rectangle. The rectangle returned by
> +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> +does not change at run-time and cannot be modified from userspace.
> +
> +Pixel array readable area
> +^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The V4L2_SEL_TGT_CROP_BOUNDS targets returns size and position of the readable
> +area of the pixel array matrix, including pixels with valid image data and pixel
> +used for calibration purposes, such as optical black pixels. It is not unlikely
> +that valid pixels and optical black pixels are surrounded by non-readable rows
> +and columns of pixels. Those does not concur in the definition of the

How about: "Only pixels that can be read out are included in the
V4L2_SEL_TGT_CROP_BOUNDS rectangle."?

> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. The rectangle returned by
> +V4L2_SEL_TGT_CROP_BOUNDS describes an immutable property of the image sensor, it
> +does not change at run-time and cannot be modified from userspace.
> +
> +Pixel array active area
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The portion of the pixel array which contains valid image data is defined as the
> +active area of the pixel matrix. The active pixel array is is accessed by mean

s/accessed/described/

Another word than "active" here would be great as we already have active
and try contexts for selections.

> +of the V4L2_SEL_TGT_CROP_DEFAULT target, and is contained in the larger

s/the larger//

> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. It represents the largest possible frame
> +resolution the sensor can produce and defines the dimension of the full

s/resolution/size/

> +field-of-view. The rectangle returned by V4L2_SEL_TGT_CROP_BOUNDS describes an

s/-/ /g

> +immutable property of the image sensor, it does not change at run-time and
> +cannot be modified from userspace.
> +
> +Analog crop rectangle
> +^^^^^^^^^^^^^^^^^^^^^
> +
> +The sensor driver might decide, in order to adjust the image resolution to best
> +match the one requested by applications, to only process a part of the active

s/, to\K/ instruct the hardware to/

> +pixel array matrix. The selected area is read-out and processed by the image
> +sensor on-board ISP in order to produce images of the desired size and
> +resolution while possible maintaing the largest possible field-of-view. The

s/size\K[^.]?*\./m

> +cropped portion of the pixel array which is used to produce images is returned

s/produce/read out/
s/returned/configured/

> +by the V4L2_SEL_TGT_CROP target and represent the only information that can

s/by/using/

I'd leave out the rest of the sentence after "target" above.

> +change at runtime as it depends on the currently configured sensor mode and
> +desired image resolution. If the sub-device driver supports that, userspace
> +can set the analog crop rectangle to select which portion of the pixel array
> +to read out.

How about instead:

Register list based drivers generally do not allow setting analogue crop
rectangles.

> +
>  
>  Types of selection targets
>  --------------------------

Hi Jacopo,

Some review comments below:

On 05/08/2020 12:57, Jacopo Mondi wrote:
> The V4L2 selection API are also used to access the pixel array

are -> is

> properties of an image sensor, such as the size and position of active
> pixels and the cropped area of the pixel matrix used to produce images.
> 
> Currently no clear definition of the different areas that compose an
> image sensor pixel array matrix is provided in the specification, and
> the actual meaning of each selection target when applied to an image
> sensor was not provided.
> 
> Provide in the sub-device documentation the definition of the pixel
> matrix properties and the selection target associated to each of them.
> 
> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> ---
>  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
>  1 file changed, 81 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> index 134d2fb909fa4..c47861dff9b9b 100644
> --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
>  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
>  the image size either up or down. :ref:`v4l2-selection-flags`
>  
> +.. _v4l2-subdev-pixel-array-properties:
> +
> +Selection targets for image sensors properties
> +----------------------------------------------
> +
> +The V4L2 selection API can be used on sub-devices that represent an image
> +sensor to retrieve the sensor's pixel array matrix properties by using the
> +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> +
> +Sub-device drivers for image sensor usually register a single source pad, but in
> +the case they expose more, the pixel array properties can be accessed from
> +any of them.
> +
> +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,

V4L2_SEL_TGT_NATIVE -> V4L2_SEL_TGT_NATIVE_SIZE

(same mistake is made elsewhere).

> +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> +the immutable properties of the several different areas that compose the sensor
> +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> +units. The logical disposition of pixels is defined by the sensor read-out
> +starting point and direction, and may differ from the physical disposition of
> +the pixel units in the pixel array matrix.
> +
> +Each pixel matrix portion is contained in a larger rectangle, with the most
> +largest being the one that describes the pixel matrix physical size. This
> +defines a hierarchical positional system, where each rectangle is defined
> +relatively to the largest available one among the ones exposed by the
> +sub-device driver. Each selection target and the associated pixel array portion
> +it represents are below presented in order from the largest to the smallest one.
> +
> +Pixel array physical size
> +^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The image sensor chip is composed by a number of physical pixels, not all of
> +them readable by the application processor. Invalid or unreadable lines might
> +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> +they might be tagged with an invalid data type (DT) so that the receiver
> +automatically discard them. The size of the whole pixel matrix area is
> +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> +defined as position (0, 0). All the other selection targets are defined
> +relatively to this, larger, rectangle. The rectangle returned by
> +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> +does not change at run-time and cannot be modified from userspace.

It is a good idea to mention that if there are no invalid or unreadable pixels/lines,
then V4L2_SEL_TGT_NATIVE_SIZE == V4L2_SEL_TGT_CROP_BOUNDS.

> +
> +Pixel array readable area
> +^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The V4L2_SEL_TGT_CROP_BOUNDS targets returns size and position of the readable
> +area of the pixel array matrix, including pixels with valid image data and pixel
> +used for calibration purposes, such as optical black pixels. It is not unlikely
> +that valid pixels and optical black pixels are surrounded by non-readable rows
> +and columns of pixels. Those does not concur in the definition of the
> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. The rectangle returned by
> +V4L2_SEL_TGT_CROP_BOUNDS describes an immutable property of the image sensor, it
> +does not change at run-time and cannot be modified from userspace.

Mention that BOUNDS is enclosed by NATIVE_SIZE.

> +
> +Pixel array active area
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The portion of the pixel array which contains valid image data is defined as the
> +active area of the pixel matrix. The active pixel array is is accessed by mean

mean -> means

> +of the V4L2_SEL_TGT_CROP_DEFAULT target, and is contained in the larger
> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. It represents the largest possible frame
> +resolution the sensor can produce and defines the dimension of the full
> +field-of-view. The rectangle returned by V4L2_SEL_TGT_CROP_BOUNDS describes an

BOUNDS -> DEFAULT

> +immutable property of the image sensor, it does not change at run-time and
> +cannot be modified from userspace.

Mention that CROP_DEFAULT is enclosed by CROP_BOUNDS

> +
> +Analog crop rectangle

Why analog? It's just the crop rectangle, nothing analog about it.

> +^^^^^^^^^^^^^^^^^^^^^
> +
> +The sensor driver might decide, in order to adjust the image resolution to best
> +match the one requested by applications, to only process a part of the active
> +pixel array matrix. The selected area is read-out and processed by the image
> +sensor on-board ISP in order to produce images of the desired size and
> +resolution while possible maintaing the largest possible field-of-view. The

maintaing -> maintaining

Actually, I'd drop 'while possible maintaing the largest possible field-of-view'
entirely. It doesn't make much sense.

> +cropped portion of the pixel array which is used to produce images is returned
> +by the V4L2_SEL_TGT_CROP target and represent the only information that can

represent -> represents

> +change at runtime as it depends on the currently configured sensor mode and
> +desired image resolution. If the sub-device driver supports that, userspace
> +can set the analog crop rectangle to select which portion of the pixel array

s/analog//

> +to read out.

Mention that CROP is enclosed by CROP_BOUNDS and defaults to CROP_DEFAULT.

Make a note that CROP can also be used to obtain optical black pixels.

> +
>  
>  Types of selection targets
>  --------------------------
> 

Regards,

	Hans

Hi Hans,

On Thu, Aug 06, 2020 at 10:05:37AM +0200, Hans Verkuil wrote:
> Hi Jacopo,
>
> Some review comments below:
>
> On 05/08/2020 12:57, Jacopo Mondi wrote:
> > The V4L2 selection API are also used to access the pixel array
>
> are -> is
>
> > properties of an image sensor, such as the size and position of active
> > pixels and the cropped area of the pixel matrix used to produce images.
> >
> > Currently no clear definition of the different areas that compose an
> > image sensor pixel array matrix is provided in the specification, and
> > the actual meaning of each selection target when applied to an image
> > sensor was not provided.
> >
> > Provide in the sub-device documentation the definition of the pixel
> > matrix properties and the selection target associated to each of them.
> >
> > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > ---
> >  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> >  1 file changed, 81 insertions(+)
> >
> > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > index 134d2fb909fa4..c47861dff9b9b 100644
> > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> >  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> >  the image size either up or down. :ref:`v4l2-selection-flags`
> >
> > +.. _v4l2-subdev-pixel-array-properties:
> > +
> > +Selection targets for image sensors properties
> > +----------------------------------------------
> > +
> > +The V4L2 selection API can be used on sub-devices that represent an image
> > +sensor to retrieve the sensor's pixel array matrix properties by using the
> > +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > +
> > +Sub-device drivers for image sensor usually register a single source pad, but in
> > +the case they expose more, the pixel array properties can be accessed from
> > +any of them.
> > +
> > +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
>
> V4L2_SEL_TGT_NATIVE -> V4L2_SEL_TGT_NATIVE_SIZE
>
> (same mistake is made elsewhere).

Ah ups, I used TGT_NATIVE consistently, seems like I thought that was
the right name

>
> > +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > +the immutable properties of the several different areas that compose the sensor
> > +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> > +units. The logical disposition of pixels is defined by the sensor read-out
> > +starting point and direction, and may differ from the physical disposition of
> > +the pixel units in the pixel array matrix.
> > +
> > +Each pixel matrix portion is contained in a larger rectangle, with the most
> > +largest being the one that describes the pixel matrix physical size. This
> > +defines a hierarchical positional system, where each rectangle is defined
> > +relatively to the largest available one among the ones exposed by the
> > +sub-device driver. Each selection target and the associated pixel array portion
> > +it represents are below presented in order from the largest to the smallest one.
> > +
> > +Pixel array physical size
> > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The image sensor chip is composed by a number of physical pixels, not all of
> > +them readable by the application processor. Invalid or unreadable lines might
> > +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > +they might be tagged with an invalid data type (DT) so that the receiver
> > +automatically discard them. The size of the whole pixel matrix area is
> > +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > +defined as position (0, 0). All the other selection targets are defined
> > +relatively to this, larger, rectangle. The rectangle returned by
> > +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > +does not change at run-time and cannot be modified from userspace.
>
> It is a good idea to mention that if there are no invalid or unreadable pixels/lines,
> then V4L2_SEL_TGT_NATIVE_SIZE == V4L2_SEL_TGT_CROP_BOUNDS.

Yes it is! I'll add it here

>
> > +
> > +Pixel array readable area
> > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The V4L2_SEL_TGT_CROP_BOUNDS targets returns size and position of the readable
> > +area of the pixel array matrix, including pixels with valid image data and pixel
> > +used for calibration purposes, such as optical black pixels. It is not unlikely
> > +that valid pixels and optical black pixels are surrounded by non-readable rows
> > +and columns of pixels. Those does not concur in the definition of the
> > +V4L2_SEL_TGT_CROP_BOUNDS rectangle. The rectangle returned by
> > +V4L2_SEL_TGT_CROP_BOUNDS describes an immutable property of the image sensor, it
> > +does not change at run-time and cannot be modified from userspace.
>
> Mention that BOUNDS is enclosed by NATIVE_SIZE.
>

I tried to express that in the intro section with

"Each pixel matrix portion is contained in a larger rectangle, with the most
largest being the one that describes the pixel matrix physical size."

But I guess it's worth to express that for each target!

> > +
> > +Pixel array active area
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The portion of the pixel array which contains valid image data is defined as the
> > +active area of the pixel matrix. The active pixel array is is accessed by mean
>
> mean -> means
>
> > +of the V4L2_SEL_TGT_CROP_DEFAULT target, and is contained in the larger
> > +V4L2_SEL_TGT_CROP_BOUNDS rectangle. It represents the largest possible frame
> > +resolution the sensor can produce and defines the dimension of the full
> > +field-of-view. The rectangle returned by V4L2_SEL_TGT_CROP_BOUNDS describes an
>
> BOUNDS -> DEFAULT
>

ups

> > +immutable property of the image sensor, it does not change at run-time and
> > +cannot be modified from userspace.
>
> Mention that CROP_DEFAULT is enclosed by CROP_BOUNDS
>
> > +
> > +Analog crop rectangle
>
> Why analog? It's just the crop rectangle, nothing analog about it.
>

We used the 'analogCrop' term in libcamera to differentiate the
cropping which happens on the sensor pixel array matrix to select the
region to process and produce image from. Sensor with an on-board
scaler can perform other cropping steps to implement, in example digital
zoom, so we expect to have a 'digital crop' phase as well. RAW
sensors, in example, will only have an analogCrop rectangle.

Quoting the libcamera definition of analog crop:

 * horizontal and vertical sizes define the portion of the pixel array which
 * is read-out and provided to the sensor's internal processing pipeline, before
 * any pixel sub-sampling method, such as pixel binning, skipping and averaging
 * take place.

should I keep it or remove it ?

> > +^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The sensor driver might decide, in order to adjust the image resolution to best
> > +match the one requested by applications, to only process a part of the active
> > +pixel array matrix. The selected area is read-out and processed by the image
> > +sensor on-board ISP in order to produce images of the desired size and
> > +resolution while possible maintaing the largest possible field-of-view. The
>
> maintaing -> maintaining
>
> Actually, I'd drop 'while possible maintaing the largest possible field-of-view'
> entirely. It doesn't make much sense.

Ack

>
> > +cropped portion of the pixel array which is used to produce images is returned
> > +by the V4L2_SEL_TGT_CROP target and represent the only information that can
>
> represent -> represents
>
> > +change at runtime as it depends on the currently configured sensor mode and
> > +desired image resolution. If the sub-device driver supports that, userspace
> > +can set the analog crop rectangle to select which portion of the pixel array
>
> s/analog//
>
> > +to read out.
>
> Mention that CROP is enclosed by CROP_BOUNDS and defaults to CROP_DEFAULT.
>
> Make a note that CROP can also be used to obtain optical black pixels.
>

What about:

+desired image resolution. If the sub-device driver supports that, userspace
+can set the analog crop rectangle to select which portion of the pixel array
+to read out including, if supported, optical black pixels.

?

Thanks
  j

> > +
> >
> >  Types of selection targets
> >  --------------------------
> >
>
> Regards,
>
> 	Hans

On 06/08/2020 11:50, Jacopo Mondi wrote:
> Hi Hans,
> 
> On Thu, Aug 06, 2020 at 10:05:37AM +0200, Hans Verkuil wrote:
>> Hi Jacopo,
>>
>> Some review comments below:
>>
>> On 05/08/2020 12:57, Jacopo Mondi wrote:
>>> The V4L2 selection API are also used to access the pixel array
>>
>> are -> is
>>
>>> properties of an image sensor, such as the size and position of active
>>> pixels and the cropped area of the pixel matrix used to produce images.
>>>
>>> Currently no clear definition of the different areas that compose an
>>> image sensor pixel array matrix is provided in the specification, and
>>> the actual meaning of each selection target when applied to an image
>>> sensor was not provided.
>>>
>>> Provide in the sub-device documentation the definition of the pixel
>>> matrix properties and the selection target associated to each of them.
>>>
>>> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
>>> ---
>>>  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
>>>  1 file changed, 81 insertions(+)
>>>
>>> diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
>>> index 134d2fb909fa4..c47861dff9b9b 100644
>>> --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
>>> +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
>>> @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
>>>  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
>>>  the image size either up or down. :ref:`v4l2-selection-flags`
>>>
>>> +.. _v4l2-subdev-pixel-array-properties:
>>> +
>>> +Selection targets for image sensors properties
>>> +----------------------------------------------
>>> +
>>> +The V4L2 selection API can be used on sub-devices that represent an image
>>> +sensor to retrieve the sensor's pixel array matrix properties by using the
>>> +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
>>> +
>>> +Sub-device drivers for image sensor usually register a single source pad, but in
>>> +the case they expose more, the pixel array properties can be accessed from
>>> +any of them.
>>> +
>>> +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
>>
>> V4L2_SEL_TGT_NATIVE -> V4L2_SEL_TGT_NATIVE_SIZE
>>
>> (same mistake is made elsewhere).
> 
> Ah ups, I used TGT_NATIVE consistently, seems like I thought that was
> the right name
> 
>>
>>> +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
>>> +the immutable properties of the several different areas that compose the sensor
>>> +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
>>> +units. The logical disposition of pixels is defined by the sensor read-out
>>> +starting point and direction, and may differ from the physical disposition of
>>> +the pixel units in the pixel array matrix.
>>> +
>>> +Each pixel matrix portion is contained in a larger rectangle, with the most
>>> +largest being the one that describes the pixel matrix physical size. This
>>> +defines a hierarchical positional system, where each rectangle is defined
>>> +relatively to the largest available one among the ones exposed by the
>>> +sub-device driver. Each selection target and the associated pixel array portion
>>> +it represents are below presented in order from the largest to the smallest one.
>>> +
>>> +Pixel array physical size
>>> +^^^^^^^^^^^^^^^^^^^^^^^^^
>>> +
>>> +The image sensor chip is composed by a number of physical pixels, not all of
>>> +them readable by the application processor. Invalid or unreadable lines might
>>> +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
>>> +they might be tagged with an invalid data type (DT) so that the receiver
>>> +automatically discard them. The size of the whole pixel matrix area is
>>> +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
>>> +defined as position (0, 0). All the other selection targets are defined
>>> +relatively to this, larger, rectangle. The rectangle returned by
>>> +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
>>> +does not change at run-time and cannot be modified from userspace.
>>
>> It is a good idea to mention that if there are no invalid or unreadable pixels/lines,
>> then V4L2_SEL_TGT_NATIVE_SIZE == V4L2_SEL_TGT_CROP_BOUNDS.
> 
> Yes it is! I'll add it here
> 
>>
>>> +
>>> +Pixel array readable area
>>> +^^^^^^^^^^^^^^^^^^^^^^^^^
>>> +
>>> +The V4L2_SEL_TGT_CROP_BOUNDS targets returns size and position of the readable
>>> +area of the pixel array matrix, including pixels with valid image data and pixel
>>> +used for calibration purposes, such as optical black pixels. It is not unlikely
>>> +that valid pixels and optical black pixels are surrounded by non-readable rows
>>> +and columns of pixels. Those does not concur in the definition of the
>>> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. The rectangle returned by
>>> +V4L2_SEL_TGT_CROP_BOUNDS describes an immutable property of the image sensor, it
>>> +does not change at run-time and cannot be modified from userspace.
>>
>> Mention that BOUNDS is enclosed by NATIVE_SIZE.
>>
> 
> I tried to express that in the intro section with
> 
> "Each pixel matrix portion is contained in a larger rectangle, with the most
> largest being the one that describes the pixel matrix physical size."
> 
> But I guess it's worth to express that for each target!
> 
>>> +
>>> +Pixel array active area
>>> +^^^^^^^^^^^^^^^^^^^^^^^
>>> +
>>> +The portion of the pixel array which contains valid image data is defined as the
>>> +active area of the pixel matrix. The active pixel array is is accessed by mean
>>
>> mean -> means
>>
>>> +of the V4L2_SEL_TGT_CROP_DEFAULT target, and is contained in the larger
>>> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. It represents the largest possible frame
>>> +resolution the sensor can produce and defines the dimension of the full
>>> +field-of-view. The rectangle returned by V4L2_SEL_TGT_CROP_BOUNDS describes an
>>
>> BOUNDS -> DEFAULT
>>
> 
> ups
> 
>>> +immutable property of the image sensor, it does not change at run-time and
>>> +cannot be modified from userspace.
>>
>> Mention that CROP_DEFAULT is enclosed by CROP_BOUNDS
>>
>>> +
>>> +Analog crop rectangle
>>
>> Why analog? It's just the crop rectangle, nothing analog about it.
>>
> 
> We used the 'analogCrop' term in libcamera to differentiate the
> cropping which happens on the sensor pixel array matrix to select the
> region to process and produce image from. Sensor with an on-board
> scaler can perform other cropping steps to implement, in example digital
> zoom, so we expect to have a 'digital crop' phase as well. RAW
> sensors, in example, will only have an analogCrop rectangle.
> 
> Quoting the libcamera definition of analog crop:
> 
>  * horizontal and vertical sizes define the portion of the pixel array which
>  * is read-out and provided to the sensor's internal processing pipeline, before
>  * any pixel sub-sampling method, such as pixel binning, skipping and averaging
>  * take place.
> 
> should I keep it or remove it ?

It's a very confusing term. Especially since this API can also be used with analog
video capture devices (Composite/S-Video) where the video signal actually is analog.

In the V4L2 API there is no such thing as 'analog crop', so please remove it.

> 
>>> +^^^^^^^^^^^^^^^^^^^^^
>>> +
>>> +The sensor driver might decide, in order to adjust the image resolution to best
>>> +match the one requested by applications, to only process a part of the active
>>> +pixel array matrix. The selected area is read-out and processed by the image
>>> +sensor on-board ISP in order to produce images of the desired size and
>>> +resolution while possible maintaing the largest possible field-of-view. The
>>
>> maintaing -> maintaining
>>
>> Actually, I'd drop 'while possible maintaing the largest possible field-of-view'
>> entirely. It doesn't make much sense.
> 
> Ack
> 
>>
>>> +cropped portion of the pixel array which is used to produce images is returned
>>> +by the V4L2_SEL_TGT_CROP target and represent the only information that can
>>
>> represent -> represents
>>
>>> +change at runtime as it depends on the currently configured sensor mode and
>>> +desired image resolution. If the sub-device driver supports that, userspace
>>> +can set the analog crop rectangle to select which portion of the pixel array
>>
>> s/analog//
>>
>>> +to read out.
>>
>> Mention that CROP is enclosed by CROP_BOUNDS and defaults to CROP_DEFAULT.
>>
>> Make a note that CROP can also be used to obtain optical black pixels.
>>
> 
> What about:
> 
> +desired image resolution. If the sub-device driver supports that, userspace
> +can set the analog crop rectangle to select which portion of the pixel array
> +to read out including, if supported, optical black pixels.

Hmm, that's a bit awkward. How about:

+desired image resolution. If supported by the sub-device driver, userspace
+can set the crop rectangle to select which portion of the pixel array
+to read out. This may include optical black pixels if those are part of
+V4L2_SEL_TGT_CROP_BOUNDS.

Regards,

	Hans

> 
> ?
> 
> Thanks
>   j
> 
>>> +
>>>
>>>  Types of selection targets
>>>  --------------------------
>>>
>>
>> Regards,
>>
>> 	Hans

Hi Hans,

On Thu, Aug 06, 2020 at 11:58:31AM +0200, Hans Verkuil wrote:
> On 06/08/2020 11:50, Jacopo Mondi wrote:
> > Hi Hans,
> > 
> > On Thu, Aug 06, 2020 at 10:05:37AM +0200, Hans Verkuil wrote:
> >> Hi Jacopo,
> >>
> >> Some review comments below:
> >>
> >> On 05/08/2020 12:57, Jacopo Mondi wrote:
> >>> +Analog crop rectangle
> >>
> >> Why analog? It's just the crop rectangle, nothing analog about it.
> >>
> > 
> > We used the 'analogCrop' term in libcamera to differentiate the
> > cropping which happens on the sensor pixel array matrix to select the
> > region to process and produce image from. Sensor with an on-board
> > scaler can perform other cropping steps to implement, in example digital
> > zoom, so we expect to have a 'digital crop' phase as well. RAW
> > sensors, in example, will only have an analogCrop rectangle.
> > 
> > Quoting the libcamera definition of analog crop:
> > 
> >  * horizontal and vertical sizes define the portion of the pixel array which
> >  * is read-out and provided to the sensor's internal processing pipeline, before
> >  * any pixel sub-sampling method, such as pixel binning, skipping and averaging
> >  * take place.
> > 
> > should I keep it or remove it ?
> 
> It's a very confusing term. Especially since this API can also be used with analog
> video capture devices (Composite/S-Video) where the video signal actually is analog.
> 
> In the V4L2 API there is no such thing as 'analog crop', so please remove it.

There isn't in the V4L2 API but I don't see why we couldn't document it
here. Analogue crop is an established term related to raw (perhaps others,
too?) camera sensors which describes cropping that is implemented by not
reading parts of the pixel array.

As this documentation only applies to camera sensors, I think it's entirely
appropriate to document this here, and using that term.

On 06/08/2020 14:54, Sakari Ailus wrote:
> Hi Hans,
> 
> On Thu, Aug 06, 2020 at 11:58:31AM +0200, Hans Verkuil wrote:
>> On 06/08/2020 11:50, Jacopo Mondi wrote:
>>> Hi Hans,
>>>
>>> On Thu, Aug 06, 2020 at 10:05:37AM +0200, Hans Verkuil wrote:
>>>> Hi Jacopo,
>>>>
>>>> Some review comments below:
>>>>
>>>> On 05/08/2020 12:57, Jacopo Mondi wrote:
>>>>> +Analog crop rectangle
>>>>
>>>> Why analog? It's just the crop rectangle, nothing analog about it.
>>>>
>>>
>>> We used the 'analogCrop' term in libcamera to differentiate the
>>> cropping which happens on the sensor pixel array matrix to select the
>>> region to process and produce image from. Sensor with an on-board
>>> scaler can perform other cropping steps to implement, in example digital
>>> zoom, so we expect to have a 'digital crop' phase as well. RAW
>>> sensors, in example, will only have an analogCrop rectangle.
>>>
>>> Quoting the libcamera definition of analog crop:
>>>
>>>  * horizontal and vertical sizes define the portion of the pixel array which
>>>  * is read-out and provided to the sensor's internal processing pipeline, before
>>>  * any pixel sub-sampling method, such as pixel binning, skipping and averaging
>>>  * take place.
>>>
>>> should I keep it or remove it ?
>>
>> It's a very confusing term. Especially since this API can also be used with analog
>> video capture devices (Composite/S-Video) where the video signal actually is analog.
>>
>> In the V4L2 API there is no such thing as 'analog crop', so please remove it.
> 
> There isn't in the V4L2 API but I don't see why we couldn't document it
> here. Analogue crop is an established term related to raw (perhaps others,
> too?) camera sensors which describes cropping that is implemented by not
> reading parts of the pixel array.
> 
> As this documentation only applies to camera sensors, I think it's entirely
> appropriate to document this here, and using that term.
> 

It's always been called just 'crop' in the V4L2 API, so renaming it suddenly
to something else is IMHO confusing. What you can do, however, is that in the
description of the "crop rectangle" you mention that "it is also known as
"analog crop" in the context of camera sensors.

With perhaps some more extensive explanation of the term.

Regards,

	Hans

Hi Jacopo, Hans,

On Thu, Aug 06, 2020 at 11:58:31AM +0200, Hans Verkuil wrote:
> On 06/08/2020 11:50, Jacopo Mondi wrote:
> > On Thu, Aug 06, 2020 at 10:05:37AM +0200, Hans Verkuil wrote:
> >> On 05/08/2020 12:57, Jacopo Mondi wrote:
> >>> The V4L2 selection API are also used to access the pixel array
> >>
> >> are -> is
> >>
> >>> properties of an image sensor, such as the size and position of active
> >>> pixels and the cropped area of the pixel matrix used to produce images.
> >>>
> >>> Currently no clear definition of the different areas that compose an
> >>> image sensor pixel array matrix is provided in the specification, and
> >>> the actual meaning of each selection target when applied to an image
> >>> sensor was not provided.
> >>>
> >>> Provide in the sub-device documentation the definition of the pixel
> >>> matrix properties and the selection target associated to each of them.
> >>>
> >>> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> >>> ---
> >>>  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> >>>  1 file changed, 81 insertions(+)
> >>>
> >>> diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> >>> index 134d2fb909fa4..c47861dff9b9b 100644
> >>> --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> >>> +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> >>> @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> >>>  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> >>>  the image size either up or down. :ref:`v4l2-selection-flags`
> >>>
> >>> +.. _v4l2-subdev-pixel-array-properties:
> >>> +
> >>> +Selection targets for image sensors properties

Maybe "Selection targets for image sensors", and renaming the reference
to v4l2-subdev-selections-image-sensors ? This section is about how
selection rectangles are used for sensors, right ?

> >>> +----------------------------------------------

I'd move this further down, after "Types of selection targets", as that
section contains generic information that applies to sensors too.

> >>> +
> >>> +The V4L2 selection API can be used on sub-devices that represent an image
> >>> +sensor to retrieve the sensor's pixel array matrix properties by using the
> >>> +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> >>> +
> >>> +Sub-device drivers for image sensor usually register a single source pad, but in
> >>> +the case they expose more, the pixel array properties can be accessed from
> >>> +any of them.

Is this right ? I don't think the V4L2_SEL_TGT_CROP rectangle, for
instance, can be accessed from any source pad indifferently. Do we have
sensor drivers that create multiple source pads in a subdev today ? If
not I'd suggest dropping this, and adding it later if needed (when we'll
have a better idea of how that would work).

I think what should be explained here, as also mentioned by Sakari, is
that camera sensors can be exposed as multiple subdevs. The text below
is related to the pixel array, which is always the first subdev, with
one source pad and no sink pad. The other subdevs, modelling additional
processing blocks in the sensor, may use the selection API, but that's
out of scope for this patch.

As we'll also need to document how other subdevs use the selection API,
as well as how sensors are usually handled, would it make sense to move
this to a separate file ? Sakari has proposed in [1] to create a new
Documentation/driver-api/media/camera-sensor.rst file. It would make
sense to centralize all sensor information there. This doesn't mean this
series should depend on Sakari's patch, we can handle merge conflicts
depending on what gets merged first.

[1] https://lore.kernel.org/linux-media/20200730162040.15560-1-sakari.ailus@linux.intel.com/

> >>> +
> >>> +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> >>
> >> V4L2_SEL_TGT_NATIVE -> V4L2_SEL_TGT_NATIVE_SIZE
> >>
> >> (same mistake is made elsewhere).
> > 
> > Ah ups, I used TGT_NATIVE consistently, seems like I thought that was
> > the right name
> > 
> >>> +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> >>> +the immutable properties of the several different areas that compose the sensor
> >>> +pixel array matrix. Each area describes a rectangle of logically adjacent pixel

V4L2_TGT_CROP isn't immutable, is it ?

> >>> +units. The logical disposition of pixels is defined by the sensor read-out
> >>> +starting point and direction, and may differ from the physical disposition of
> >>> +the pixel units in the pixel array matrix.
> >>> +
> >>> +Each pixel matrix portion is contained in a larger rectangle, with the most
> >>> +largest being the one that describes the pixel matrix physical size. This
> >>> +defines a hierarchical positional system, where each rectangle is defined
> >>> +relatively to the largest available one among the ones exposed by the
> >>> +sub-device driver. Each selection target and the associated pixel array portion
> >>> +it represents are below presented in order from the largest to the smallest one.

I find this quite confusing. As Hans suggested, I think each target
should define its boundaries. I'd drop this paragraph completely, as you
already explain below that all rectangles are defined relatively to
V4L2_SEL_TGT_NATIVE_SIZE.

> >>> +
> >>> +Pixel array physical size
> >>> +^^^^^^^^^^^^^^^^^^^^^^^^^
> >>> +
> >>> +The image sensor chip is composed by a number of physical pixels, not all of
> >>> +them readable by the application processor. Invalid or unreadable lines might
> >>> +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> >>> +they might be tagged with an invalid data type (DT) so that the receiver
> >>> +automatically discard them.

"might" is a bit weak for unreadable lines, there's no way they can be
transmitted if they can't be read :-)

One way to generalize this a bit would be to explain, after the first
sentence, that not all pixels may be read by the sensor, that among the
pixels that are read invalid ones may not be transmitted on the bus, and
that among transmitted pixels not all of them may be possible to capture
on the receiver side. For instance, invalid lines may be transmitted as
part of the vertical blanking on parallel buses, or tagged as blanking
data or null data on CSI-2 buses. Most receivers are not able to capture
either.

(On a side note, strictly speaking, a CSI-2 receiver that would be able
to capture null or blanking packets wouldn't be compliant with the CSI-2
spec.)

> >>> The size of the whole pixel matrix area is
> >>> +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> >>> +defined as position (0, 0). All the other selection targets are defined
> >>> +relatively to this, larger, rectangle. The rectangle returned by

s/, larger,/

> >>> +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> >>> +does not change at run-time and cannot be modified from userspace.
> >>
> >> It is a good idea to mention that if there are no invalid or unreadable pixels/lines,
> >> then V4L2_SEL_TGT_NATIVE_SIZE == V4L2_SEL_TGT_CROP_BOUNDS.
> > 
> > Yes it is! I'll add it here

Should it be added below instead, where you define
V4L2_SEL_TGT_CROP_BOUNDS ? It's best to avoid mentioning something that
isn't defined yet when possible.

> >>> +
> >>> +Pixel array readable area
> >>> +^^^^^^^^^^^^^^^^^^^^^^^^^
> >>> +
> >>> +The V4L2_SEL_TGT_CROP_BOUNDS targets returns size and position of the readable
> >>> +area of the pixel array matrix, including pixels with valid image data and pixel
> >>> +used for calibration purposes, such as optical black pixels. It is not unlikely

s/not unlikely/likely ? Or just "common".

> >>> +that valid pixels and optical black pixels are surrounded by non-readable rows
> >>> +and columns of pixels. Those does not concur in the definition of the

s/does/do/

I'm not sure "concur" is the right word. Did you mean "those are not
part of the V4L2_SEL_TGT_CROP_BOUNDS rectangle" ?

> >>> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. The rectangle returned by
> >>> +V4L2_SEL_TGT_CROP_BOUNDS describes an immutable property of the image sensor, it
> >>> +does not change at run-time and cannot be modified from userspace.
> >>
> >> Mention that BOUNDS is enclosed by NATIVE_SIZE.
> > 
> > I tried to express that in the intro section with
> > 
> > "Each pixel matrix portion is contained in a larger rectangle, with the most
> > largest being the one that describes the pixel matrix physical size."
> > 
> > But I guess it's worth to express that for each target!
> > 
> >>> +
> >>> +Pixel array active area
> >>> +^^^^^^^^^^^^^^^^^^^^^^^
> >>> +
> >>> +The portion of the pixel array which contains valid image data is defined as the
> >>> +active area of the pixel matrix. The active pixel array is is accessed by mean
> >>

s/is is/is/

> >> mean -> means
> >>
> >>> +of the V4L2_SEL_TGT_CROP_DEFAULT target, and is contained in the larger
> >>> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. It represents the largest possible frame
> >>> +resolution the sensor can produce and defines the dimension of the full
> >>> +field-of-view. The rectangle returned by V4L2_SEL_TGT_CROP_BOUNDS describes an
> >>
> >> BOUNDS -> DEFAULT
> > 
> > ups
> > 
> >>> +immutable property of the image sensor, it does not change at run-time and
> >>> +cannot be modified from userspace.
> >>
> >> Mention that CROP_DEFAULT is enclosed by CROP_BOUNDS
> >>
> >>> +
> >>> +Analog crop rectangle
> >>
> >> Why analog? It's just the crop rectangle, nothing analog about it.
> > 
> > We used the 'analogCrop' term in libcamera to differentiate the
> > cropping which happens on the sensor pixel array matrix to select the
> > region to process and produce image from. Sensor with an on-board
> > scaler can perform other cropping steps to implement, in example digital
> > zoom, so we expect to have a 'digital crop' phase as well. RAW
> > sensors, in example, will only have an analogCrop rectangle.
> > 
> > Quoting the libcamera definition of analog crop:
> > 
> >  * horizontal and vertical sizes define the portion of the pixel array which
> >  * is read-out and provided to the sensor's internal processing pipeline, before
> >  * any pixel sub-sampling method, such as pixel binning, skipping and averaging
> >  * take place.
> > 
> > should I keep it or remove it ?
> 
> It's a very confusing term. Especially since this API can also be used with analog
> video capture devices (Composite/S-Video) where the video signal actually is analog.
> 
> In the V4L2 API there is no such thing as 'analog crop', so please remove it.

Jacopo is right, sensors usually perform cropping in the analog domain
(by not reading out all pixels from the pixel array), and also support
cropping in later stages, after binning/skipping, and after further
scaling. Note that all of these crop operations are optional. Although
not common, it's also not unconceivable that a sensor wouldn't support
cropping at all.

This being said, it only makes sense to talk about analog crop when
multiple crop operations are performed, and thus in the context of the
whole sensor, with multiple subdevs. If we explain this, as proposed
above, and make it clear that the usage of the selection rectangles
defined here applies to the pixel array only, we can drop the "analog"
term, and just talk about cropping in the pixel array.

> >>> +^^^^^^^^^^^^^^^^^^^^^
> >>> +
> >>> +The sensor driver might decide, in order to adjust the image resolution to best
> >>> +match the one requested by applications, to only process a part of the active
> >>> +pixel array matrix.

I don't think that's the right approach. With MC-based devices, the
philosophy is to expose all configuration parameters to userspace. It's
not about sensor drivers making decisions, but about userspace deciding
to crop at the pixel array level.

This being said, I'm aware the decision is made by drivers when they're
mode-based. Please see below for that.

> >>> The selected area is read-out and processed by the image
> >>> +sensor on-board ISP in order to produce images of the desired size and
> >>> +resolution while possible maintaing the largest possible field-of-view. The
> >>
> >> maintaing -> maintaining
> >>
> >> Actually, I'd drop 'while possible maintaing the largest possible field-of-view'
> >> entirely. It doesn't make much sense.
> > 
> > Ack

In general, in this section, as we're documenting the pixel array, let's
not talk about the ISP.

> >>> +cropped portion of the pixel array which is used to produce images is returned
> >>> +by the V4L2_SEL_TGT_CROP target and represent the only information that can
> >>
> >> represent -> represents
> >>
> >>> +change at runtime as it depends on the currently configured sensor mode and
> >>> +desired image resolution. If the sub-device driver supports that, userspace
> >>> +can set the analog crop rectangle to select which portion of the pixel array
> >>
> >> s/analog//
> >>
> >>> +to read out.

I think it's better to focus on the best case, and document usage of
crop rectangles in general first, for drivers that expose full
configurability of the sensor. A separate section should then then make
a note of how mode-based drivers differ, which is mostly in the
V4L2_SEL_TGT_CROP target being read-only, and on the single subdev
hiding all the processing steps, with the crop target thus being the
result of all cropping operations, analog and digital.

Sakari's patch has a bit of information about this, it may be useful to
reuse it or integrate with it somehow.

> >> Mention that CROP is enclosed by CROP_BOUNDS and defaults to CROP_DEFAULT.
> >>
> >> Make a note that CROP can also be used to obtain optical black pixels.
> > 
> > What about:
> > 
> > +desired image resolution. If the sub-device driver supports that, userspace
> > +can set the analog crop rectangle to select which portion of the pixel array
> > +to read out including, if supported, optical black pixels.
> 
> Hmm, that's a bit awkward. How about:
> 
> +desired image resolution. If supported by the sub-device driver, userspace
> +can set the crop rectangle to select which portion of the pixel array
> +to read out. This may include optical black pixels if those are part of
> +V4L2_SEL_TGT_CROP_BOUNDS.
>
> >>> +
> >>>
> >>>  Types of selection targets
> >>>  --------------------------

Hi Jacopo,

Thank you for the patch.

On Wed, Aug 05, 2020 at 12:57:18PM +0200, Jacopo Mondi wrote:
> The V4L2 selection API are also used to access the pixel array
> properties of an image sensor, such as the size and position of active
> pixels and the cropped area of the pixel matrix used to produce images.
> 
> Currently no clear definition of the different areas that compose an
> image sensor pixel array matrix is provided in the specification, and
> the actual meaning of each selection target when applied to an image
> sensor was not provided.
> 
> Provide in the sub-device documentation the definition of the pixel
> matrix properties and the selection target associated to each of them.
> 
> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> ---
>  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
>  1 file changed, 81 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> index 134d2fb909fa4..c47861dff9b9b 100644
> --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
>  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
>  the image size either up or down. :ref:`v4l2-selection-flags`
>  
> +.. _v4l2-subdev-pixel-array-properties:
> +
> +Selection targets for image sensors properties
> +----------------------------------------------
> +
> +The V4L2 selection API can be used on sub-devices that represent an image
> +sensor to retrieve the sensor's pixel array matrix properties by using the
> +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> +
> +Sub-device drivers for image sensor usually register a single source pad, but in
> +the case they expose more, the pixel array properties can be accessed from
> +any of them.
> +
> +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> +the immutable properties of the several different areas that compose the sensor
> +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> +units. The logical disposition of pixels is defined by the sensor read-out
> +starting point and direction, and may differ from the physical disposition of
> +the pixel units in the pixel array matrix.
> +
> +Each pixel matrix portion is contained in a larger rectangle, with the most
> +largest being the one that describes the pixel matrix physical size. This
> +defines a hierarchical positional system, where each rectangle is defined
> +relatively to the largest available one among the ones exposed by the
> +sub-device driver. Each selection target and the associated pixel array portion
> +it represents are below presented in order from the largest to the smallest one.
> +
> +Pixel array physical size
> +^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The image sensor chip is composed by a number of physical pixels, not all of
> +them readable by the application processor. Invalid or unreadable lines might
> +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> +they might be tagged with an invalid data type (DT) so that the receiver
> +automatically discard them. The size of the whole pixel matrix area is
> +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> +defined as position (0, 0). All the other selection targets are defined
> +relatively to this, larger, rectangle. The rectangle returned by
> +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> +does not change at run-time and cannot be modified from userspace.

As I think I've mentioned previously (not sure if it was by e-mail or on
IRC), we could also decide to set V4L2_SEL_TGT_NATIVE_SIZE ==
V4L2_SEL_TGT_CROP_BOUNDS by ignoring the non-readable pixels completely.
What's the advantage of exposing them in the API, when the sensors
doesn't provide them to the rest of the pipeline ?

> +Pixel array readable area
> +^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The V4L2_SEL_TGT_CROP_BOUNDS targets returns size and position of the readable
> +area of the pixel array matrix, including pixels with valid image data and pixel
> +used for calibration purposes, such as optical black pixels. It is not unlikely
> +that valid pixels and optical black pixels are surrounded by non-readable rows
> +and columns of pixels. Those does not concur in the definition of the
> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. The rectangle returned by
> +V4L2_SEL_TGT_CROP_BOUNDS describes an immutable property of the image sensor, it
> +does not change at run-time and cannot be modified from userspace.
> +
> +Pixel array active area
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The portion of the pixel array which contains valid image data is defined as the
> +active area of the pixel matrix. The active pixel array is is accessed by mean
> +of the V4L2_SEL_TGT_CROP_DEFAULT target, and is contained in the larger
> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. It represents the largest possible frame
> +resolution the sensor can produce and defines the dimension of the full
> +field-of-view. The rectangle returned by V4L2_SEL_TGT_CROP_BOUNDS describes an
> +immutable property of the image sensor, it does not change at run-time and
> +cannot be modified from userspace.
> +
> +Analog crop rectangle
> +^^^^^^^^^^^^^^^^^^^^^
> +
> +The sensor driver might decide, in order to adjust the image resolution to best
> +match the one requested by applications, to only process a part of the active
> +pixel array matrix. The selected area is read-out and processed by the image
> +sensor on-board ISP in order to produce images of the desired size and
> +resolution while possible maintaing the largest possible field-of-view. The
> +cropped portion of the pixel array which is used to produce images is returned
> +by the V4L2_SEL_TGT_CROP target and represent the only information that can
> +change at runtime as it depends on the currently configured sensor mode and
> +desired image resolution. If the sub-device driver supports that, userspace
> +can set the analog crop rectangle to select which portion of the pixel array
> +to read out.
> +
>  
>  Types of selection targets
>  --------------------------

Hi Sakari,
    thanks for feedback.

On Thu, Aug 06, 2020 at 01:24:47AM +0300, Sakari Ailus wrote:
> Hi Jacopo,
>
> Thanks for the patchset.
>
> This improves selection documentation quite a bit. Please see my comments
> below.
>

Thanks. Laurent just mentioned your effort on documenting sensor
driver drivers, I would be happy to somehow merge the two efforts.

> On Wed, Aug 05, 2020 at 12:57:18PM +0200, Jacopo Mondi wrote:
> > The V4L2 selection API are also used to access the pixel array
> > properties of an image sensor, such as the size and position of active
> > pixels and the cropped area of the pixel matrix used to produce images.
> >
> > Currently no clear definition of the different areas that compose an
> > image sensor pixel array matrix is provided in the specification, and
> > the actual meaning of each selection target when applied to an image
> > sensor was not provided.
> >
> > Provide in the sub-device documentation the definition of the pixel
> > matrix properties and the selection target associated to each of them.
> >
> > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > ---
> >  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> >  1 file changed, 81 insertions(+)
> >
> > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > index 134d2fb909fa4..c47861dff9b9b 100644
> > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> >  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> >  the image size either up or down. :ref:`v4l2-selection-flags`
> >
> > +.. _v4l2-subdev-pixel-array-properties:
> > +
> > +Selection targets for image sensors properties
> > +----------------------------------------------
> > +
> > +The V4L2 selection API can be used on sub-devices that represent an image
> > +sensor to retrieve the sensor's pixel array matrix properties by using the
> > +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > +
> > +Sub-device drivers for image sensor usually register a single source pad, but in
> > +the case they expose more, the pixel array properties can be accessed from
> > +any of them.
>
> Is this a hypothetical case or are there examples?
>
> Also note that camera sensor drivers may expose more than one sub-devices,
> only one of which represents the pixel array.
>

Yes, I just tried to mention that as a possible use case, but I admit
I might be a bit confused about that. I would, as suggested by
Laurent, drop this part and add it back when we'll have a case at
hands.

> > +
> > +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> > +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > +the immutable properties of the several different areas that compose the sensor
> > +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> > +units. The logical disposition of pixels is defined by the sensor read-out
> > +starting point and direction, and may differ from the physical disposition of
> > +the pixel units in the pixel array matrix.
> > +
> > +Each pixel matrix portion is contained in a larger rectangle, with the most
>
> s/larger\K/ or equal/
>
> s/most//
>
> > +largest being the one that describes the pixel matrix physical size. This
> > +defines a hierarchical positional system, where each rectangle is defined
>
> s/,//
>

Ack on both sections.

> > +relatively to the largest available one among the ones exposed by the
> > +sub-device driver. Each selection target and the associated pixel array portion
> > +it represents are below presented in order from the largest to the smallest one.
> > +
> > +Pixel array physical size
> > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The image sensor chip is composed by a number of physical pixels, not all of
> > +them readable by the application processor. Invalid or unreadable lines might
> > +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > +they might be tagged with an invalid data type (DT) so that the receiver
> > +automatically discard them. The size of the whole pixel matrix area is
> > +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > +defined as position (0, 0). All the other selection targets are defined
> > +relatively to this, larger, rectangle. The rectangle returned by
> > +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > +does not change at run-time and cannot be modified from userspace.
> > +
> > +Pixel array readable area
> > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The V4L2_SEL_TGT_CROP_BOUNDS targets returns size and position of the readable
> > +area of the pixel array matrix, including pixels with valid image data and pixel
> > +used for calibration purposes, such as optical black pixels. It is not unlikely
> > +that valid pixels and optical black pixels are surrounded by non-readable rows
> > +and columns of pixels. Those does not concur in the definition of the
>
> How about: "Only pixels that can be read out are included in the
> V4L2_SEL_TGT_CROP_BOUNDS rectangle."?
>

I'll more extensively reply on this to laurent's comment on the "Pixel
array physical size" section, as it also address this comment you have
here. There's a SMIA++ question for you there :)

> > +V4L2_SEL_TGT_CROP_BOUNDS rectangle. The rectangle returned by
> > +V4L2_SEL_TGT_CROP_BOUNDS describes an immutable property of the image sensor, it
> > +does not change at run-time and cannot be modified from userspace.
> > +
> > +Pixel array active area
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The portion of the pixel array which contains valid image data is defined as the
> > +active area of the pixel matrix. The active pixel array is is accessed by mean
>
> s/accessed/described/
>
> Another word than "active" here would be great as we already have active
> and try contexts for selections.
>

I feel like we would need to define a stricter gloassary as well.
To replace active I would usually say "Valid for image capture",
"pixel that contain valid image data". But they're both longer

> > +of the V4L2_SEL_TGT_CROP_DEFAULT target, and is contained in the larger
>
> s/the larger//
>
> > +V4L2_SEL_TGT_CROP_BOUNDS rectangle. It represents the largest possible frame
> > +resolution the sensor can produce and defines the dimension of the full
>
> s/resolution/size/
>
> > +field-of-view. The rectangle returned by V4L2_SEL_TGT_CROP_BOUNDS describes an
>
> s/-/ /g
>
> > +immutable property of the image sensor, it does not change at run-time and
> > +cannot be modified from userspace.
> > +
> > +Analog crop rectangle
> > +^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The sensor driver might decide, in order to adjust the image resolution to best
> > +match the one requested by applications, to only process a part of the active
>
> s/, to\K/ instruct the hardware to/
>
> > +pixel array matrix. The selected area is read-out and processed by the image
> > +sensor on-board ISP in order to produce images of the desired size and
> > +resolution while possible maintaing the largest possible field-of-view. The
>
> s/size\K[^.]?*\./m
>
> > +cropped portion of the pixel array which is used to produce images is returned
>
> s/produce/read out/
> s/returned/configured/
>
> > +by the V4L2_SEL_TGT_CROP target and represent the only information that can
>
> s/by/using/
>
> I'd leave out the rest of the sentence after "target" above.

I added this as I initially listed CROP in the immutable targets, and
I was trying to specify it's actually not here. I'll remove the first
ambiguity then I could drop this patch.

>
> > +change at runtime as it depends on the currently configured sensor mode and
> > +desired image resolution. If the sub-device driver supports that, userspace
> > +can set the analog crop rectangle to select which portion of the pixel array
> > +to read out.
>
> How about instead:
>
> Register list based drivers generally do not allow setting analogue crop
> rectangles.
>

I could do that. I'm always a bit uncertain on mentioning 'register
list drivers', 'mode-based drivers' etc as we don't have a real
definition of them in the documentation..

Thanks
  j


> > +
> >
> >  Types of selection targets
> >  --------------------------
>
> --
> Kind regards,
>
> Sakari Ailus

Hi Sakari, Laurent
    tanks for comments.


On Sun, Aug 09, 2020 at 08:17:57PM +0300, Laurent Pinchart wrote:
> Hi Jacopo, Hans,
>
> On Thu, Aug 06, 2020 at 11:58:31AM +0200, Hans Verkuil wrote:
> > On 06/08/2020 11:50, Jacopo Mondi wrote:
> > > On Thu, Aug 06, 2020 at 10:05:37AM +0200, Hans Verkuil wrote:
> > >> On 05/08/2020 12:57, Jacopo Mondi wrote:
> > >>> The V4L2 selection API are also used to access the pixel array
> > >>
> > >> are -> is
> > >>
> > >>> properties of an image sensor, such as the size and position of active
> > >>> pixels and the cropped area of the pixel matrix used to produce images.
> > >>>
> > >>> Currently no clear definition of the different areas that compose an
> > >>> image sensor pixel array matrix is provided in the specification, and
> > >>> the actual meaning of each selection target when applied to an image
> > >>> sensor was not provided.
> > >>>
> > >>> Provide in the sub-device documentation the definition of the pixel
> > >>> matrix properties and the selection target associated to each of them.
> > >>>
> > >>> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > >>> ---
> > >>>  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> > >>>  1 file changed, 81 insertions(+)
> > >>>
> > >>> diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > >>> index 134d2fb909fa4..c47861dff9b9b 100644
> > >>> --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > >>> +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > >>> @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> > >>>  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> > >>>  the image size either up or down. :ref:`v4l2-selection-flags`
> > >>>
> > >>> +.. _v4l2-subdev-pixel-array-properties:
> > >>> +
> > >>> +Selection targets for image sensors properties
>
> Maybe "Selection targets for image sensors", and renaming the reference
> to v4l2-subdev-selections-image-sensors ? This section is about how
> selection rectangles are used for sensors, right ?
>
> > >>> +----------------------------------------------
>
> I'd move this further down, after "Types of selection targets", as that
> section contains generic information that applies to sensors too.

Ack on both points.

>
> > >>> +
> > >>> +The V4L2 selection API can be used on sub-devices that represent an image
> > >>> +sensor to retrieve the sensor's pixel array matrix properties by using the
> > >>> +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > >>> +
> > >>> +Sub-device drivers for image sensor usually register a single source pad, but in
> > >>> +the case they expose more, the pixel array properties can be accessed from
> > >>> +any of them.
>
> Is this right ? I don't think the V4L2_SEL_TGT_CROP rectangle, for
> instance, can be accessed from any source pad indifferently. Do we have
> sensor drivers that create multiple source pads in a subdev today ? If
> not I'd suggest dropping this, and adding it later if needed (when we'll
> have a better idea of how that would work).

Yes, this was meant to cover cases which I still have not a clear idea
about but I suspect people might have question about looking at their
drivers. I'm totally fine adding it later when required.

>
> I think what should be explained here, as also mentioned by Sakari, is
> that camera sensors can be exposed as multiple subdevs. The text below
> is related to the pixel array, which is always the first subdev, with
> one source pad and no sink pad. The other subdevs, modelling additional
> processing blocks in the sensor, may use the selection API, but that's
> out of scope for this patch.
>
> As we'll also need to document how other subdevs use the selection API,
> as well as how sensors are usually handled, would it make sense to move
> this to a separate file ? Sakari has proposed in [1] to create a new
> Documentation/driver-api/media/camera-sensor.rst file. It would make
> sense to centralize all sensor information there. This doesn't mean this
> series should depend on Sakari's patch, we can handle merge conflicts
> depending on what gets merged first.

I totally missed that one but I equally totally welcome that change. I
would be happy to rebase this work on top of Sakari's patch which I
will soon give a read to.

>
> [1] https://lore.kernel.org/linux-media/20200730162040.15560-1-sakari.ailus@linux.intel.com/
>
> > >>> +
> > >>> +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> > >>
> > >> V4L2_SEL_TGT_NATIVE -> V4L2_SEL_TGT_NATIVE_SIZE
> > >>
> > >> (same mistake is made elsewhere).
> > >
> > > Ah ups, I used TGT_NATIVE consistently, seems like I thought that was
> > > the right name
> > >
> > >>> +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > >>> +the immutable properties of the several different areas that compose the sensor
> > >>> +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
>
> V4L2_TGT_CROP isn't immutable, is it ?
>

Right, I noticed that, but didn't want to be too heavy with createing
a special section for CROP. But you're right, it's not immutable so it
should not be mentioned here.

> > >>> +units. The logical disposition of pixels is defined by the sensor read-out
> > >>> +starting point and direction, and may differ from the physical disposition of
> > >>> +the pixel units in the pixel array matrix.
> > >>> +
> > >>> +Each pixel matrix portion is contained in a larger rectangle, with the most
> > >>> +largest being the one that describes the pixel matrix physical size. This
> > >>> +defines a hierarchical positional system, where each rectangle is defined
> > >>> +relatively to the largest available one among the ones exposed by the
> > >>> +sub-device driver. Each selection target and the associated pixel array portion
> > >>> +it represents are below presented in order from the largest to the smallest one.
>
> I find this quite confusing. As Hans suggested, I think each target
> should define its boundaries. I'd drop this paragraph completely, as you
> already explain below that all rectangles are defined relatively to
> V4L2_SEL_TGT_NATIVE_SIZE.
>

Ack.

> > >>> +
> > >>> +Pixel array physical size
> > >>> +^^^^^^^^^^^^^^^^^^^^^^^^^
> > >>> +
> > >>> +The image sensor chip is composed by a number of physical pixels, not all of
> > >>> +them readable by the application processor. Invalid or unreadable lines might
> > >>> +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > >>> +they might be tagged with an invalid data type (DT) so that the receiver
> > >>> +automatically discard them.
>
> "might" is a bit weak for unreadable lines, there's no way they can be
> transmitted if they can't be read :-)

This paragraph reflects my confusion on the subject. My interpretation
is that for CSI-2 sensors, you cannot crop a black pixels area and
capture just them. At the contrary, the black pixels are sent on the
bus (maybe that can be optionally enabled/disabled) tagged with a
special DT and interleaved with image data and you have to instruct
your receiver to discard or accept that DT, and have black pixels
captured to a separate memory area, or at buffer end (that depends on
the receiver's architecture I guess). At the same time, I won't be
surprised if some sensor's allow you to explicitly crop on black
pixels areas and only put them on the bus. Knowing how the SMIA++
standard handles that part might help establishing an expected
behaviour (I really, really, wish we had as a community any leverage
to influence sensor manufacturer towards a standardized behaviour, it
would be time for the industry to do so. </wishful thinking>).

If that's correct, I wonder how would that possibly work with parallel
sensors, where you cannot tag data on the bus. I there assume you have
to explicitly select the black region to capture.

I there tried to, confusingly, express that different behaviour and
stay as much as possible generic not to rule out any existing case.

>
> One way to generalize this a bit would be to explain, after the first
> sentence, that not all pixels may be read by the sensor, that among the
> pixels that are read invalid ones may not be transmitted on the bus, and
> that among transmitted pixels not all of them may be possible to capture
> on the receiver side. For instance, invalid lines may be transmitted as
> part of the vertical blanking on parallel buses, or tagged as blanking
> data or null data on CSI-2 buses. Most receivers are not able to capture
> either.
>
> (On a side note, strictly speaking, a CSI-2 receiver that would be able
> to capture null or blanking packets wouldn't be compliant with the CSI-2
> spec.)
>
> > >>> The size of the whole pixel matrix area is
> > >>> +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > >>> +defined as position (0, 0). All the other selection targets are defined
> > >>> +relatively to this, larger, rectangle. The rectangle returned by
>
> s/, larger,/
>
> > >>> +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > >>> +does not change at run-time and cannot be modified from userspace.
> > >>
> > >> It is a good idea to mention that if there are no invalid or unreadable pixels/lines,
> > >> then V4L2_SEL_TGT_NATIVE_SIZE == V4L2_SEL_TGT_CROP_BOUNDS.
> > >
> > > Yes it is! I'll add it here
>
> Should it be added below instead, where you define
> V4L2_SEL_TGT_CROP_BOUNDS ? It's best to avoid mentioning something that
> isn't defined yet when possible.
>

I have a question for Sakari on this target, but I'll deflect it to
the reply to your comment  on patch 1/4.

> > >>> +
> > >>> +Pixel array readable area
> > >>> +^^^^^^^^^^^^^^^^^^^^^^^^^
> > >>> +
> > >>> +The V4L2_SEL_TGT_CROP_BOUNDS targets returns size and position of the readable
> > >>> +area of the pixel array matrix, including pixels with valid image data and pixel
> > >>> +used for calibration purposes, such as optical black pixels. It is not unlikely
>
> s/not unlikely/likely ? Or just "common".
>
> > >>> +that valid pixels and optical black pixels are surrounded by non-readable rows
> > >>> +and columns of pixels. Those does not concur in the definition of the
>
> s/does/do/
>
> I'm not sure "concur" is the right word. Did you mean "those are not
> part of the V4L2_SEL_TGT_CROP_BOUNDS rectangle" ?

Yes, I meant they should not be counted in the definition of the BOUND
rectangle sizes.

>
> > >>> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. The rectangle returned by
> > >>> +V4L2_SEL_TGT_CROP_BOUNDS describes an immutable property of the image sensor, it
> > >>> +does not change at run-time and cannot be modified from userspace.
> > >>
> > >> Mention that BOUNDS is enclosed by NATIVE_SIZE.
> > >
> > > I tried to express that in the intro section with
> > >
> > > "Each pixel matrix portion is contained in a larger rectangle, with the most
> > > largest being the one that describes the pixel matrix physical size."
> > >
> > > But I guess it's worth to express that for each target!
> > >
> > >>> +
> > >>> +Pixel array active area
> > >>> +^^^^^^^^^^^^^^^^^^^^^^^
> > >>> +
> > >>> +The portion of the pixel array which contains valid image data is defined as the
> > >>> +active area of the pixel matrix. The active pixel array is is accessed by mean
> > >>
>
> s/is is/is/
>
> > >> mean -> means
> > >>
> > >>> +of the V4L2_SEL_TGT_CROP_DEFAULT target, and is contained in the larger
> > >>> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. It represents the largest possible frame
> > >>> +resolution the sensor can produce and defines the dimension of the full
> > >>> +field-of-view. The rectangle returned by V4L2_SEL_TGT_CROP_BOUNDS describes an
> > >>
> > >> BOUNDS -> DEFAULT
> > >
> > > ups
> > >
> > >>> +immutable property of the image sensor, it does not change at run-time and
> > >>> +cannot be modified from userspace.
> > >>
> > >> Mention that CROP_DEFAULT is enclosed by CROP_BOUNDS
> > >>
> > >>> +
> > >>> +Analog crop rectangle
> > >>
> > >> Why analog? It's just the crop rectangle, nothing analog about it.
> > >
> > > We used the 'analogCrop' term in libcamera to differentiate the
> > > cropping which happens on the sensor pixel array matrix to select the
> > > region to process and produce image from. Sensor with an on-board
> > > scaler can perform other cropping steps to implement, in example digital
> > > zoom, so we expect to have a 'digital crop' phase as well. RAW
> > > sensors, in example, will only have an analogCrop rectangle.
> > >
> > > Quoting the libcamera definition of analog crop:
> > >
> > >  * horizontal and vertical sizes define the portion of the pixel array which
> > >  * is read-out and provided to the sensor's internal processing pipeline, before
> > >  * any pixel sub-sampling method, such as pixel binning, skipping and averaging
> > >  * take place.
> > >
> > > should I keep it or remove it ?
> >
> > It's a very confusing term. Especially since this API can also be used with analog
> > video capture devices (Composite/S-Video) where the video signal actually is analog.
> >
> > In the V4L2 API there is no such thing as 'analog crop', so please remove it.
>
> Jacopo is right, sensors usually perform cropping in the analog domain
> (by not reading out all pixels from the pixel array), and also support
> cropping in later stages, after binning/skipping, and after further
> scaling. Note that all of these crop operations are optional. Although
> not common, it's also not unconceivable that a sensor wouldn't support
> cropping at all.
>
> This being said, it only makes sense to talk about analog crop when
> multiple crop operations are performed, and thus in the context of the
> whole sensor, with multiple subdevs. If we explain this, as proposed
> above, and make it clear that the usage of the selection rectangles
> defined here applies to the pixel array only, we can drop the "analog"
> term, and just talk about cropping in the pixel array.
>

It's fine as long as it removes any ambiguity.

> > >>> +^^^^^^^^^^^^^^^^^^^^^
> > >>> +
> > >>> +The sensor driver might decide, in order to adjust the image resolution to best
> > >>> +match the one requested by applications, to only process a part of the active
> > >>> +pixel array matrix.
>
> I don't think that's the right approach. With MC-based devices, the
> philosophy is to expose all configuration parameters to userspace. It's
> not about sensor drivers making decisions, but about userspace deciding
> to crop at the pixel array level.
>
> This being said, I'm aware the decision is made by drivers when they're
> mode-based. Please see below for that.

Correct, and I should now be used enough to the 'userspace drives'
approach to remember about documenting it :)

>
> > >>> The selected area is read-out and processed by the image
> > >>> +sensor on-board ISP in order to produce images of the desired size and
> > >>> +resolution while possible maintaing the largest possible field-of-view. The
> > >>
> > >> maintaing -> maintaining
> > >>
> > >> Actually, I'd drop 'while possible maintaing the largest possible field-of-view'
> > >> entirely. It doesn't make much sense.
> > >
> > > Ack
>
> In general, in this section, as we're documenting the pixel array, let's
> not talk about the ISP.
>
> > >>> +cropped portion of the pixel array which is used to produce images is returned
> > >>> +by the V4L2_SEL_TGT_CROP target and represent the only information that can
> > >>
> > >> represent -> represents
> > >>
> > >>> +change at runtime as it depends on the currently configured sensor mode and
> > >>> +desired image resolution. If the sub-device driver supports that, userspace
> > >>> +can set the analog crop rectangle to select which portion of the pixel array
> > >>
> > >> s/analog//
> > >>
> > >>> +to read out.
>
> I think it's better to focus on the best case, and document usage of
> crop rectangles in general first, for drivers that expose full
> configurability of the sensor. A separate section should then then make
> a note of how mode-based drivers differ, which is mostly in the
> V4L2_SEL_TGT_CROP target being read-only, and on the single subdev
> hiding all the processing steps, with the crop target thus being the
> result of all cropping operations, analog and digital.
>
> Sakari's patch has a bit of information about this, it may be useful to
> reuse it or integrate with it somehow.
>

I'll try to see how the two parts can be piled one on top of the
other.

Thanks
  j


> > >> Mention that CROP is enclosed by CROP_BOUNDS and defaults to CROP_DEFAULT.
> > >>
> > >> Make a note that CROP can also be used to obtain optical black pixels.
> > >
> > > What about:
> > >
> > > +desired image resolution. If the sub-device driver supports that, userspace
> > > +can set the analog crop rectangle to select which portion of the pixel array
> > > +to read out including, if supported, optical black pixels.
> >
> > Hmm, that's a bit awkward. How about:
> >
> > +desired image resolution. If supported by the sub-device driver, userspace
> > +can set the crop rectangle to select which portion of the pixel array
> > +to read out. This may include optical black pixels if those are part of
> > +V4L2_SEL_TGT_CROP_BOUNDS.
> >
> > >>> +
> > >>>
> > >>>  Types of selection targets
> > >>>  --------------------------
>
> --
> Regards,
>
> Laurent Pinchart

On Sun, Aug 09, 2020 at 08:58:21PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Wed, Aug 05, 2020 at 12:57:18PM +0200, Jacopo Mondi wrote:
> > The V4L2 selection API are also used to access the pixel array
> > properties of an image sensor, such as the size and position of active
> > pixels and the cropped area of the pixel matrix used to produce images.
> >
> > Currently no clear definition of the different areas that compose an
> > image sensor pixel array matrix is provided in the specification, and
> > the actual meaning of each selection target when applied to an image
> > sensor was not provided.
> >
> > Provide in the sub-device documentation the definition of the pixel
> > matrix properties and the selection target associated to each of them.
> >
> > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > ---
> >  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> >  1 file changed, 81 insertions(+)
> >
> > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > index 134d2fb909fa4..c47861dff9b9b 100644
> > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> >  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> >  the image size either up or down. :ref:`v4l2-selection-flags`
> >
> > +.. _v4l2-subdev-pixel-array-properties:
> > +
> > +Selection targets for image sensors properties
> > +----------------------------------------------
> > +
> > +The V4L2 selection API can be used on sub-devices that represent an image
> > +sensor to retrieve the sensor's pixel array matrix properties by using the
> > +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > +
> > +Sub-device drivers for image sensor usually register a single source pad, but in
> > +the case they expose more, the pixel array properties can be accessed from
> > +any of them.
> > +
> > +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> > +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > +the immutable properties of the several different areas that compose the sensor
> > +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> > +units. The logical disposition of pixels is defined by the sensor read-out
> > +starting point and direction, and may differ from the physical disposition of
> > +the pixel units in the pixel array matrix.
> > +
> > +Each pixel matrix portion is contained in a larger rectangle, with the most
> > +largest being the one that describes the pixel matrix physical size. This
> > +defines a hierarchical positional system, where each rectangle is defined
> > +relatively to the largest available one among the ones exposed by the
> > +sub-device driver. Each selection target and the associated pixel array portion
> > +it represents are below presented in order from the largest to the smallest one.
> > +
> > +Pixel array physical size
> > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The image sensor chip is composed by a number of physical pixels, not all of
> > +them readable by the application processor. Invalid or unreadable lines might
> > +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > +they might be tagged with an invalid data type (DT) so that the receiver
> > +automatically discard them. The size of the whole pixel matrix area is
> > +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > +defined as position (0, 0). All the other selection targets are defined
> > +relatively to this, larger, rectangle. The rectangle returned by
> > +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > +does not change at run-time and cannot be modified from userspace.
>
> As I think I've mentioned previously (not sure if it was by e-mail or on
> IRC), we could also decide to set V4L2_SEL_TGT_NATIVE_SIZE ==
> V4L2_SEL_TGT_CROP_BOUNDS by ignoring the non-readable pixels completely.
> What's the advantage of exposing them in the API, when the sensors
> doesn't provide them to the rest of the pipeline ?
>

I don't know :) I'm also  bit confused on what's the purpose of
NATIVE, this commit seems to suggest it was meant to replace
CROP_BOUNDS, but I'm not sure about that.

commit b518d86609cc066b626120fe6ec6fe3a4ccfcd54
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Nov 6 16:54:33 2014 -0300

    [media] smiapp: Support V4L2_SEL_TGT_NATIVE_SIZE

    Add support for selection target V4L2_SEL_TGT_NATIVE_SIZE. It is equivalent
    of what V4L2_SEL_TGT_CROP_BOUNDS used to be. Support for
    V4L2_SEL_TGT_CROP_BOUNDS is still supported by the driver as a compatibility
    interface.

Sakari, do you recall if that's was the original plan ?

Thanks
  j

> > +Pixel array readable area
> > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The V4L2_SEL_TGT_CROP_BOUNDS targets returns size and position of the readable
> > +area of the pixel array matrix, including pixels with valid image data and pixel
> > +used for calibration purposes, such as optical black pixels. It is not unlikely
> > +that valid pixels and optical black pixels are surrounded by non-readable rows
> > +and columns of pixels. Those does not concur in the definition of the
> > +V4L2_SEL_TGT_CROP_BOUNDS rectangle. The rectangle returned by
> > +V4L2_SEL_TGT_CROP_BOUNDS describes an immutable property of the image sensor, it
> > +does not change at run-time and cannot be modified from userspace.
> > +
> > +Pixel array active area
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The portion of the pixel array which contains valid image data is defined as the
> > +active area of the pixel matrix. The active pixel array is is accessed by mean
> > +of the V4L2_SEL_TGT_CROP_DEFAULT target, and is contained in the larger
> > +V4L2_SEL_TGT_CROP_BOUNDS rectangle. It represents the largest possible frame
> > +resolution the sensor can produce and defines the dimension of the full
> > +field-of-view. The rectangle returned by V4L2_SEL_TGT_CROP_BOUNDS describes an
> > +immutable property of the image sensor, it does not change at run-time and
> > +cannot be modified from userspace.
> > +
> > +Analog crop rectangle
> > +^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The sensor driver might decide, in order to adjust the image resolution to best
> > +match the one requested by applications, to only process a part of the active
> > +pixel array matrix. The selected area is read-out and processed by the image
> > +sensor on-board ISP in order to produce images of the desired size and
> > +resolution while possible maintaing the largest possible field-of-view. The
> > +cropped portion of the pixel array which is used to produce images is returned
> > +by the V4L2_SEL_TGT_CROP target and represent the only information that can
> > +change at runtime as it depends on the currently configured sensor mode and
> > +desired image resolution. If the sub-device driver supports that, userspace
> > +can set the analog crop rectangle to select which portion of the pixel array
> > +to read out.
> > +
> >
> >  Types of selection targets
> >  --------------------------
>
> --
> Regards,
>
> Laurent Pinchart

On Thu, Aug 06, 2020 at 03:22:34PM +0200, Hans Verkuil wrote:
> On 06/08/2020 14:54, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > On Thu, Aug 06, 2020 at 11:58:31AM +0200, Hans Verkuil wrote:
> >> On 06/08/2020 11:50, Jacopo Mondi wrote:
> >>> Hi Hans,
> >>>
> >>> On Thu, Aug 06, 2020 at 10:05:37AM +0200, Hans Verkuil wrote:
> >>>> Hi Jacopo,
> >>>>
> >>>> Some review comments below:
> >>>>
> >>>> On 05/08/2020 12:57, Jacopo Mondi wrote:
> >>>>> +Analog crop rectangle
> >>>>
> >>>> Why analog? It's just the crop rectangle, nothing analog about it.
> >>>>
> >>>
> >>> We used the 'analogCrop' term in libcamera to differentiate the
> >>> cropping which happens on the sensor pixel array matrix to select the
> >>> region to process and produce image from. Sensor with an on-board
> >>> scaler can perform other cropping steps to implement, in example digital
> >>> zoom, so we expect to have a 'digital crop' phase as well. RAW
> >>> sensors, in example, will only have an analogCrop rectangle.
> >>>
> >>> Quoting the libcamera definition of analog crop:
> >>>
> >>>  * horizontal and vertical sizes define the portion of the pixel array which
> >>>  * is read-out and provided to the sensor's internal processing pipeline, before
> >>>  * any pixel sub-sampling method, such as pixel binning, skipping and averaging
> >>>  * take place.
> >>>
> >>> should I keep it or remove it ?
> >>
> >> It's a very confusing term. Especially since this API can also be used with analog
> >> video capture devices (Composite/S-Video) where the video signal actually is analog.
> >>
> >> In the V4L2 API there is no such thing as 'analog crop', so please remove it.
> > 
> > There isn't in the V4L2 API but I don't see why we couldn't document it
> > here. Analogue crop is an established term related to raw (perhaps others,
> > too?) camera sensors which describes cropping that is implemented by not
> > reading parts of the pixel array.
> > 
> > As this documentation only applies to camera sensors, I think it's entirely
> > appropriate to document this here, and using that term.
> > 
> 
> It's always been called just 'crop' in the V4L2 API, so renaming it suddenly
> to something else is IMHO confusing. What you can do, however, is that in the

This has been actually implemented a decade ago but it seems the
documentation has either never been there or has disappeared.

Most drivers hide this as they work on the frame interval and output size
alone, ignoring the rest. Despite that, generally camera sensors do have
both analogue and digital cropping capabilities with differing features
(granularity and dependency to frame interval).

> description of the "crop rectangle" you mention that "it is also known as
> "analog crop" in the context of camera sensors.

Just saying it's a crop rectangle isn't exactly wrong but it's incomplete.
The frame interval calculation requires that information so this should be
more than just a side note.

> 
> With perhaps some more extensive explanation of the term.

Hi Jacopo,

On Mon, Aug 10, 2020 at 10:17:57AM +0200, Jacopo Mondi wrote:
> On Sun, Aug 09, 2020 at 08:58:21PM +0300, Laurent Pinchart wrote:
> > Hi Jacopo,
> >
> > Thank you for the patch.
> >
> > On Wed, Aug 05, 2020 at 12:57:18PM +0200, Jacopo Mondi wrote:
> > > The V4L2 selection API are also used to access the pixel array
> > > properties of an image sensor, such as the size and position of active
> > > pixels and the cropped area of the pixel matrix used to produce images.
> > >
> > > Currently no clear definition of the different areas that compose an
> > > image sensor pixel array matrix is provided in the specification, and
> > > the actual meaning of each selection target when applied to an image
> > > sensor was not provided.
> > >
> > > Provide in the sub-device documentation the definition of the pixel
> > > matrix properties and the selection target associated to each of them.
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > > ---
> > >  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> > >  1 file changed, 81 insertions(+)
> > >
> > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > index 134d2fb909fa4..c47861dff9b9b 100644
> > > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> > >  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> > >  the image size either up or down. :ref:`v4l2-selection-flags`
> > >
> > > +.. _v4l2-subdev-pixel-array-properties:
> > > +
> > > +Selection targets for image sensors properties
> > > +----------------------------------------------
> > > +
> > > +The V4L2 selection API can be used on sub-devices that represent an image
> > > +sensor to retrieve the sensor's pixel array matrix properties by using the
> > > +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > > +
> > > +Sub-device drivers for image sensor usually register a single source pad, but in
> > > +the case they expose more, the pixel array properties can be accessed from
> > > +any of them.
> > > +
> > > +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> > > +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > > +the immutable properties of the several different areas that compose the sensor
> > > +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> > > +units. The logical disposition of pixels is defined by the sensor read-out
> > > +starting point and direction, and may differ from the physical disposition of
> > > +the pixel units in the pixel array matrix.
> > > +
> > > +Each pixel matrix portion is contained in a larger rectangle, with the most
> > > +largest being the one that describes the pixel matrix physical size. This
> > > +defines a hierarchical positional system, where each rectangle is defined
> > > +relatively to the largest available one among the ones exposed by the
> > > +sub-device driver. Each selection target and the associated pixel array portion
> > > +it represents are below presented in order from the largest to the smallest one.
> > > +
> > > +Pixel array physical size
> > > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > > +
> > > +The image sensor chip is composed by a number of physical pixels, not all of
> > > +them readable by the application processor. Invalid or unreadable lines might
> > > +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > > +they might be tagged with an invalid data type (DT) so that the receiver
> > > +automatically discard them. The size of the whole pixel matrix area is
> > > +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > > +defined as position (0, 0). All the other selection targets are defined
> > > +relatively to this, larger, rectangle. The rectangle returned by
> > > +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > > +does not change at run-time and cannot be modified from userspace.
> >
> > As I think I've mentioned previously (not sure if it was by e-mail or on
> > IRC), we could also decide to set V4L2_SEL_TGT_NATIVE_SIZE ==
> > V4L2_SEL_TGT_CROP_BOUNDS by ignoring the non-readable pixels completely.
> > What's the advantage of exposing them in the API, when the sensors
> > doesn't provide them to the rest of the pipeline ?
> >
> 
> I don't know :) I'm also  bit confused on what's the purpose of
> NATIVE, this commit seems to suggest it was meant to replace
> CROP_BOUNDS, but I'm not sure about that.
> 
> commit b518d86609cc066b626120fe6ec6fe3a4ccfcd54
> Author: Sakari Ailus <sakari.ailus@linux.intel.com>
> Date:   Thu Nov 6 16:54:33 2014 -0300
> 
>     [media] smiapp: Support V4L2_SEL_TGT_NATIVE_SIZE
> 
>     Add support for selection target V4L2_SEL_TGT_NATIVE_SIZE. It is equivalent
>     of what V4L2_SEL_TGT_CROP_BOUNDS used to be. Support for
>     V4L2_SEL_TGT_CROP_BOUNDS is still supported by the driver as a compatibility
>     interface.
> 
> Sakari, do you recall if that's was the original plan ?

That was to denote the size of the pixel array indeed. We didn't discuss
dark or invalid pixels at the time.

So this was just there to tell that it's the pixel array you're cropping
from.

But as long as it's API-wise compatible, I don't think anything prevents
re-purposing this to include other areas. The documentation (AFAIR) does
not say this has to be the same as the crop bounds rectangle.

Hi Sakari,

On Tue, Aug 18, 2020 at 11:17:43AM +0300, Sakari Ailus wrote:
> On Mon, Aug 10, 2020 at 10:17:57AM +0200, Jacopo Mondi wrote:
> > On Sun, Aug 09, 2020 at 08:58:21PM +0300, Laurent Pinchart wrote:
> > > On Wed, Aug 05, 2020 at 12:57:18PM +0200, Jacopo Mondi wrote:
> > > > The V4L2 selection API are also used to access the pixel array
> > > > properties of an image sensor, such as the size and position of active
> > > > pixels and the cropped area of the pixel matrix used to produce images.
> > > >
> > > > Currently no clear definition of the different areas that compose an
> > > > image sensor pixel array matrix is provided in the specification, and
> > > > the actual meaning of each selection target when applied to an image
> > > > sensor was not provided.
> > > >
> > > > Provide in the sub-device documentation the definition of the pixel
> > > > matrix properties and the selection target associated to each of them.
> > > >
> > > > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > > > ---
> > > >  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> > > >  1 file changed, 81 insertions(+)
> > > >
> > > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > index 134d2fb909fa4..c47861dff9b9b 100644
> > > > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> > > >  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> > > >  the image size either up or down. :ref:`v4l2-selection-flags`
> > > >
> > > > +.. _v4l2-subdev-pixel-array-properties:
> > > > +
> > > > +Selection targets for image sensors properties
> > > > +----------------------------------------------
> > > > +
> > > > +The V4L2 selection API can be used on sub-devices that represent an image
> > > > +sensor to retrieve the sensor's pixel array matrix properties by using the
> > > > +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > > > +
> > > > +Sub-device drivers for image sensor usually register a single source pad, but in
> > > > +the case they expose more, the pixel array properties can be accessed from
> > > > +any of them.
> > > > +
> > > > +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> > > > +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > > > +the immutable properties of the several different areas that compose the sensor
> > > > +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> > > > +units. The logical disposition of pixels is defined by the sensor read-out
> > > > +starting point and direction, and may differ from the physical disposition of
> > > > +the pixel units in the pixel array matrix.
> > > > +
> > > > +Each pixel matrix portion is contained in a larger rectangle, with the most
> > > > +largest being the one that describes the pixel matrix physical size. This
> > > > +defines a hierarchical positional system, where each rectangle is defined
> > > > +relatively to the largest available one among the ones exposed by the
> > > > +sub-device driver. Each selection target and the associated pixel array portion
> > > > +it represents are below presented in order from the largest to the smallest one.
> > > > +
> > > > +Pixel array physical size
> > > > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > +
> > > > +The image sensor chip is composed by a number of physical pixels, not all of
> > > > +them readable by the application processor. Invalid or unreadable lines might
> > > > +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > > > +they might be tagged with an invalid data type (DT) so that the receiver
> > > > +automatically discard them. The size of the whole pixel matrix area is
> > > > +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > > > +defined as position (0, 0). All the other selection targets are defined
> > > > +relatively to this, larger, rectangle. The rectangle returned by
> > > > +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > > > +does not change at run-time and cannot be modified from userspace.
> > >
> > > As I think I've mentioned previously (not sure if it was by e-mail or on
> > > IRC), we could also decide to set V4L2_SEL_TGT_NATIVE_SIZE ==
> > > V4L2_SEL_TGT_CROP_BOUNDS by ignoring the non-readable pixels completely.
> > > What's the advantage of exposing them in the API, when the sensors
> > > doesn't provide them to the rest of the pipeline ?
> > 
> > I don't know :) I'm also  bit confused on what's the purpose of
> > NATIVE, this commit seems to suggest it was meant to replace
> > CROP_BOUNDS, but I'm not sure about that.
> > 
> > commit b518d86609cc066b626120fe6ec6fe3a4ccfcd54
> > Author: Sakari Ailus <sakari.ailus@linux.intel.com>
> > Date:   Thu Nov 6 16:54:33 2014 -0300
> > 
> >     [media] smiapp: Support V4L2_SEL_TGT_NATIVE_SIZE
> > 
> >     Add support for selection target V4L2_SEL_TGT_NATIVE_SIZE. It is equivalent
> >     of what V4L2_SEL_TGT_CROP_BOUNDS used to be. Support for
> >     V4L2_SEL_TGT_CROP_BOUNDS is still supported by the driver as a compatibility
> >     interface.
> > 
> > Sakari, do you recall if that's was the original plan ?
> 
> That was to denote the size of the pixel array indeed. We didn't discuss
> dark or invalid pixels at the time.
> 
> So this was just there to tell that it's the pixel array you're cropping
> from.
> 
> But as long as it's API-wise compatible, I don't think anything prevents
> re-purposing this to include other areas. The documentation (AFAIR) does
> not say this has to be the same as the crop bounds rectangle.

What do you think would be best ? Should we include the non-readable
pixels in V4L2_SEL_TGT_NATIVE_SIZE, with V4L2_SEL_TGT_CROP_BOUNDS then
being strictly smaller, or drop them completely from the API, with
V4L2_SEL_TGT_CROP_BOUNDS being equal to V4L2_SEL_TGT_NATIVE_SIZE ? It
may be that we have to allow both to support existing drivers, but we
should pick one of the two options and make it mandatory for new
drivers.

Hi Jacopo,

On Mon, Aug 10, 2020 at 10:14:37AM +0200, Jacopo Mondi wrote:
> On Sun, Aug 09, 2020 at 08:17:57PM +0300, Laurent Pinchart wrote:
> > On Thu, Aug 06, 2020 at 11:58:31AM +0200, Hans Verkuil wrote:
> > > On 06/08/2020 11:50, Jacopo Mondi wrote:
> > > > On Thu, Aug 06, 2020 at 10:05:37AM +0200, Hans Verkuil wrote:
> > > >> On 05/08/2020 12:57, Jacopo Mondi wrote:
> > > >>> The V4L2 selection API are also used to access the pixel array
> > > >>
> > > >> are -> is
> > > >>
> > > >>> properties of an image sensor, such as the size and position of active
> > > >>> pixels and the cropped area of the pixel matrix used to produce images.
> > > >>>
> > > >>> Currently no clear definition of the different areas that compose an
> > > >>> image sensor pixel array matrix is provided in the specification, and
> > > >>> the actual meaning of each selection target when applied to an image
> > > >>> sensor was not provided.
> > > >>>
> > > >>> Provide in the sub-device documentation the definition of the pixel
> > > >>> matrix properties and the selection target associated to each of them.
> > > >>>
> > > >>> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > > >>> ---
> > > >>>  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> > > >>>  1 file changed, 81 insertions(+)
> > > >>>
> > > >>> diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > >>> index 134d2fb909fa4..c47861dff9b9b 100644
> > > >>> --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > >>> +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > >>> @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> > > >>>  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> > > >>>  the image size either up or down. :ref:`v4l2-selection-flags`
> > > >>>
> > > >>> +.. _v4l2-subdev-pixel-array-properties:
> > > >>> +
> > > >>> +Selection targets for image sensors properties
> >
> > Maybe "Selection targets for image sensors", and renaming the reference
> > to v4l2-subdev-selections-image-sensors ? This section is about how
> > selection rectangles are used for sensors, right ?
> >
> > > >>> +----------------------------------------------
> >
> > I'd move this further down, after "Types of selection targets", as that
> > section contains generic information that applies to sensors too.
> 
> Ack on both points.
> 
> > > >>> +
> > > >>> +The V4L2 selection API can be used on sub-devices that represent an image
> > > >>> +sensor to retrieve the sensor's pixel array matrix properties by using the
> > > >>> +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > > >>> +
> > > >>> +Sub-device drivers for image sensor usually register a single source pad, but in
> > > >>> +the case they expose more, the pixel array properties can be accessed from
> > > >>> +any of them.
> >
> > Is this right ? I don't think the V4L2_SEL_TGT_CROP rectangle, for
> > instance, can be accessed from any source pad indifferently. Do we have
> > sensor drivers that create multiple source pads in a subdev today ? If
> > not I'd suggest dropping this, and adding it later if needed (when we'll
> > have a better idea of how that would work).
> 
> Yes, this was meant to cover cases which I still have not a clear idea
> about but I suspect people might have question about looking at their
> drivers. I'm totally fine adding it later when required.
> 
> > I think what should be explained here, as also mentioned by Sakari, is
> > that camera sensors can be exposed as multiple subdevs. The text below
> > is related to the pixel array, which is always the first subdev, with
> > one source pad and no sink pad. The other subdevs, modelling additional
> > processing blocks in the sensor, may use the selection API, but that's
> > out of scope for this patch.
> >
> > As we'll also need to document how other subdevs use the selection API,
> > as well as how sensors are usually handled, would it make sense to move
> > this to a separate file ? Sakari has proposed in [1] to create a new
> > Documentation/driver-api/media/camera-sensor.rst file. It would make
> > sense to centralize all sensor information there. This doesn't mean this
> > series should depend on Sakari's patch, we can handle merge conflicts
> > depending on what gets merged first.
> 
> I totally missed that one but I equally totally welcome that change. I
> would be happy to rebase this work on top of Sakari's patch which I
> will soon give a read to.
> 
> >
> > [1] https://lore.kernel.org/linux-media/20200730162040.15560-1-sakari.ailus@linux.intel.com/
> >
> > > >>> +
> > > >>> +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> > > >>
> > > >> V4L2_SEL_TGT_NATIVE -> V4L2_SEL_TGT_NATIVE_SIZE
> > > >>
> > > >> (same mistake is made elsewhere).
> > > >
> > > > Ah ups, I used TGT_NATIVE consistently, seems like I thought that was
> > > > the right name
> > > >
> > > >>> +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > > >>> +the immutable properties of the several different areas that compose the sensor
> > > >>> +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> >
> > V4L2_TGT_CROP isn't immutable, is it ?
> >
> 
> Right, I noticed that, but didn't want to be too heavy with createing
> a special section for CROP. But you're right, it's not immutable so it
> should not be mentioned here.
> 
> > > >>> +units. The logical disposition of pixels is defined by the sensor read-out
> > > >>> +starting point and direction, and may differ from the physical disposition of
> > > >>> +the pixel units in the pixel array matrix.
> > > >>> +
> > > >>> +Each pixel matrix portion is contained in a larger rectangle, with the most
> > > >>> +largest being the one that describes the pixel matrix physical size. This
> > > >>> +defines a hierarchical positional system, where each rectangle is defined
> > > >>> +relatively to the largest available one among the ones exposed by the
> > > >>> +sub-device driver. Each selection target and the associated pixel array portion
> > > >>> +it represents are below presented in order from the largest to the smallest one.
> >
> > I find this quite confusing. As Hans suggested, I think each target
> > should define its boundaries. I'd drop this paragraph completely, as you
> > already explain below that all rectangles are defined relatively to
> > V4L2_SEL_TGT_NATIVE_SIZE.
> 
> Ack.
> 
> > > >>> +
> > > >>> +Pixel array physical size
> > > >>> +^^^^^^^^^^^^^^^^^^^^^^^^^
> > > >>> +
> > > >>> +The image sensor chip is composed by a number of physical pixels, not all of
> > > >>> +them readable by the application processor. Invalid or unreadable lines might
> > > >>> +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > > >>> +they might be tagged with an invalid data type (DT) so that the receiver
> > > >>> +automatically discard them.
> >
> > "might" is a bit weak for unreadable lines, there's no way they can be
> > transmitted if they can't be read :-)
> 
> This paragraph reflects my confusion on the subject. My interpretation
> is that for CSI-2 sensors, you cannot crop a black pixels area and
> capture just them. At the contrary, the black pixels are sent on the
> bus (maybe that can be optionally enabled/disabled) tagged with a
> special DT and interleaved with image data and you have to instruct
> your receiver to discard or accept that DT, and have black pixels
> captured to a separate memory area, or at buffer end (that depends on
> the receiver's architecture I guess).

This is all sensor specific I'm afraid :-( It's entirely conceivable
that a sensor would implement a single crop rectangle that can span the
black pixels, while another sensor could restrict cropping to the
effective area, and enable/disable the black pixels output through a
separate configuration. The black pixels lines will however very likely
be cropped horizontally the same way as the visible pixels, as
variable-length lines isn't widely supported on the receiver side, but
some sensors could implement more options.

> At the same time, I won't be
> surprised if some sensor's allow you to explicitly crop on black
> pixels areas and only put them on the bus. Knowing how the SMIA++
> standard handles that part might help establishing an expected
> behaviour (I really, really, wish we had as a community any leverage
> to influence sensor manufacturer towards a standardized behaviour, it
> would be time for the industry to do so. </wishful thinking>).

MIPI CCS ? Still, not all vendors will implement that, sometimes for
good reasons, mostly probably just "because".

> If that's correct, I wonder how would that possibly work with parallel
> sensors, where you cannot tag data on the bus. I there assume you have
> to explicitly select the black region to capture.

From a sensor point of view it makes no difference, it's only from a
receiver point of view that the situation may get more complex as you
can't filter on the data type.

> I there tried to, confusingly, express that different behaviour and
> stay as much as possible generic not to rule out any existing case.
> 
> > One way to generalize this a bit would be to explain, after the first
> > sentence, that not all pixels may be read by the sensor, that among the
> > pixels that are read invalid ones may not be transmitted on the bus, and
> > that among transmitted pixels not all of them may be possible to capture
> > on the receiver side. For instance, invalid lines may be transmitted as
> > part of the vertical blanking on parallel buses, or tagged as blanking
> > data or null data on CSI-2 buses. Most receivers are not able to capture
> > either.
> >
> > (On a side note, strictly speaking, a CSI-2 receiver that would be able
> > to capture null or blanking packets wouldn't be compliant with the CSI-2
> > spec.)
> >
> > > >>> The size of the whole pixel matrix area is
> > > >>> +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > > >>> +defined as position (0, 0). All the other selection targets are defined
> > > >>> +relatively to this, larger, rectangle. The rectangle returned by
> >
> > s/, larger,/
> >
> > > >>> +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > > >>> +does not change at run-time and cannot be modified from userspace.
> > > >>
> > > >> It is a good idea to mention that if there are no invalid or unreadable pixels/lines,
> > > >> then V4L2_SEL_TGT_NATIVE_SIZE == V4L2_SEL_TGT_CROP_BOUNDS.
> > > >
> > > > Yes it is! I'll add it here
> >
> > Should it be added below instead, where you define
> > V4L2_SEL_TGT_CROP_BOUNDS ? It's best to avoid mentioning something that
> > isn't defined yet when possible.
> 
> I have a question for Sakari on this target, but I'll deflect it to
> the reply to your comment  on patch 1/4.
> 
> > > >>> +
> > > >>> +Pixel array readable area
> > > >>> +^^^^^^^^^^^^^^^^^^^^^^^^^
> > > >>> +
> > > >>> +The V4L2_SEL_TGT_CROP_BOUNDS targets returns size and position of the readable
> > > >>> +area of the pixel array matrix, including pixels with valid image data and pixel
> > > >>> +used for calibration purposes, such as optical black pixels. It is not unlikely
> >
> > s/not unlikely/likely ? Or just "common".
> >
> > > >>> +that valid pixels and optical black pixels are surrounded by non-readable rows
> > > >>> +and columns of pixels. Those does not concur in the definition of the
> >
> > s/does/do/
> >
> > I'm not sure "concur" is the right word. Did you mean "those are not
> > part of the V4L2_SEL_TGT_CROP_BOUNDS rectangle" ?
> 
> Yes, I meant they should not be counted in the definition of the BOUND
> rectangle sizes.
> 
> > > >>> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. The rectangle returned by
> > > >>> +V4L2_SEL_TGT_CROP_BOUNDS describes an immutable property of the image sensor, it
> > > >>> +does not change at run-time and cannot be modified from userspace.
> > > >>
> > > >> Mention that BOUNDS is enclosed by NATIVE_SIZE.
> > > >
> > > > I tried to express that in the intro section with
> > > >
> > > > "Each pixel matrix portion is contained in a larger rectangle, with the most
> > > > largest being the one that describes the pixel matrix physical size."
> > > >
> > > > But I guess it's worth to express that for each target!
> > > >
> > > >>> +
> > > >>> +Pixel array active area
> > > >>> +^^^^^^^^^^^^^^^^^^^^^^^
> > > >>> +
> > > >>> +The portion of the pixel array which contains valid image data is defined as the
> > > >>> +active area of the pixel matrix. The active pixel array is is accessed by mean
> > > >>
> >
> > s/is is/is/
> >
> > > >> mean -> means
> > > >>
> > > >>> +of the V4L2_SEL_TGT_CROP_DEFAULT target, and is contained in the larger
> > > >>> +V4L2_SEL_TGT_CROP_BOUNDS rectangle. It represents the largest possible frame
> > > >>> +resolution the sensor can produce and defines the dimension of the full
> > > >>> +field-of-view. The rectangle returned by V4L2_SEL_TGT_CROP_BOUNDS describes an
> > > >>
> > > >> BOUNDS -> DEFAULT
> > > >
> > > > ups
> > > >
> > > >>> +immutable property of the image sensor, it does not change at run-time and
> > > >>> +cannot be modified from userspace.
> > > >>
> > > >> Mention that CROP_DEFAULT is enclosed by CROP_BOUNDS
> > > >>
> > > >>> +
> > > >>> +Analog crop rectangle
> > > >>
> > > >> Why analog? It's just the crop rectangle, nothing analog about it.
> > > >
> > > > We used the 'analogCrop' term in libcamera to differentiate the
> > > > cropping which happens on the sensor pixel array matrix to select the
> > > > region to process and produce image from. Sensor with an on-board
> > > > scaler can perform other cropping steps to implement, in example digital
> > > > zoom, so we expect to have a 'digital crop' phase as well. RAW
> > > > sensors, in example, will only have an analogCrop rectangle.
> > > >
> > > > Quoting the libcamera definition of analog crop:
> > > >
> > > >  * horizontal and vertical sizes define the portion of the pixel array which
> > > >  * is read-out and provided to the sensor's internal processing pipeline, before
> > > >  * any pixel sub-sampling method, such as pixel binning, skipping and averaging
> > > >  * take place.
> > > >
> > > > should I keep it or remove it ?
> > >
> > > It's a very confusing term. Especially since this API can also be used with analog
> > > video capture devices (Composite/S-Video) where the video signal actually is analog.
> > >
> > > In the V4L2 API there is no such thing as 'analog crop', so please remove it.
> >
> > Jacopo is right, sensors usually perform cropping in the analog domain
> > (by not reading out all pixels from the pixel array), and also support
> > cropping in later stages, after binning/skipping, and after further
> > scaling. Note that all of these crop operations are optional. Although
> > not common, it's also not unconceivable that a sensor wouldn't support
> > cropping at all.
> >
> > This being said, it only makes sense to talk about analog crop when
> > multiple crop operations are performed, and thus in the context of the
> > whole sensor, with multiple subdevs. If we explain this, as proposed
> > above, and make it clear that the usage of the selection rectangles
> > defined here applies to the pixel array only, we can drop the "analog"
> > term, and just talk about cropping in the pixel array.
> 
> It's fine as long as it removes any ambiguity.
> 
> > > >>> +^^^^^^^^^^^^^^^^^^^^^
> > > >>> +
> > > >>> +The sensor driver might decide, in order to adjust the image resolution to best
> > > >>> +match the one requested by applications, to only process a part of the active
> > > >>> +pixel array matrix.
> >
> > I don't think that's the right approach. With MC-based devices, the
> > philosophy is to expose all configuration parameters to userspace. It's
> > not about sensor drivers making decisions, but about userspace deciding
> > to crop at the pixel array level.
> >
> > This being said, I'm aware the decision is made by drivers when they're
> > mode-based. Please see below for that.
> 
> Correct, and I should now be used enough to the 'userspace drives'
> approach to remember about documenting it :)
> 
> > > >>> The selected area is read-out and processed by the image
> > > >>> +sensor on-board ISP in order to produce images of the desired size and
> > > >>> +resolution while possible maintaing the largest possible field-of-view. The
> > > >>
> > > >> maintaing -> maintaining
> > > >>
> > > >> Actually, I'd drop 'while possible maintaing the largest possible field-of-view'
> > > >> entirely. It doesn't make much sense.
> > > >
> > > > Ack
> >
> > In general, in this section, as we're documenting the pixel array, let's
> > not talk about the ISP.
> >
> > > >>> +cropped portion of the pixel array which is used to produce images is returned
> > > >>> +by the V4L2_SEL_TGT_CROP target and represent the only information that can
> > > >>
> > > >> represent -> represents
> > > >>
> > > >>> +change at runtime as it depends on the currently configured sensor mode and
> > > >>> +desired image resolution. If the sub-device driver supports that, userspace
> > > >>> +can set the analog crop rectangle to select which portion of the pixel array
> > > >>
> > > >> s/analog//
> > > >>
> > > >>> +to read out.
> >
> > I think it's better to focus on the best case, and document usage of
> > crop rectangles in general first, for drivers that expose full
> > configurability of the sensor. A separate section should then then make
> > a note of how mode-based drivers differ, which is mostly in the
> > V4L2_SEL_TGT_CROP target being read-only, and on the single subdev
> > hiding all the processing steps, with the crop target thus being the
> > result of all cropping operations, analog and digital.
> >
> > Sakari's patch has a bit of information about this, it may be useful to
> > reuse it or integrate with it somehow.
> 
> I'll try to see how the two parts can be piled one on top of the
> other.
> 
> > > >> Mention that CROP is enclosed by CROP_BOUNDS and defaults to CROP_DEFAULT.
> > > >>
> > > >> Make a note that CROP can also be used to obtain optical black pixels.
> > > >
> > > > What about:
> > > >
> > > > +desired image resolution. If the sub-device driver supports that, userspace
> > > > +can set the analog crop rectangle to select which portion of the pixel array
> > > > +to read out including, if supported, optical black pixels.
> > >
> > > Hmm, that's a bit awkward. How about:
> > >
> > > +desired image resolution. If supported by the sub-device driver, userspace
> > > +can set the crop rectangle to select which portion of the pixel array
> > > +to read out. This may include optical black pixels if those are part of
> > > +V4L2_SEL_TGT_CROP_BOUNDS.
> > >
> > > >>> +
> > > >>>
> > > >>>  Types of selection targets
> > > >>>  --------------------------

Hi Laurent,

On Wed, Aug 19, 2020 at 04:06:23AM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Tue, Aug 18, 2020 at 11:17:43AM +0300, Sakari Ailus wrote:
> > On Mon, Aug 10, 2020 at 10:17:57AM +0200, Jacopo Mondi wrote:
> > > On Sun, Aug 09, 2020 at 08:58:21PM +0300, Laurent Pinchart wrote:
> > > > On Wed, Aug 05, 2020 at 12:57:18PM +0200, Jacopo Mondi wrote:
> > > > > The V4L2 selection API are also used to access the pixel array
> > > > > properties of an image sensor, such as the size and position of active
> > > > > pixels and the cropped area of the pixel matrix used to produce images.
> > > > >
> > > > > Currently no clear definition of the different areas that compose an
> > > > > image sensor pixel array matrix is provided in the specification, and
> > > > > the actual meaning of each selection target when applied to an image
> > > > > sensor was not provided.
> > > > >
> > > > > Provide in the sub-device documentation the definition of the pixel
> > > > > matrix properties and the selection target associated to each of them.
> > > > >
> > > > > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > > > > ---
> > > > >  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> > > > >  1 file changed, 81 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > index 134d2fb909fa4..c47861dff9b9b 100644
> > > > > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> > > > >  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> > > > >  the image size either up or down. :ref:`v4l2-selection-flags`
> > > > >
> > > > > +.. _v4l2-subdev-pixel-array-properties:
> > > > > +
> > > > > +Selection targets for image sensors properties
> > > > > +----------------------------------------------
> > > > > +
> > > > > +The V4L2 selection API can be used on sub-devices that represent an image
> > > > > +sensor to retrieve the sensor's pixel array matrix properties by using the
> > > > > +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > > > > +
> > > > > +Sub-device drivers for image sensor usually register a single source pad, but in
> > > > > +the case they expose more, the pixel array properties can be accessed from
> > > > > +any of them.
> > > > > +
> > > > > +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> > > > > +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > > > > +the immutable properties of the several different areas that compose the sensor
> > > > > +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> > > > > +units. The logical disposition of pixels is defined by the sensor read-out
> > > > > +starting point and direction, and may differ from the physical disposition of
> > > > > +the pixel units in the pixel array matrix.
> > > > > +
> > > > > +Each pixel matrix portion is contained in a larger rectangle, with the most
> > > > > +largest being the one that describes the pixel matrix physical size. This
> > > > > +defines a hierarchical positional system, where each rectangle is defined
> > > > > +relatively to the largest available one among the ones exposed by the
> > > > > +sub-device driver. Each selection target and the associated pixel array portion
> > > > > +it represents are below presented in order from the largest to the smallest one.
> > > > > +
> > > > > +Pixel array physical size
> > > > > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > +
> > > > > +The image sensor chip is composed by a number of physical pixels, not all of
> > > > > +them readable by the application processor. Invalid or unreadable lines might
> > > > > +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > > > > +they might be tagged with an invalid data type (DT) so that the receiver
> > > > > +automatically discard them. The size of the whole pixel matrix area is
> > > > > +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > > > > +defined as position (0, 0). All the other selection targets are defined
> > > > > +relatively to this, larger, rectangle. The rectangle returned by
> > > > > +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > > > > +does not change at run-time and cannot be modified from userspace.
> > > >
> > > > As I think I've mentioned previously (not sure if it was by e-mail or on
> > > > IRC), we could also decide to set V4L2_SEL_TGT_NATIVE_SIZE ==
> > > > V4L2_SEL_TGT_CROP_BOUNDS by ignoring the non-readable pixels completely.
> > > > What's the advantage of exposing them in the API, when the sensors
> > > > doesn't provide them to the rest of the pipeline ?
> > > 
> > > I don't know :) I'm also  bit confused on what's the purpose of
> > > NATIVE, this commit seems to suggest it was meant to replace
> > > CROP_BOUNDS, but I'm not sure about that.
> > > 
> > > commit b518d86609cc066b626120fe6ec6fe3a4ccfcd54
> > > Author: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > Date:   Thu Nov 6 16:54:33 2014 -0300
> > > 
> > >     [media] smiapp: Support V4L2_SEL_TGT_NATIVE_SIZE
> > > 
> > >     Add support for selection target V4L2_SEL_TGT_NATIVE_SIZE. It is equivalent
> > >     of what V4L2_SEL_TGT_CROP_BOUNDS used to be. Support for
> > >     V4L2_SEL_TGT_CROP_BOUNDS is still supported by the driver as a compatibility
> > >     interface.
> > > 
> > > Sakari, do you recall if that's was the original plan ?
> > 
> > That was to denote the size of the pixel array indeed. We didn't discuss
> > dark or invalid pixels at the time.
> > 
> > So this was just there to tell that it's the pixel array you're cropping
> > from.
> > 
> > But as long as it's API-wise compatible, I don't think anything prevents
> > re-purposing this to include other areas. The documentation (AFAIR) does
> > not say this has to be the same as the crop bounds rectangle.
> 
> What do you think would be best ? Should we include the non-readable
> pixels in V4L2_SEL_TGT_NATIVE_SIZE, with V4L2_SEL_TGT_CROP_BOUNDS then
> being strictly smaller, or drop them completely from the API, with
> V4L2_SEL_TGT_CROP_BOUNDS being equal to V4L2_SEL_TGT_NATIVE_SIZE ? It
> may be that we have to allow both to support existing drivers, but we
> should pick one of the two options and make it mandatory for new
> drivers.

That's a very good question.

What would be the purpose of adding pixels that cannot be read? I assume
they would not affect sensor timing either in that case, so there would be
no difference whether they are there or not. The crop bounds should contain
everything whereas for the default crop should reflect the area of the
visible pixels.

I guess in theory the visible pixels could not be cropped by the sensor in
analogue cropping step, so it might be worth having a separate rectangle
for those, too.

There could also be sensors that read the dark pixels internally and use
them somehow without sending their data out. don't think we should try to
model that though as it's likely entirely internal to the sensor in that
case.

Hi Sakari,

On Wed, Aug 19, 2020 at 01:20:00PM +0300, Sakari Ailus wrote:
> On Wed, Aug 19, 2020 at 04:06:23AM +0300, Laurent Pinchart wrote:
> > On Tue, Aug 18, 2020 at 11:17:43AM +0300, Sakari Ailus wrote:
> > > On Mon, Aug 10, 2020 at 10:17:57AM +0200, Jacopo Mondi wrote:
> > > > On Sun, Aug 09, 2020 at 08:58:21PM +0300, Laurent Pinchart wrote:
> > > > > On Wed, Aug 05, 2020 at 12:57:18PM +0200, Jacopo Mondi wrote:
> > > > > > The V4L2 selection API are also used to access the pixel array
> > > > > > properties of an image sensor, such as the size and position of active
> > > > > > pixels and the cropped area of the pixel matrix used to produce images.
> > > > > >
> > > > > > Currently no clear definition of the different areas that compose an
> > > > > > image sensor pixel array matrix is provided in the specification, and
> > > > > > the actual meaning of each selection target when applied to an image
> > > > > > sensor was not provided.
> > > > > >
> > > > > > Provide in the sub-device documentation the definition of the pixel
> > > > > > matrix properties and the selection target associated to each of them.
> > > > > >
> > > > > > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > > > > > ---
> > > > > >  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> > > > > >  1 file changed, 81 insertions(+)
> > > > > >
> > > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > index 134d2fb909fa4..c47861dff9b9b 100644
> > > > > > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> > > > > >  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> > > > > >  the image size either up or down. :ref:`v4l2-selection-flags`
> > > > > >
> > > > > > +.. _v4l2-subdev-pixel-array-properties:
> > > > > > +
> > > > > > +Selection targets for image sensors properties
> > > > > > +----------------------------------------------
> > > > > > +
> > > > > > +The V4L2 selection API can be used on sub-devices that represent an image
> > > > > > +sensor to retrieve the sensor's pixel array matrix properties by using the
> > > > > > +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > > > > > +
> > > > > > +Sub-device drivers for image sensor usually register a single source pad, but in
> > > > > > +the case they expose more, the pixel array properties can be accessed from
> > > > > > +any of them.
> > > > > > +
> > > > > > +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> > > > > > +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > > > > > +the immutable properties of the several different areas that compose the sensor
> > > > > > +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> > > > > > +units. The logical disposition of pixels is defined by the sensor read-out
> > > > > > +starting point and direction, and may differ from the physical disposition of
> > > > > > +the pixel units in the pixel array matrix.
> > > > > > +
> > > > > > +Each pixel matrix portion is contained in a larger rectangle, with the most
> > > > > > +largest being the one that describes the pixel matrix physical size. This
> > > > > > +defines a hierarchical positional system, where each rectangle is defined
> > > > > > +relatively to the largest available one among the ones exposed by the
> > > > > > +sub-device driver. Each selection target and the associated pixel array portion
> > > > > > +it represents are below presented in order from the largest to the smallest one.
> > > > > > +
> > > > > > +Pixel array physical size
> > > > > > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > > +
> > > > > > +The image sensor chip is composed by a number of physical pixels, not all of
> > > > > > +them readable by the application processor. Invalid or unreadable lines might
> > > > > > +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > > > > > +they might be tagged with an invalid data type (DT) so that the receiver
> > > > > > +automatically discard them. The size of the whole pixel matrix area is
> > > > > > +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > > > > > +defined as position (0, 0). All the other selection targets are defined
> > > > > > +relatively to this, larger, rectangle. The rectangle returned by
> > > > > > +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > > > > > +does not change at run-time and cannot be modified from userspace.
> > > > >
> > > > > As I think I've mentioned previously (not sure if it was by e-mail or on
> > > > > IRC), we could also decide to set V4L2_SEL_TGT_NATIVE_SIZE ==
> > > > > V4L2_SEL_TGT_CROP_BOUNDS by ignoring the non-readable pixels completely.
> > > > > What's the advantage of exposing them in the API, when the sensors
> > > > > doesn't provide them to the rest of the pipeline ?
> > > > 
> > > > I don't know :) I'm also  bit confused on what's the purpose of
> > > > NATIVE, this commit seems to suggest it was meant to replace
> > > > CROP_BOUNDS, but I'm not sure about that.
> > > > 
> > > > commit b518d86609cc066b626120fe6ec6fe3a4ccfcd54
> > > > Author: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > Date:   Thu Nov 6 16:54:33 2014 -0300
> > > > 
> > > >     [media] smiapp: Support V4L2_SEL_TGT_NATIVE_SIZE
> > > > 
> > > >     Add support for selection target V4L2_SEL_TGT_NATIVE_SIZE. It is equivalent
> > > >     of what V4L2_SEL_TGT_CROP_BOUNDS used to be. Support for
> > > >     V4L2_SEL_TGT_CROP_BOUNDS is still supported by the driver as a compatibility
> > > >     interface.
> > > > 
> > > > Sakari, do you recall if that's was the original plan ?
> > > 
> > > That was to denote the size of the pixel array indeed. We didn't discuss
> > > dark or invalid pixels at the time.
> > > 
> > > So this was just there to tell that it's the pixel array you're cropping
> > > from.
> > > 
> > > But as long as it's API-wise compatible, I don't think anything prevents
> > > re-purposing this to include other areas. The documentation (AFAIR) does
> > > not say this has to be the same as the crop bounds rectangle.
> > 
> > What do you think would be best ? Should we include the non-readable
> > pixels in V4L2_SEL_TGT_NATIVE_SIZE, with V4L2_SEL_TGT_CROP_BOUNDS then
> > being strictly smaller, or drop them completely from the API, with
> > V4L2_SEL_TGT_CROP_BOUNDS being equal to V4L2_SEL_TGT_NATIVE_SIZE ? It
> > may be that we have to allow both to support existing drivers, but we
> > should pick one of the two options and make it mandatory for new
> > drivers.
> 
> That's a very good question.
> 
> What would be the purpose of adding pixels that cannot be read? I assume
> they would not affect sensor timing either in that case, so there would be
> no difference whether they are there or not.

Timings is a good point, could there be sensors that read those pixels
but don't send them out ? Maybe to avoid edge effects ? That would be
accounted for in the H/V blank though, wouldn't it ?

> The crop bounds should contain
> everything whereas for the default crop should reflect the area of the
> visible pixels.

I believe there are sensors that have all pixels visible, but recommend
not using edge pixels as they are affected by edge effects, even if
those pixels can be read out and transferred. In that case
V4L2_SEL_TGT_CROP_BOUNDS should include the edge pixels, but maybe
V4L2_SEL_TGT_CROP_DEFAULT shouldn't ?

> I guess in theory the visible pixels could not be cropped by the sensor in
> analogue cropping step, so it might be worth having a separate rectangle
> for those, too.

I'm not sure to follow you here.

> There could also be sensors that read the dark pixels internally and use
> them somehow without sending their data out. don't think we should try to
> model that though as it's likely entirely internal to the sensor in that
> case.

Agreed.

Hi Laurent,

On Wed, Aug 19, 2020 at 03:38:40PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Wed, Aug 19, 2020 at 01:20:00PM +0300, Sakari Ailus wrote:
> > On Wed, Aug 19, 2020 at 04:06:23AM +0300, Laurent Pinchart wrote:
> > > On Tue, Aug 18, 2020 at 11:17:43AM +0300, Sakari Ailus wrote:
> > > > On Mon, Aug 10, 2020 at 10:17:57AM +0200, Jacopo Mondi wrote:
> > > > > On Sun, Aug 09, 2020 at 08:58:21PM +0300, Laurent Pinchart wrote:
> > > > > > On Wed, Aug 05, 2020 at 12:57:18PM +0200, Jacopo Mondi wrote:
> > > > > > > The V4L2 selection API are also used to access the pixel array
> > > > > > > properties of an image sensor, such as the size and position of active
> > > > > > > pixels and the cropped area of the pixel matrix used to produce images.
> > > > > > >
> > > > > > > Currently no clear definition of the different areas that compose an
> > > > > > > image sensor pixel array matrix is provided in the specification, and
> > > > > > > the actual meaning of each selection target when applied to an image
> > > > > > > sensor was not provided.
> > > > > > >
> > > > > > > Provide in the sub-device documentation the definition of the pixel
> > > > > > > matrix properties and the selection target associated to each of them.
> > > > > > >
> > > > > > > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > > > > > > ---
> > > > > > >  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> > > > > > >  1 file changed, 81 insertions(+)
> > > > > > >
> > > > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > > index 134d2fb909fa4..c47861dff9b9b 100644
> > > > > > > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > > @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> > > > > > >  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> > > > > > >  the image size either up or down. :ref:`v4l2-selection-flags`
> > > > > > >
> > > > > > > +.. _v4l2-subdev-pixel-array-properties:
> > > > > > > +
> > > > > > > +Selection targets for image sensors properties
> > > > > > > +----------------------------------------------
> > > > > > > +
> > > > > > > +The V4L2 selection API can be used on sub-devices that represent an image
> > > > > > > +sensor to retrieve the sensor's pixel array matrix properties by using the
> > > > > > > +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > > > > > > +
> > > > > > > +Sub-device drivers for image sensor usually register a single source pad, but in
> > > > > > > +the case they expose more, the pixel array properties can be accessed from
> > > > > > > +any of them.
> > > > > > > +
> > > > > > > +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> > > > > > > +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > > > > > > +the immutable properties of the several different areas that compose the sensor
> > > > > > > +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> > > > > > > +units. The logical disposition of pixels is defined by the sensor read-out
> > > > > > > +starting point and direction, and may differ from the physical disposition of
> > > > > > > +the pixel units in the pixel array matrix.
> > > > > > > +
> > > > > > > +Each pixel matrix portion is contained in a larger rectangle, with the most
> > > > > > > +largest being the one that describes the pixel matrix physical size. This
> > > > > > > +defines a hierarchical positional system, where each rectangle is defined
> > > > > > > +relatively to the largest available one among the ones exposed by the
> > > > > > > +sub-device driver. Each selection target and the associated pixel array portion
> > > > > > > +it represents are below presented in order from the largest to the smallest one.
> > > > > > > +
> > > > > > > +Pixel array physical size
> > > > > > > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > > > +
> > > > > > > +The image sensor chip is composed by a number of physical pixels, not all of
> > > > > > > +them readable by the application processor. Invalid or unreadable lines might
> > > > > > > +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > > > > > > +they might be tagged with an invalid data type (DT) so that the receiver
> > > > > > > +automatically discard them. The size of the whole pixel matrix area is
> > > > > > > +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > > > > > > +defined as position (0, 0). All the other selection targets are defined
> > > > > > > +relatively to this, larger, rectangle. The rectangle returned by
> > > > > > > +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > > > > > > +does not change at run-time and cannot be modified from userspace.
> > > > > >
> > > > > > As I think I've mentioned previously (not sure if it was by e-mail or on
> > > > > > IRC), we could also decide to set V4L2_SEL_TGT_NATIVE_SIZE ==
> > > > > > V4L2_SEL_TGT_CROP_BOUNDS by ignoring the non-readable pixels completely.
> > > > > > What's the advantage of exposing them in the API, when the sensors
> > > > > > doesn't provide them to the rest of the pipeline ?
> > > > > 
> > > > > I don't know :) I'm also  bit confused on what's the purpose of
> > > > > NATIVE, this commit seems to suggest it was meant to replace
> > > > > CROP_BOUNDS, but I'm not sure about that.
> > > > > 
> > > > > commit b518d86609cc066b626120fe6ec6fe3a4ccfcd54
> > > > > Author: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > > Date:   Thu Nov 6 16:54:33 2014 -0300
> > > > > 
> > > > >     [media] smiapp: Support V4L2_SEL_TGT_NATIVE_SIZE
> > > > > 
> > > > >     Add support for selection target V4L2_SEL_TGT_NATIVE_SIZE. It is equivalent
> > > > >     of what V4L2_SEL_TGT_CROP_BOUNDS used to be. Support for
> > > > >     V4L2_SEL_TGT_CROP_BOUNDS is still supported by the driver as a compatibility
> > > > >     interface.
> > > > > 
> > > > > Sakari, do you recall if that's was the original plan ?
> > > > 
> > > > That was to denote the size of the pixel array indeed. We didn't discuss
> > > > dark or invalid pixels at the time.
> > > > 
> > > > So this was just there to tell that it's the pixel array you're cropping
> > > > from.
> > > > 
> > > > But as long as it's API-wise compatible, I don't think anything prevents
> > > > re-purposing this to include other areas. The documentation (AFAIR) does
> > > > not say this has to be the same as the crop bounds rectangle.
> > > 
> > > What do you think would be best ? Should we include the non-readable
> > > pixels in V4L2_SEL_TGT_NATIVE_SIZE, with V4L2_SEL_TGT_CROP_BOUNDS then
> > > being strictly smaller, or drop them completely from the API, with
> > > V4L2_SEL_TGT_CROP_BOUNDS being equal to V4L2_SEL_TGT_NATIVE_SIZE ? It
> > > may be that we have to allow both to support existing drivers, but we
> > > should pick one of the two options and make it mandatory for new
> > > drivers.
> > 
> > That's a very good question.
> > 
> > What would be the purpose of adding pixels that cannot be read? I assume
> > they would not affect sensor timing either in that case, so there would be
> > no difference whether they are there or not.
> 
> Timings is a good point, could there be sensors that read those pixels
> but don't send them out ? Maybe to avoid edge effects ? That would be
> accounted for in the H/V blank though, wouldn't it ?

I guess we could ignore it, as it takes place during what is indeed
considered as blanking.

> 
> > The crop bounds should contain
> > everything whereas for the default crop should reflect the area of the
> > visible pixels.
> 
> I believe there are sensors that have all pixels visible, but recommend
> not using edge pixels as they are affected by edge effects, even if
> those pixels can be read out and transferred. In that case
> V4L2_SEL_TGT_CROP_BOUNDS should include the edge pixels, but maybe
> V4L2_SEL_TGT_CROP_DEFAULT shouldn't ?

I guess so. But in practice I wonder if there are such implementations.

> 
> > I guess in theory the visible pixels could not be cropped by the sensor in
> > analogue cropping step, so it might be worth having a separate rectangle
> > for those, too.
> 
> I'm not sure to follow you here.

I'm saying the sensor hardware could in theory be unable to read only the
visible pixels.

Hi Sakari,

On Thu, Aug 20, 2020 at 06:16:04PM +0300, Sakari Ailus wrote:
> On Wed, Aug 19, 2020 at 03:38:40PM +0300, Laurent Pinchart wrote:
> > On Wed, Aug 19, 2020 at 01:20:00PM +0300, Sakari Ailus wrote:
> > > On Wed, Aug 19, 2020 at 04:06:23AM +0300, Laurent Pinchart wrote:
> > > > On Tue, Aug 18, 2020 at 11:17:43AM +0300, Sakari Ailus wrote:
> > > > > On Mon, Aug 10, 2020 at 10:17:57AM +0200, Jacopo Mondi wrote:
> > > > > > On Sun, Aug 09, 2020 at 08:58:21PM +0300, Laurent Pinchart wrote:
> > > > > > > On Wed, Aug 05, 2020 at 12:57:18PM +0200, Jacopo Mondi wrote:
> > > > > > > > The V4L2 selection API are also used to access the pixel array
> > > > > > > > properties of an image sensor, such as the size and position of active
> > > > > > > > pixels and the cropped area of the pixel matrix used to produce images.
> > > > > > > >
> > > > > > > > Currently no clear definition of the different areas that compose an
> > > > > > > > image sensor pixel array matrix is provided in the specification, and
> > > > > > > > the actual meaning of each selection target when applied to an image
> > > > > > > > sensor was not provided.
> > > > > > > >
> > > > > > > > Provide in the sub-device documentation the definition of the pixel
> > > > > > > > matrix properties and the selection target associated to each of them.
> > > > > > > >
> > > > > > > > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > > > > > > > ---
> > > > > > > >  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> > > > > > > >  1 file changed, 81 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > > > index 134d2fb909fa4..c47861dff9b9b 100644
> > > > > > > > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > > > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > > > @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> > > > > > > >  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> > > > > > > >  the image size either up or down. :ref:`v4l2-selection-flags`
> > > > > > > >
> > > > > > > > +.. _v4l2-subdev-pixel-array-properties:
> > > > > > > > +
> > > > > > > > +Selection targets for image sensors properties
> > > > > > > > +----------------------------------------------
> > > > > > > > +
> > > > > > > > +The V4L2 selection API can be used on sub-devices that represent an image
> > > > > > > > +sensor to retrieve the sensor's pixel array matrix properties by using the
> > > > > > > > +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > > > > > > > +
> > > > > > > > +Sub-device drivers for image sensor usually register a single source pad, but in
> > > > > > > > +the case they expose more, the pixel array properties can be accessed from
> > > > > > > > +any of them.
> > > > > > > > +
> > > > > > > > +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> > > > > > > > +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > > > > > > > +the immutable properties of the several different areas that compose the sensor
> > > > > > > > +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> > > > > > > > +units. The logical disposition of pixels is defined by the sensor read-out
> > > > > > > > +starting point and direction, and may differ from the physical disposition of
> > > > > > > > +the pixel units in the pixel array matrix.
> > > > > > > > +
> > > > > > > > +Each pixel matrix portion is contained in a larger rectangle, with the most
> > > > > > > > +largest being the one that describes the pixel matrix physical size. This
> > > > > > > > +defines a hierarchical positional system, where each rectangle is defined
> > > > > > > > +relatively to the largest available one among the ones exposed by the
> > > > > > > > +sub-device driver. Each selection target and the associated pixel array portion
> > > > > > > > +it represents are below presented in order from the largest to the smallest one.
> > > > > > > > +
> > > > > > > > +Pixel array physical size
> > > > > > > > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > > > > +
> > > > > > > > +The image sensor chip is composed by a number of physical pixels, not all of
> > > > > > > > +them readable by the application processor. Invalid or unreadable lines might
> > > > > > > > +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > > > > > > > +they might be tagged with an invalid data type (DT) so that the receiver
> > > > > > > > +automatically discard them. The size of the whole pixel matrix area is
> > > > > > > > +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > > > > > > > +defined as position (0, 0). All the other selection targets are defined
> > > > > > > > +relatively to this, larger, rectangle. The rectangle returned by
> > > > > > > > +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > > > > > > > +does not change at run-time and cannot be modified from userspace.
> > > > > > >
> > > > > > > As I think I've mentioned previously (not sure if it was by e-mail or on
> > > > > > > IRC), we could also decide to set V4L2_SEL_TGT_NATIVE_SIZE ==
> > > > > > > V4L2_SEL_TGT_CROP_BOUNDS by ignoring the non-readable pixels completely.
> > > > > > > What's the advantage of exposing them in the API, when the sensors
> > > > > > > doesn't provide them to the rest of the pipeline ?
> > > > > > 
> > > > > > I don't know :) I'm also  bit confused on what's the purpose of
> > > > > > NATIVE, this commit seems to suggest it was meant to replace
> > > > > > CROP_BOUNDS, but I'm not sure about that.
> > > > > > 
> > > > > > commit b518d86609cc066b626120fe6ec6fe3a4ccfcd54
> > > > > > Author: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > > > Date:   Thu Nov 6 16:54:33 2014 -0300
> > > > > > 
> > > > > >     [media] smiapp: Support V4L2_SEL_TGT_NATIVE_SIZE
> > > > > > 
> > > > > >     Add support for selection target V4L2_SEL_TGT_NATIVE_SIZE. It is equivalent
> > > > > >     of what V4L2_SEL_TGT_CROP_BOUNDS used to be. Support for
> > > > > >     V4L2_SEL_TGT_CROP_BOUNDS is still supported by the driver as a compatibility
> > > > > >     interface.
> > > > > > 
> > > > > > Sakari, do you recall if that's was the original plan ?
> > > > > 
> > > > > That was to denote the size of the pixel array indeed. We didn't discuss
> > > > > dark or invalid pixels at the time.
> > > > > 
> > > > > So this was just there to tell that it's the pixel array you're cropping
> > > > > from.
> > > > > 
> > > > > But as long as it's API-wise compatible, I don't think anything prevents
> > > > > re-purposing this to include other areas. The documentation (AFAIR) does
> > > > > not say this has to be the same as the crop bounds rectangle.
> > > > 
> > > > What do you think would be best ? Should we include the non-readable
> > > > pixels in V4L2_SEL_TGT_NATIVE_SIZE, with V4L2_SEL_TGT_CROP_BOUNDS then
> > > > being strictly smaller, or drop them completely from the API, with
> > > > V4L2_SEL_TGT_CROP_BOUNDS being equal to V4L2_SEL_TGT_NATIVE_SIZE ? It
> > > > may be that we have to allow both to support existing drivers, but we
> > > > should pick one of the two options and make it mandatory for new
> > > > drivers.
> > > 
> > > That's a very good question.
> > > 
> > > What would be the purpose of adding pixels that cannot be read? I assume
> > > they would not affect sensor timing either in that case, so there would be
> > > no difference whether they are there or not.
> > 
> > Timings is a good point, could there be sensors that read those pixels
> > but don't send them out ? Maybe to avoid edge effects ? That would be
> > accounted for in the H/V blank though, wouldn't it ?
> 
> I guess we could ignore it, as it takes place during what is indeed
> considered as blanking.

Makes sense.

> > > The crop bounds should contain
> > > everything whereas for the default crop should reflect the area of the
> > > visible pixels.
> > 
> > I believe there are sensors that have all pixels visible, but recommend
> > not using edge pixels as they are affected by edge effects, even if
> > those pixels can be read out and transferred. In that case
> > V4L2_SEL_TGT_CROP_BOUNDS should include the edge pixels, but maybe
> > V4L2_SEL_TGT_CROP_DEFAULT shouldn't ?
> 
> I guess so. But in practice I wonder if there are such implementations.

I think it's actually quite common, sensors often have visible pixels on
the edges that are not counted in the nominal sensor resolution, but are
still commonly read out and consumed by the demosaicing operation.
Ideally we should report both the nominal active array (the pixels
guaranteed by the manufacturer to be good), and the potentially larger
exposed pixels array that include margins of potentially lower quality.

> > > I guess in theory the visible pixels could not be cropped by the sensor in
> > > analogue cropping step, so it might be worth having a separate rectangle
> > > for those, too.
> > 
> > I'm not sure to follow you here.
> 
> I'm saying the sensor hardware could in theory be unable to read only the
> visible pixels.

Hi Laurent,

On Thu, Nov 26, 2020 at 03:09:43PM +0200, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Thu, Aug 20, 2020 at 06:16:04PM +0300, Sakari Ailus wrote:
> > On Wed, Aug 19, 2020 at 03:38:40PM +0300, Laurent Pinchart wrote:
> > > On Wed, Aug 19, 2020 at 01:20:00PM +0300, Sakari Ailus wrote:
> > > > On Wed, Aug 19, 2020 at 04:06:23AM +0300, Laurent Pinchart wrote:
> > > > > On Tue, Aug 18, 2020 at 11:17:43AM +0300, Sakari Ailus wrote:
> > > > > > On Mon, Aug 10, 2020 at 10:17:57AM +0200, Jacopo Mondi wrote:
> > > > > > > On Sun, Aug 09, 2020 at 08:58:21PM +0300, Laurent Pinchart wrote:
> > > > > > > > On Wed, Aug 05, 2020 at 12:57:18PM +0200, Jacopo Mondi wrote:
> > > > > > > > > The V4L2 selection API are also used to access the pixel array
> > > > > > > > > properties of an image sensor, such as the size and position of active
> > > > > > > > > pixels and the cropped area of the pixel matrix used to produce images.
> > > > > > > > >
> > > > > > > > > Currently no clear definition of the different areas that compose an
> > > > > > > > > image sensor pixel array matrix is provided in the specification, and
> > > > > > > > > the actual meaning of each selection target when applied to an image
> > > > > > > > > sensor was not provided.
> > > > > > > > >
> > > > > > > > > Provide in the sub-device documentation the definition of the pixel
> > > > > > > > > matrix properties and the selection target associated to each of them.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > > > > > > > > ---
> > > > > > > > >  .../userspace-api/media/v4l/dev-subdev.rst    | 81 +++++++++++++++++++
> > > > > > > > >  1 file changed, 81 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > > > > index 134d2fb909fa4..c47861dff9b9b 100644
> > > > > > > > > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > > > > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
> > > > > > > > > @@ -386,6 +386,87 @@ requests on all selection targets, unless specifically told otherwise.
> > > > > > > > >  ``V4L2_SEL_FLAG_GE`` and ``V4L2_SEL_FLAG_LE`` flags may be used to round
> > > > > > > > >  the image size either up or down. :ref:`v4l2-selection-flags`
> > > > > > > > >
> > > > > > > > > +.. _v4l2-subdev-pixel-array-properties:
> > > > > > > > > +
> > > > > > > > > +Selection targets for image sensors properties
> > > > > > > > > +----------------------------------------------
> > > > > > > > > +
> > > > > > > > > +The V4L2 selection API can be used on sub-devices that represent an image
> > > > > > > > > +sensor to retrieve the sensor's pixel array matrix properties by using the
> > > > > > > > > +:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls.
> > > > > > > > > +
> > > > > > > > > +Sub-device drivers for image sensor usually register a single source pad, but in
> > > > > > > > > +the case they expose more, the pixel array properties can be accessed from
> > > > > > > > > +any of them.
> > > > > > > > > +
> > > > > > > > > +The ``V4L2_SEL_TGT_NATIVE``, ``V4L2_SEL_TGT_CROP_BOUNDS``,
> > > > > > > > > +``V4L2_SEL_TGT_CROP_DEFAULT`` and ``V4L2_TGT_CROP`` targets are used to retrieve
> > > > > > > > > +the immutable properties of the several different areas that compose the sensor
> > > > > > > > > +pixel array matrix. Each area describes a rectangle of logically adjacent pixel
> > > > > > > > > +units. The logical disposition of pixels is defined by the sensor read-out
> > > > > > > > > +starting point and direction, and may differ from the physical disposition of
> > > > > > > > > +the pixel units in the pixel array matrix.
> > > > > > > > > +
> > > > > > > > > +Each pixel matrix portion is contained in a larger rectangle, with the most
> > > > > > > > > +largest being the one that describes the pixel matrix physical size. This
> > > > > > > > > +defines a hierarchical positional system, where each rectangle is defined
> > > > > > > > > +relatively to the largest available one among the ones exposed by the
> > > > > > > > > +sub-device driver. Each selection target and the associated pixel array portion
> > > > > > > > > +it represents are below presented in order from the largest to the smallest one.
> > > > > > > > > +
> > > > > > > > > +Pixel array physical size
> > > > > > > > > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > > > > > +
> > > > > > > > > +The image sensor chip is composed by a number of physical pixels, not all of
> > > > > > > > > +them readable by the application processor. Invalid or unreadable lines might
> > > > > > > > > +not be transmitted on the data bus at all, or in case on CSI-2 capable sensors
> > > > > > > > > +they might be tagged with an invalid data type (DT) so that the receiver
> > > > > > > > > +automatically discard them. The size of the whole pixel matrix area is
> > > > > > > > > +retrieved using the V4L2_SEL_TGT_NATIVE target, which has its top-left corner
> > > > > > > > > +defined as position (0, 0). All the other selection targets are defined
> > > > > > > > > +relatively to this, larger, rectangle. The rectangle returned by
> > > > > > > > > +V4L2_SEL_TGT_NATIVE describes an immutable property of the image sensor, it
> > > > > > > > > +does not change at run-time and cannot be modified from userspace.
> > > > > > > >
> > > > > > > > As I think I've mentioned previously (not sure if it was by e-mail or on
> > > > > > > > IRC), we could also decide to set V4L2_SEL_TGT_NATIVE_SIZE ==
> > > > > > > > V4L2_SEL_TGT_CROP_BOUNDS by ignoring the non-readable pixels completely.
> > > > > > > > What's the advantage of exposing them in the API, when the sensors
> > > > > > > > doesn't provide them to the rest of the pipeline ?
> > > > > > > 
> > > > > > > I don't know :) I'm also  bit confused on what's the purpose of
> > > > > > > NATIVE, this commit seems to suggest it was meant to replace
> > > > > > > CROP_BOUNDS, but I'm not sure about that.
> > > > > > > 
> > > > > > > commit b518d86609cc066b626120fe6ec6fe3a4ccfcd54
> > > > > > > Author: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > > > > Date:   Thu Nov 6 16:54:33 2014 -0300
> > > > > > > 
> > > > > > >     [media] smiapp: Support V4L2_SEL_TGT_NATIVE_SIZE
> > > > > > > 
> > > > > > >     Add support for selection target V4L2_SEL_TGT_NATIVE_SIZE. It is equivalent
> > > > > > >     of what V4L2_SEL_TGT_CROP_BOUNDS used to be. Support for
> > > > > > >     V4L2_SEL_TGT_CROP_BOUNDS is still supported by the driver as a compatibility
> > > > > > >     interface.
> > > > > > > 
> > > > > > > Sakari, do you recall if that's was the original plan ?
> > > > > > 
> > > > > > That was to denote the size of the pixel array indeed. We didn't discuss
> > > > > > dark or invalid pixels at the time.
> > > > > > 
> > > > > > So this was just there to tell that it's the pixel array you're cropping
> > > > > > from.
> > > > > > 
> > > > > > But as long as it's API-wise compatible, I don't think anything prevents
> > > > > > re-purposing this to include other areas. The documentation (AFAIR) does
> > > > > > not say this has to be the same as the crop bounds rectangle.
> > > > > 
> > > > > What do you think would be best ? Should we include the non-readable
> > > > > pixels in V4L2_SEL_TGT_NATIVE_SIZE, with V4L2_SEL_TGT_CROP_BOUNDS then
> > > > > being strictly smaller, or drop them completely from the API, with
> > > > > V4L2_SEL_TGT_CROP_BOUNDS being equal to V4L2_SEL_TGT_NATIVE_SIZE ? It
> > > > > may be that we have to allow both to support existing drivers, but we
> > > > > should pick one of the two options and make it mandatory for new
> > > > > drivers.
> > > > 
> > > > That's a very good question.
> > > > 
> > > > What would be the purpose of adding pixels that cannot be read? I assume
> > > > they would not affect sensor timing either in that case, so there would be
> > > > no difference whether they are there or not.
> > > 
> > > Timings is a good point, could there be sensors that read those pixels
> > > but don't send them out ? Maybe to avoid edge effects ? That would be
> > > accounted for in the H/V blank though, wouldn't it ?
> > 
> > I guess we could ignore it, as it takes place during what is indeed
> > considered as blanking.
> 
> Makes sense.
> 
> > > > The crop bounds should contain
> > > > everything whereas for the default crop should reflect the area of the
> > > > visible pixels.
> > > 
> > > I believe there are sensors that have all pixels visible, but recommend
> > > not using edge pixels as they are affected by edge effects, even if
> > > those pixels can be read out and transferred. In that case
> > > V4L2_SEL_TGT_CROP_BOUNDS should include the edge pixels, but maybe
> > > V4L2_SEL_TGT_CROP_DEFAULT shouldn't ?
> > 
> > I guess so. But in practice I wonder if there are such implementations.
> 
> I think it's actually quite common, sensors often have visible pixels on
> the edges that are not counted in the nominal sensor resolution, but are
> still commonly read out and consumed by the demosaicing operation.
> Ideally we should report both the nominal active array (the pixels
> guaranteed by the manufacturer to be good), and the potentially larger
> exposed pixels array that include margins of potentially lower quality.

Yes, I think so, too.

But I do also think we'll need a new target for the purpose; this is really
about telling the pixels inside the area are of good quality, and it's
unrelated to cropping.

I wonder what to call it though. V4L2_SEL_TGT_PIXEL_PRETTY? :-)

> 
> > > > I guess in theory the visible pixels could not be cropped by the sensor in
> > > > analogue cropping step, so it might be worth having a separate rectangle
> > > > for those, too.
> > > 
> > > I'm not sure to follow you here.
> > 
> > I'm saying the sensor hardware could in theory be unable to read only the
> > visible pixels.
> 
> -- 
> Regards,
> 
> Laurent Pinchart