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
