On Sat, Sep 22, 2012 at 07:12:52PM +0200, Sylwester Nawrocki wrote: > If we ever need the clock selection API I would vote for an IOCTL. > The controls API is a bad choice for something such fundamental as > type of clock for buffer timestamping IMHO. Let's stop making the > controls API a dumping ground for almost everything in V4L2! ;) > Perhaps VIDIOC_QUERYBUF and VIDIOC_DQBUF should be reporting > timestamps type only for the time they are being called. Not per buffer, > per device. And applications would be checking the flags any time they > want to find out what is the buffer timestamp type. Or every time if it > don't have full control over the device (S/G_PRIORITY). I'm all for adding an IOCTL, but if we think about adding a VIDIOC_S_TIMESTAMP_TYPE in the future, we might as well add a VIDIOC_G_TIMESTAMP_TYPE right now. Old drivers will return ENOSYS, so the application knows it will have to guess the type (or take own timestamps). I can't imagine anything useful coming from an app that has to process timestamps that change their source every now and then and I seriously doubt anyone will go to such an extent that they check the timestamp type on every buffer. If they don't set their priority high enough to prevent others from changing the timestamp type, they also run the risk of someone else changing the image format. It should be enough to forbid changing the timestamp type while I/O is in progress, as it is done for VIDIOC_S_FMT. Daniel -- 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
