Re: [RFC 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs

[Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>]

Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Saturday 07 January 2012 12:09:29 Sakari Ailus wrote:
>> Sakari Ailus wrote:
>> ...
>>
>>> On second thought, I think I'll combine them into a new anonymous struct
>>> the field name of which I call "pad", unless that requires too intrusive
>>> changes in other drivers. How about that?
>>
>> And the answer to that is "no". The smia++ driver does store the format,
>> crop and compose values in arrays indexed by pad numbers which I think
>> is a natural thing for the driver to do. In many functiona the driver
>> uses internally it's trivial to choose the array either from driver's
>> internal data structure (V4L2_SUBDEV_FORMAT_ACTIVE) or the file handle
>> (V4L2_SUBDEV_FORMAT_TRY).
>>
>> Alternatively a named struct could be created for the same, but the
>> drivers might not need all the fields at all, or choose to store them in
>> a different form.
> 
> Drivers should use the v4l2_subdev_get_try_format(), 
> v4l2_subdev_get_try_crop() and v4l2_subdev_get_try_compose() functions to 
> access TRY formats and selection rectangles on file handles, so they shouldn't 
> care about the allocation details.

Good point... That requires some changes as well, like introduction of
v4l2_subdev_get_try_compose(). :-)

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com