Re: [RFC 1/4] time: export getnstime_raw_and_real for DRM

[Imre Deak <imre.deak@intel.com>]

On Tue, 2012-10-09 at 01:00 +0200, Mario Kleiner wrote:
> On 08.10.12 13:35, Imre Deak wrote:
> > On Sat, 2012-10-06 at 03:41 +0200, Mario Kleiner wrote:
> >> [...]
> >>
> >> But then Psychtoolbox checks each timestamp it gets from somewhere
> >> "outside" (OML_sync_control / INTEL_swap_events / ALSA audio timestamps,
> >> network receive timestamps, evdev, x11, ...) if it is in gettimeofday()
> >> aka CLOCK_REALTIME aka wall time or in CLOCK_MONOTONIC time and just
> >> remaps to whatever its reference clock is.
> >>
> >> There's no way around this than to have no fixed expectations, but to
> >> remap stuff on the fly, because different parts of the Linux universe
> >> have decided on different time bases, or even switched somewhere from
> >> one kernel version to the next in the last years, e.g., ALSA, which at
> >> some time switched from wall clock to CLOCK_MONOTONIC. Sometimes
> >> clock_gettime() wasn't available at all in older setups, so there only
> >> was gettimeofday(). Or toolkits like GStreamer use different timebases
> >> dependent on OS and sometimes even on plugins.
> >>
> >> I would expect that other timing sensitive apps have to have ways to
> >> handle this in similar ways.
> >
> > I think the question is, can we be sure? I don't think there is any
> > guarantee that random application X will not be confused by an
> > unconditional switch to monotonic timestamps.
> >
> >> Wrt. to the drm vblank/pageflip timestamps, the userspace extensions
> >> which expose these (INTEL_swap_events, OML_sync_control) don't allow
> >> apps to select which timebase to use, they define monotonic time as what
> >> is returned, so i don't know how a userspace app could actually ask the
> >> DRM for one or the other format? So i guess just switching to
> >> CLOCK_MONOTONIC shouldn't be that bad.
> >
> > An application could just use the kernel DRM interface directly. I admit
> > this is not very likely but this is what should determine the rules by
> > which we change the ABI.
> >
> Ok, that's a good point, agreed.

Still pondering about this, since I wouldn't want to complicate things
unnecessarily by storing both timestamps.

Based on the feedback you guys gave, I now also think we could simply
switch over to monotonic timestamps and have a module flag to fall back
to the old behavior. This is what ALSA does and what V4L2 people are
planning to do as well. As you pointed out the mainstream users of this
interface already expect a monotonic timestamp and I couldn't find
either a good reason to support both formats at the same time.

--Imre