[PATCH xserver] xwayland: Make it possible to force CLOCK_MONOTONIC
Daniel Stone
daniel at fooishbar.org
Wed Mar 9 10:36:32 UTC 2016
Hi,
On 9 March 2016 at 04:27, Jonas Ã…dahl <jadahl at 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 <daniels at collabora.com>
and just forcing Xwayland to do it unconditionally is:
Acked-by: Daniel Stone <daniels at 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
More information about the xorg-devel
mailing list