Hi, On 9 March 2016 at 04:27, Jonas Ådahl <jad...@gmail.com> wrote: > By default the X server will try CLOCK_MONOTONIC_COARSE before > CLOCK_MONOTONIC. This causes various issues for Wayland display > servers who may get their internal timestamps from the CLOCK_MONOTONIC, > since it may very well happen that a timestamp from CLOCK_MONOTONIC > retrieved before a sending an X request will still be "later" than the > timestamp the X server than gets after receiving the request, due to > the fact that CLOCK_MONOTONIC_COARSE has a lower resolution.
For reference, this isn't anything to do with Wayland core protocol or similar, but that evdev devices can provide events with CLOCK_MONOTONIC timestamps, which we try to match. The original reason for using CLOCK_MONOTONIC_COARSE over CLOCK_MONOTONIC is that the former had a runtime power impact by battering HPET. I don't know if that still holds up on modern systems. > FWIW, I would be just as fine with always forcing CLOCK_MONOTONIC for Xwayland > if the command line argument seems unnecessary. This one is : Reviewed-by: Daniel Stone <dani...@collabora.com> and just forcing Xwayland to do it unconditionally is: Acked-by: Daniel Stone <dani...@collabora.com> > @@ -86,6 +88,10 @@ ddxProcessArgument(int argc, char *argv[], int i) > else if (strcmp(argv[i], "-shm") == 0) { > return 1; > } > + else if (strcmp(argv[i], "-forceMonotonic") == 0) { > + ForceClockId(CLOCK_MONOTONIC); > + return 1; > + } Needs #ifdef MONOTONIC_CLOCK. > +#ifdef MONOTONIC_CLOCK > +static clockid_t clockid; > +#endif > + > OsSigHandlerPtr > OsSignal(int sig, OsSigHandlerPtr handler) > { > @@ -427,6 +431,26 @@ GiveUp(int sig) > errno = olderrno; > } > > +#ifdef MONOTONIC_CLOCK > +void > +ForceClockId(clockid_t forced_clockid) > +{ > + struct timespec tp; > + > + if (clockid) { > + ErrorF("Warning: clock id was forced after it was initialized.\n"); Turn this into a BUG(), especially as the one below is a FatalError ... Cheers, Daniel _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel