From 7e62d25257db1927ab71123c0b6ca3533764f178 Mon Sep 17 00:00:00 2001 From: Pekka Paalanen Date: Tue, 23 Sep 2014 22:08:42 -0400 Subject: [PATCH] protocol: add presentation extension v5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add accurate presentation timing features to Wayland: queueing and feedback. This specification is based on the draft written by Frederic Plourde and redesigned by Pekka Paalanen. The RFC v2 version is from http://lists.freedesktop.org/archives/wayland-devel/2014-January/012988.html Changes in v3: * associate presentation time to current surface contents This implements the suggestion from http://lists.freedesktop.org/archives/wayland-devel/2014-February/013066.html which prevents surface content from jumping backwards in time if a client retroactively queues an update with a target time in the past. * use 64-bit tv_sec in presentation The time_t type used in struct timespec could be almost anything. POSIX probably defines it to be an integer, but not the size. Apparently it is usually 'long', which makes it 64-bit on x86_64. To be able to fully represent timespec values returned by clock_gettime, change the protocol to use 64 bits for the tv_sec part. * define an error for invalid tv_nsec This allow us to rely on the normalized timestamp form. * define some interactions with sub-surfaces Sub-surface cached state updates (synchronized mode) are designed especially for resizing. As queued updates are not meant to produce any resizing-like effects, they also do not trigger any sub-surface operations. * add sub-headings as xml comments * queued update cannot map Because before mapping, the surface has no main output assigned. An immediate commit is needed anyway, to be able to set all the surface state, which a queued update cannot touch. * frame callbacks are not queued It is not known when queueing frame callbacks would be useful. Changes in v4: * remove mentions of the queuing feature The specification has been split and the queuing feature will be added back in another version of the extension. * add flags argument to 'presented' event Describe the nature of how the update was presented to screen and the characteristics of the feedback information. No flags have been defined for now. * add a protocol error code for invalid flags Changes in v5: * remove the destroy method for the feedback object The protocol object should instead be automatically destroyed after a 'presented' or 'discarded' event has been triggered. * some grammatical corrections to the specification [Louis-Francis Ratté-Boulianne: split the spec in two parts] Signed-off-by: Pekka Paalanen Signed-off-by: Louis-Francis Ratté-Boulianne v3 Reviewed-by: Mario Kleiner --- Makefile.am | 5 + protocol/presentation_timing.xml | 240 +++++++++++++++++++++++++++++++ 2 files changed, 245 insertions(+) create mode 100644 protocol/presentation_timing.xml diff --git a/Makefile.am b/Makefile.am index b2d68935..b1dcc21a 100644 --- a/Makefile.am +++ b/Makefile.am @@ -78,6 +78,8 @@ nodist_weston_SOURCES = \ protocol/input-method-server-protocol.h \ protocol/workspaces-protocol.c \ protocol/workspaces-server-protocol.h \ + protocol/presentation_timing-protocol.c \ + protocol/presentation_timing-server-protocol.h \ protocol/scaler-protocol.c \ protocol/scaler-server-protocol.h @@ -445,6 +447,8 @@ nodist_libtoytoolkit_la_SOURCES = \ protocol/scaler-client-protocol.h \ protocol/workspaces-protocol.c \ protocol/workspaces-client-protocol.h \ + protocol/presentation_timing-protocol.c \ + protocol/presentation_timing-client-protocol.h \ protocol/xdg-shell-protocol.c \ protocol/xdg-shell-client-protocol.h @@ -987,6 +991,7 @@ EXTRA_DIST += \ protocol/wayland-test.xml \ protocol/xdg-shell.xml \ protocol/fullscreen-shell.xml \ + protocol/presentation_timing.xml \ protocol/scaler.xml man_MANS = weston.1 weston.ini.5 diff --git a/protocol/presentation_timing.xml b/protocol/presentation_timing.xml new file mode 100644 index 00000000..b5855d3c --- /dev/null +++ b/protocol/presentation_timing.xml @@ -0,0 +1,240 @@ + + + + + + Copyright © 2013-2014 Collabora, Ltd. + + Permission to use, copy, modify, distribute, and sell this + software and its documentation for any purpose is hereby granted + without fee, provided that the above copyright notice appear in + all copies and that both that copyright notice and this permission + notice appear in supporting documentation, and that the name of + the copyright holders not be used in advertising or publicity + pertaining to distribution of the software without specific, + written prior permission. The copyright holders make no + representations about the suitability of this software for any + purpose. It is provided "as is" without express or implied + warranty. + + THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS + SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND + FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY + SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN + AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, + ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF + THIS SOFTWARE. + + + + + + + + The main feature of this interface is accurate presentation + timing feedback to ensure smooth video playback while maintaining + audio/video synchronization. Some features use the concept of a + presentation clock, which is defined in presentation.clock_id + event. + + Request 'feedback' can be regarded as an additional wl_surface + method. It is part of the double-buffered surface state update + mechanism, where other requests first set up the state and then + wl_surface.commit atomically applies the state into use. In + other words, wl_surface.commit submits a content update. + + + + When the final realized presentation time is available, e.g. + after a framebuffer flip completes, the requested + presentation_feedback.presented events are sent. The final + presentation time can differ from the compositor's predicted + display update time and the update's target time, especially + when the compositor misses its target vertical blanking period. + + + + + These fatal protocol errors may be emitted in response to + illegal presentation requests. + + + + + + + + Informs the server that the client will not be using this + protocol object anymore. This does not affect any existing + objects created by this interface. + + + + + + Request presentation feedback for the current content submission + on the given surface. This creates a new presentation_feedback + object, which will deliver the feedback information once. If + multiple presentation_feedback objects are created for the same + submission, they will all deliver the same information. + + For details on what information is returned, see + presentation_feedback interface. + + + + + + + + + This event tells the client in which clock domain the + compositor interprets the timestamps used by the presentation + extension. This clock is called the presentation clock. + + The compositor sends this event when the client binds to the + 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 identifer 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. + + Timestamps in this clock domain are expressed as tv_sec_hi, + tv_sec_lo, tv_nsec triples, each component being an unsigned + 32-bit value. Whole seconds are in tv_sec which is a 64-bit + value combined from tv_sec_hi and tv_sec_lo, and the + additional fractional part in tv_nsec as nanoseconds. Hence, + for valid timestamps tv_nsec must be in [0, 999999999]. + + 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. + + + + + + + + + + A presentation_feedback object returns an indication that a + wl_surface content update has become visible to the user. + One object corresponds to one content update submission + (wl_surface.commit). There are two possible outcomes: the + content update is presented to the user, and a presentation + timestamp delivered; or, the user did not see the content + update because it was superseded or its surface destroyed, + and the content update is discarded. + + Once a presentation_feedback object has delivered an 'presented' + or 'discarded' event it is automatically destroyed. + + + + + As presentation can be synchronized to only one output at a + time, this event tells which output it was. This event is only + sent prior to the presented event. + + As clients may bind to the same global wl_output multiple + times, this event is sent for each bound instance that matches + the synchronized output. If a client has not bound to the + right wl_output global at all, this event is not sent. + + + + + + + + Currently no flags are defined. Some flags will be added + into presentation_feedback version 1 before it is released. + + + + + + + + The associated content update was displayed to the user at the + indicated time (tv_sec_hi/lo, tv_nsec). For the interpretation of + the timestamp, see presentation.clock_id event. + + The timestamp corresponds to the time when the content update + turned into light the first time on the surface's main output. + Compositors may approximate this from the framebuffer flip + completion events from the system, and the latency of the + physical display path if known. + + This event is preceeded by all related sync_output events + telling which output's refresh cycle the feedback corresponds + to, i.e. the main output for the surface. Compositors are + recommended to choose the output containing the largest part + of the wl_surface, or keeping the output they previously + chose. Having a stable presentation output association helps + clients predict future output refreshes (vblank). + + 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. + + + + + + + + + + + + + + The content update was never displayed to the user. + + + + +