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

[Mario Kleiner]

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