On 07/21/2014 10:56 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Thursday 17 July 2014 23:04:09 Hans Verkuil wrote:
>> Hi Laurent,
>>
>> Something that just caught my eye:
>>
>> On 06/24/2014 01:54 AM, Laurent Pinchart wrote:
>>> The v4l2_pix_format structure has no reserved field. It is embedded in
>>> the v4l2_framebuffer structure which has no reserved fields either, and
>>> in the v4l2_format structure which has reserved fields that were not
>>> previously required to be zeroed out by applications.
>>>
>>> To allow extending v4l2_pix_format, inline it in the v4l2_framebuffer
>>> structure, and use the priv field as a magic value to indicate that the
>>> application has set all v4l2_pix_format extended fields and zeroed all
>>> reserved fields following the v4l2_pix_format field in the v4l2_format
>>> structure.
>>>
>>> The availability of this API extension is reported to userspace through
>>> the new V4L2_CAP_EXT_PIX_FORMAT capability flag. Just checking that the
>>> priv field is still set to the magic value at [GS]_FMT return wouldn't
>>> be enough, as older kernels don't zero the priv field on return.
>>>
>>> To simplify the internal API towards drivers zero the extended fields
>>> and set the priv field to the magic value for applications not aware of
>>> the extensions.
>>>
>>> Signed-off-by: Laurent Pinchart
>>> <laurent.pinchart+rene...@ideasonboard.com>
>>> ---
>>>
>>> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml
>>> b/Documentation/DocBook/media/v4l/pixfmt.xml index 91dcbc8..8c56cacd
>>> 100644
>>> --- a/Documentation/DocBook/media/v4l/pixfmt.xml
>>> +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
>
> [snip]
>
>>> +<para>To use the extended fields, applications must set the
>>> +<structfield>priv</structfield> field to
>>> +<constant>V4L2_PIX_FMT_PRIV_MAGIC</constant>, initialize all the extended
>>> fields
>>> +and zero the unused bytes of the <structname>v4l2_format</structname>
>>> +<structfield>raw_data</structfield> field.</para>
>>
>> Easy to write, much harder to implement. You would end up with something
>> like:
>>
>> memset(&fmt.fmt.pix.flags + sizeof(fmt.fmt.pix.flags), 0,
>> sizeof(fmt.fmt.raw_data) - sizeof(fmt.fmt.pix));
>>
>> Not user-friendly and error-prone.
>
> Or, rather, memset the whole v4l2_format structure to 0 and then fill it.
>
>> I would suggest adding a reserved array to pix_format instead, of at least
>> size (10 + 2 * 7) / 4 = 6 __u32. So: __u32 reserved[6]. Better would be to
>> go with 10 + 17 = 27 elements (same as the number of reserved elements in
>> v4l2_pix_format_mplane and one struct v4l2_plane_pix_format).
>
> Maybe it's a bit late, but I'm not sure to see where you got those values.
I'm making the assumption that anything we might want to add to pix_format, we
also want to add to pix_format_mplane. And the latter has 10 reserved bytes in
the pix_format_mplane struct and another 7 __u16's in each plane_pix_format.
So for a single plane format that means that there are 10 + 2 * 7 bytes reserved
space available in the multiplanar case (for the main struct + one plane
struct).
We could add a __u8 reserved[24] to pix_format. Then the amount of reserved
fields
in pix_format is identical to that in pix_format_mplane. That makes it easy to
keep in sync. The alignment looks to be OK too (no holes in the struct).
(BTW, when I wrote '10 + 17' in my earlier email I meant '10 + 14'. Sorry about
that confusion.)
But perhaps I am just over-analyzing and the real problem is the text in the
spec
'initialize all the extended fields and zero the unused bytes of the v4l2_format
raw_data field.'. It might be better to add something along the lines of:
"It is good practice to either call VIDIOC_G_FMT first, and then modify any
fields,
or to memset to 0 the whole v4l2_format structure before filling in fields."
> If we want to use a reserved array, it would make more sense to make it cover
> the
> whole raw_data array, otherwise future extensions could require an API
> change.
> On the other hand this would result in the v4l2_pix_format structure suddenly
> consuming 200 bytes instead of 36 today. That wouldn't be good when allocated
> on the stack.
I think the amount of available space in the multiplanar structs puts an upper
limit to what can be done with pix_format anyway. So reserving more space seems
unnecessary. It's not as if we'll see a huge number of new fields appearing.
I know of one flag that might be needed to signal alternate quantization ranges
to enhance the colorspace information, but that's all I know about.
Regards,
Hans
>
>> That will allow you to just say that the app should zero the reserved array.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
