On Wed, Nov 02, 2011 at 12:14:49PM +0200, Sakari Ailus wrote: > > How about making all drivers record monotonic timestamps and doing > > the conversion to/from realtime timestamps in v4l2-ioctl.c's > > __video_do_ioctl if requested? We then just need an extension of the > > spec to switch to monotonic, which can be implemented without touching > > a single driver. > > Converting between the two can be done when making the timestamp but it's > non-trivial at other times and likely isn't supported. I could be wrong, > though. This might lead to e.g. timestamps that are taken before switching > to summer time and for which the conversion is done after the switch. This > might be a theoretical possibility, but there might be also unfavourable > interaction with the NTP. Summertime/wintertime is purely a userspace thing. UTC as returned by gettimeofday is unaffected by that. NTP AFAIK adjusts the speed of the monotonic clock, so there is a constant delta between wall clock time and clock monotonic unless there is a leap second or someone calls settimeofday. Applications currently using the wall clock timestamps should have trouble dealing with that as well. > I'd probably rather just make a new timestamp in wall clock time in > v4l2-ioctl.c if needed using do_gettimeofday(). I think that would be worse than subtracting ktime_get_monotonic_offset(). You don't know the delay between capturing a frame and calling dqbuf. If there is a settimeofday between capturing a frame and calling dqbuf, the wall time clock was probably wrong when the frame was captured and subtracting the new ktime_get_monotonic_offset() yields a better timestamp. > Or just do the wall clock timestamps user space as they are typically > critical in timing. > > How would this work for you? As I keep the cpu busy with video encoding in the same thread, I'd expect a high jitter from taking timestamps in userspace. 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
