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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
