Re: [RFCv3 API PATCH 15/31] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.

[Sylwester Nawrocki <sylvester.nawrocki@gmail.com>]

On 09/15/2012 02:35 PM, Hans Verkuil wrote:
>>>> If we switch all existing drivers to monotonic timestamps in kernel release
>>>> 3.x, v4l2-compliance can just use the version it gets from VIDIOC_QUERYCAP and
>>>> enforce monotonic timestamps verification if the version is>= 3.x. This isn't
>>>> more difficult for apps to check than a dedicated flag (although it's less
>>>> explicit).
>>>
>>> I think that checking for the driver (kernel) version is a very poor substitute
>>> for testing against a proper flag.
>>
>> That flag should be the default in this case. The flag should be set by
>> the framework instead giving every driver the job of setting it.
>>
>>> One alternative might be to use a v4l2_buffer flag instead. That does have the
>>> advantage that in the future we can add additional flags should we need to
>>> support different clocks. Should we ever add support to switch clocks dynamically,
>>> then a buffer flag is more suitable than a driver capability. In that scenario
>>> it does make real sense to have a flag (or really mask).
>>>
>>> Say something like this:
>>>
>>> /* Clock Mask */
>>> V4L2_BUF_FLAG_CLOCK_MASK	0xf000
>>> /* Possible Clocks */
>>> V4L2_BUF_FLAG_CLOCK_SYSTEM	0x0000
> 
> I realized that this should be called:
> 
> V4L2_BUF_FLAG_CLOCK_UNKNOWN	0x0000
> 
> With a comment saying that is clock is either the system clock or a monotonic
> clock. That reflects the current situation correctly.
> 
>>> V4L2_BUF_FLAG_CLOCK_MONOTONIC	0x1000

There is already lots of overhead related to the buffers management, could 
we perhaps have the most common option defined in a way that drivers don't 
need to update each buffer's flags before dequeuing, only to indicate the
timestamp type (other than flags being modified in videobuf) ?

This buffer flags idea sounds to me worse than the capability flag. After 
all the drivers should use monotonic clock timestamps, shouldn't they ?

Have anyone has ever come with a use case for switching timestamps clock 
type, can anyone give an example of it ? How likely is we will ever need 
that ? 

:)

--

Regards,
Sylwester