Re: how to crop/scale in mono-subdev camera sensor driver?

[Sakari Ailus <sakari.ailus@iki.fi>]

Hi Sylwester and Nicolas,

Sylwester Nawrocki wrote:
> Hi,
>
> On 09/14/2012 05:00 PM, Nicolas THERY wrote:
>> Hello,
>>
>> I'm studying how to support cropping and scaling (binning, skipping, digital
>> scaling if any) for different models for camera sensor drivers.  There seems to
>> be (at least) two kinds of sensor drivers:
>>
>> 1) The smiapp driver has 2 or 3 subdevs: pixel array ->  binning (->  scaling).
>> It gives clients full control over the various ways of cropping and scaling
>> thanks to the selection API.
>>
>> 2) The mt9p031 driver (and maybe others) has a single subdev.  Clients use the
>> obsolete SUBDEV_S_CROP ioctl for selecting a region of interest in the pixel
>> array and SUBDEV_S_FMT for setting the source pad mbus size.  If the mbus size
>> differs from the cropping rectangle size, scaling is enabled and the driver
>> decides internally how to combine skipping and binning to achieve the requested
>> scaling factors.
>>
>> As SUBDEV_S_CROP is obsolete, I wonder whether it is okay to support cropping
>> and scaling in a mono-subdev sensor driver by (a) setting the cropping
>> rectangle with SUBDEV_S_SELECTION on the source pad, and (b) setting the
>> scaling factors via the source pad mbus size as in the mt9p031 driver?
>
> Cc: Sakari, Laurent
>
> AFAICT in a single subdev with one pad configuration your steps as above
> are valid, i.e. crop rectangle can be set with
> VIDIOC_SUBDEV_S_SELECTION(V4L2_SEL_TGT_CROP) and the sensor's output
> resolution with VIDIOC_SUBDEV_S_FMT.
>
> I guess documentation [1] wasn't clear enough about that ?
>
> The subdev crop ioctls are deprecated in favour of the selection API, so
> now VIDIOC_SUBDEV_G/S_SELECTION ioctls and corresponding subdev ops needs
> to be used anywhere you would have used SUBDEV_G/S_CROP before.
>
> This reminds me there are still a few drivers that need to be converted
> to use set/get_selection subdev pad level ops, rather than set/get_crop.
>
> [1] http://linuxtv.org/downloads/v4l-dvb-apis/subdev.html

After the selection IOCTLs were implemented for the subdev API, the 
subdev API then allowed explicitly configuring cropping after scaling 
inside a single subdev, among other improvements.

Before the introduction of the selection extensions, the subdev API has 
never allowed explicitly performing scaling and cropping using a single 
subdev with only a single source pad but still some sensor drivers 
implement it this way. It may well be that it is technically possible to 
use the source pad media bus format to configure scaling after cropping 
but that's against what's currently defined in the spec, for the reason 
that we wanted to define explicitly which selection targets are used for 
configuring cropping and scaling and in which order that configuration 
is expected to be done, in order to be able to configure the subdev 
without having to know anything else about it except that it implements 
the selection API. The scaler in the ISP can now be configured using 
exactly the same API as can the scaler in the sensor.

If you wish to expose the scaling configuration of the sensor using the 
V4L2 subdev interface, then I suggest doing what the SMIA++ driver does: 
multiple subdevs. See "Order of configuration and format propagation" 
behind the above URL.

Kind regards,

-- 
Sakari Ailus
sakari.ailus@iki.fi