diff --git a/stable/presentation-time/presentation-time.xml b/stable/presentation-time/presentation-time.xml index 826fb3b..af18879 100644 --- a/stable/presentation-time/presentation-time.xml +++ b/stable/presentation-time/presentation-time.xml @@ -376,8 +376,16 @@ never be decreased below duration_min and can never be increased beyond duration_max. + The buffer_latching argument describes when the buffer latching + of a refresh cycle happens relative to the commit latching. See + the latching event for more information. + + The presentation argument describes when the presentation of a + refresh cycle happens relative to the commit latching. See the + latching event for more information. + This event indicates a discontinuity and the discontinuity flag - in the latching event is set. + of the next latching event is set. The compositor sends this event when the client binds to the refresh_cycle interface. @@ -394,6 +402,10 @@ summary="the maximum increase of the duration per refresh cycle in nanoseconds"/> + + @@ -415,44 +427,57 @@ - The latching event is sent no earlier than the compositor - deciding which commits will be chosen for the next - presentation, but as close to it as possible. + Each refresh cycle consists of a number of events in order: the + commit latching of the previous refresh cycle, the commit + latching of the current cycle, the buffer latching and the + presentation. - The exact time of this event is recorded in the commit latching - timestamp (commit_tv_sec_hi/lo, commit_tv_nsec). + The commit latching indicates the start of a new refresh cycle. + Two refresh cycles overlap between the commit latching and the + presentation. The buffer latching can be at the same time as + the commit latching. - The buffer latching timestamp (buffer_tv_sec_hi/lo, - buffer_tv_nsec) describes when all the fences of buffers - attached to surfaces of a commit must be signaled in order to - get presented on the refresh cycle of this latching event. + The time between two commit latching events is the duration of + the refresh cycle and describes the update frequency. - For the interpretation of the timestamps, see - presentation.clock_id. + If a content update is supposed to land on a certain refresh + cycle then the content update must be committed before the + commit latching and the buffers of the content update must be + ready before the buffer latching. + + A buffer is considered ready if there are no fences attached to + it or if all the explicit and implicit fences attached to it + are signaled. + + If a content update landed on a refresh cycle then it is + considered for presentation by the compositor on this or any + of the following refresh cycles. + + This latching event is sent no earlier than the commit latching + but as close to it as possible. + + The exact time of the commit latching is recorded in the + timestamp (commit_tv_sec_hi/lo, commit_tv_nsec). For the + interpretation of the timestamp, see presentation.clock_id. The 64-bit value combined from seq_hi and seq_lo is the value - of the output's vertical retrace counter of the following + of the output's vertical retrace counter of the refresh cycle's presentation. This value is compatible with seq_hi and seq_lo from presentation_feedback.presented. + + The time of the buffer latching and presentation relative to the + commit latching is sent in the state event. - - - - - - -