From 79a417297699df6ade9b6363d7050a3c1e39c087 Mon Sep 17 00:00:00 2001 From: Pekka Paalanen Date: Wed, 13 Apr 2016 10:56:39 +0300 Subject: stable/presentation-time: reorganize clock_id documentation Move compositor implementors' guidelines to the end. Recombine the affected paragraphs. No changes to the wording are made. Suggested-by: Bryce Harrington Signed-off-by: Pekka Paalanen Reviewed-by: Bryce Harrington --- stable/presentation-time/presentation-time.xml | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/stable/presentation-time/presentation-time.xml b/stable/presentation-time/presentation-time.xml index 00875a9..698ed96 100644 --- a/stable/presentation-time/presentation-time.xml +++ b/stable/presentation-time/presentation-time.xml @@ -99,18 +99,10 @@ presentation interface. The presentation clock does not change during the lifetime of the client connection. - The clock identifier is platform dependent. Clients must be - able to query the current clock value directly, not by asking - the compositor. - - On Linux/glibc, the identifier value is one of the clockid_t - values accepted by clock_gettime(). clock_gettime() is defined - by POSIX.1-2001. - - Compositors should prefer a clock which does not jump and is - not slewed e.g. by NTP. The absolute value of the clock is - irrelevant. Precision of one millisecond or better is - recommended. + The clock identifier is platform dependent. On Linux/glibc, + the identifier value is one of the clockid_t values accepted + by clock_gettime(). clock_gettime() is defined by + POSIX.1-2001. Timestamps in this clock domain are expressed as tv_sec_hi, tv_sec_lo, tv_nsec triples, each component being an unsigned @@ -122,6 +114,12 @@ Note that clock_id applies only to the presentation clock, and implies nothing about e.g. the timestamps used in the Wayland core protocol input events. + + Compositors should prefer a clock which does not jump and is + not slewed e.g. by NTP. The absolute value of the clock is + irrelevant. Precision of one millisecond or better is + recommended. Clients must be able to query the current clock + value directly, not by asking the compositor. -- cgit v1.2.3