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.
Kristian, i assume Wayland will also return presentation timestamps in the format and microsecond precision of the DRM, right?
On 05.10.12 18:22, intel-gfx-request@lists.freedesktop.org wrote:
Message: 7 Date: Fri, 5 Oct 2012 12:14:29 -0400 From: Kristian H?gsberg
...
I just had a quick look at driver/input/evdev.c, since evdev devices did a similar change recently to allow evdev timestamp from the monotonic clock. They're using a different time API:
time_mono = ktime_get(); time_real = ktime_sub(time_mono, ktime_get_monotonic_offset());
and
event->time = ktime_to_timeval(client->clkid == CLOCK_MONOTONIC ? mono : real);I'm not really up-to-date on kernel time APIs, but I wonder if that may be better? At least, I suspect we wouldn't need changes outside drm if we use this API.
Kristian
Userspace apps only have access to what gettimeofday() and clock_gettime() for CLOCK_REALTIME (== gettimeofday() afaik) and CLOCK_MONOTONIC return, so whatever is returned should be in CLOCK_MONOTONIC format, otherwise there will be lots of tears and dead kittens. I think what evdev does makes a lot of sense, but i'm also not up-to-date about the various layers of timing apis.
Yes, this should be the case, regardless of which kernel interface we decide to use.
--Imre