From 8cdb39103247fdde5764fc35b1b5cf60698db3e5 Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Thu, 4 Jul 2024 16:56:23 +0100 Subject: [PATCH] presentation-time: Specify refresh bounds for VRR When this extension was developed, we did not yet know how VRR hardware would behave in practice as it was not standardised, and the KMS interface was equally unstandardised. Now things have shaken out to an acceptable level, we have a good idea of what we need, which is simply to include a base refresh rate - the rate the compositor would drive the display for non-VRR clients. Bump the protocol to version 2 and require the compositor to provide a rate. Signed-off-by: Daniel Stone Signed-off-by: Derek Foreman --- stable/presentation-time/presentation-time.xml | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/stable/presentation-time/presentation-time.xml b/stable/presentation-time/presentation-time.xml index a10f703..c2431c5 100644 --- a/stable/presentation-time/presentation-time.xml +++ b/stable/presentation-time/presentation-time.xml @@ -25,7 +25,7 @@ DEALINGS IN THE SOFTWARE. - + @@ -123,7 +123,7 @@ - + A presentation_feedback object returns an indication that a wl_surface content update has become visible to the user. @@ -224,9 +224,12 @@ targeting the next few vblanks. If such prediction cannot usefully be done, the argument is zero. - If the output does not have a constant refresh rate, explicit - video mode switches excluded, then the refresh argument must - be zero. + For version 2 and later, if the output does not have a constant + refresh rate, explicit video mode switches excluded, then the + refresh argument must be either an appropriate rate picked by the + compositor (e.g. fastest rate), or 0 if no such rate exists. + For version 1, if the output does not have a constant refresh rate, + the refresh argument must be 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