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 at 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
