On Mon, 22 Feb 2016 11:45:44 -0800 Bill Spitzak <spit...@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 5:34 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > > > > > + Argument 'refresh' gives the compositor's prediction of how > > + many nanoseconds after tv_sec, tv_nsec the very next output > > + refresh may occur. This is to further aid clients in > > + predicting future refreshes, i.e., estimating the timestamps > > + targeting the next few vblanks. If such prediction cannot > > + usefully be done, the argument is zero. > > + > > + The 64-bit value combined from seq_hi and seq_lo is the value > > + of the output's vertical retrace counter when the content > > + update was first scanned out to the display. This value must > > + be compatible with the definition of MSC in > > + GLX_OML_sync_control specification. Note, that if the display > > + path has a non-zero latency, the time instant specified by > > + this counter may differ from the timestamp's. > > + > > + If the output does not have a constant refresh rate, explicit > > + video mode switches excluded, then the refresh argument must > > + be zero. > > + > > + If the output does not have a concept of vertical retrace or a > > + refresh cycle, or the output device is self-refreshing without > > + a way to query the refresh count, then the arguments seq_hi > > + and seq_lo must be zero. > > > > I think the two middle paragraphs above need to be swapped. Number 1 and 3 > are talking about the refresh nanoseconds, number 2 and 4 are talking about > the sequence counter. Hi, sure, makes sense. Thanks, pq
pgpFitwhGVWTH.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
