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 -- 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
