Hi Hans and Laurent, Hans Verkuil wrote: ... >>> Using v4l2_buffer flags to report the clock >>> ------------------------------------------- >>> >>> By defining flags like this: >>> >>> V4L2_BUF_FLAG_CLOCK_MASK 0x7000 >>> /* Possible Clocks */ >>> V4L2_BUF_FLAG_CLOCK_UNKNOWN 0x0000 /* system or monotonic, we don't know >> */ >>> V4L2_BUF_FLAG_CLOCK_MONOTONIC 0x1000 >>> >>> you could tell the application which clock is used. >>> >>> This does allow for more clocks to be added in the future and clock >>> selection would then be done by a control or possibly an ioctl. >> >> Clock selection could also be done by setting the buffer flag at QBUF time. > > True. Not a bad idea, actually. You would have to specify that setting the > clock to 0 (UNKNOWN) or any other unsupported clock, then that will be mapped > to MONOTONIC for newer kernels, but that's no problem. > > It has the advantage of not requiring any controls, ioctls, etc. The only > disadvantage is that you can't check if a particular clock is actually > supported. Although I guess you could do a QBUF followed by QUERYBUF to check > the clock bits. But you can't change to a different clock for that buffer > afterwards (at least, not until it is dequeued). Buffer flags are not and will not be available on subdevs. If the timestamp clock source is made selectable it should be selectable on subdevs, too. I'm afraid otherwise it may end up being a useless feature: the timestamps that the application gets from the devices must be from the same clock, otherwise they cannot be compared in a meaningful way. Or at least alternative mechanism should be provided to subdevs, but I don't see then why that wouldn't be done on V4L2, too... Kind regards, -- Sakari Ailus sakari.ailus@xxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
