Mark some issues as resolved.

Also fix some boilerplate language / copyright.

appendices/VK_EXT_present_timing.adoc

@@ -7,7 +7,7 @@ include::{generated}/meta/{refprefix}VK_EXT_present_timing.adoc[]
 === Other Extension Metadata
 
 *Last Modified Date*::
-    2024-05-30
+    2024-10-09
 *IP Status*::
     No known IP claims.
 *Contributors*::
@@ -159,7 +159,7 @@ Other extensions can add other platform-specific time domains.
 
 6) What time to use for targetPresentTime for early images?
 
-*PROPOSED*: Have no query for determining the current time in the PE’s time
+*RESOLVED*: Have no query for determining the current time in the PE’s time
 domain; and do allow the special value of zero for targetPresentTime,
 meaning that there is no target.
 
@@ -184,7 +184,9 @@ address this issue.
 
 8) Do we have a query for the anticipated latency from present to feedback?
 
-*UNRESOLVED*: There is some amount of latency from when an application calls
+*RESOLVED*: Do not provide a query for the feedback latency.
+
+There is some amount of latency from when an application calls
 vkQueuePresentKHR to when the image is displayed to the user, to when feedback
 is available to the application on when the image was actually displayed to the
 user.
@@ -198,27 +200,22 @@ the latency was approximately 5 refresh cycles (83.33ms).
 For higher-frequency displays, the latency may have a larger number of refresh
 cycles.
 
-Can such a query be reasonably answered by the driver? Is there other
-interesting information in this space that we may wish to capture?
-
 
 9) Do we have a query(s) about the number of VkPastPresentationTimingEXT
 structs to keep?
 
-*PROPOSED*: Let the application specify at swapchain creation how many
-results the swapchain is allowed to store before querying them with
-vkGetPastPresentationTimingEXT.
+*RESOLVED*: Do not provide a query for the number of results the swapchain
+is allowed to store before querying them with
+vkGetPastPresentationTimingEXT. Let the application specify that value with
+a dedicated API.
 
 
-10) How is the SWAPCHAIN_LOCAL time domain used with the calibrated
-timestamps extension?
+10) How is the SWAPCHAIN_LOCAL and STAGE_LOCAL time domain used with the
+calibrated timestamps extension?
 
-*PROPOSED*: Define a struct to chain into VkCalibratedTimestampInfoEXT::pNext
-that specifies a swapchain.
-Is anything additional needed for
-vkGetPhysicalDeviceCalibrateableTimeDomainsEXT, or are swapchain-local
-timestamps always calibrateable or always not calibrateable for a given
-device?
+*RESOLVED*: Define a struct to chain into
+VkCalibratedTimestampInfoEXT::pNext that specifies a swapchain and present
+stage.
 
 
 11) Should VK_PRESENT_MODE_FIFO_LATEST_READY_EXT be part of this extension,
@@ -235,5 +232,5 @@ Split it out into its own extension and define the interaction here.
   * Revision 2, 2022-11-30 (Lionel Duc)
   ** Rebase for public discussions.
 
-  * Revision 3, 2024-05-29 (Lionel Duc)
+  * Revision 3, 2024-10-09 (Lionel Duc)
   ** Public revisions.

chapters/VK_EXT_present_timing/PresentTimeInfo.adoc

@@ -1,4 +1,4 @@
-// Copyright (c) 2014-2023 Khronos Group.
+// Copyright (c) 2014-2024 Khronos Group.
 //
 // SPDX-License-Identifier: CC-BY-4.0
 

chapters/VK_EXT_present_timing/queries.adoc

@@ -1,4 +1,4 @@
-// Copyright (c) 2014-2023 Khronos Group.
+// Copyright (c) 2014-2024 Khronos Group.
 //
 // SPDX-License-Identifier: CC-BY-4.0
 
@@ -113,8 +113,8 @@ include::{generated}/api/structs/VkSwapchainTimingPropertiesEXT.adoc[]
     theoretical delay for the presentation engine to start a new refresh
     cycle upon processing a presentation request.
 
-If pname:variableRefreshDelay is the same as pname:refreshDuration, the
-presentation engine is operating as an FRR display.
+If pname:variableRefreshDelay is code:UINT64_MAX, the presentation engine is
+operating as an FRR display.
 
 Some platforms may: not provide timing properties until after at least one
 image has been presented to the pname:swapchain. If timing properties

chapters/features.adoc

@@ -5896,7 +5896,7 @@ include::{generated}/api/structs/VkPhysicalDevicePresentTimingFeaturesEXT.adoc[]
 
 This structure describes the following feature:
 
-  * pname:sType is the type of this structure.
+  * pname:sType is a elink:VkStructureType value identifying this structure.
   * pname:pNext is `NULL` or a pointer to a structure extending this
     structure.
   * [[features-presentTiming]] pname:presentTiming indicates that the

proposals/VK_EXT_present_timing.adoc

@@ -127,7 +127,7 @@ VkResult vkGetSwapchainTimingPropertiesEXT(
     uint64_t*                                   pSwapchainTimingPropertiesCounter,
     VkSwapchainTimingPropertiesEXT*             pSwapchainTimingProperties);
 ----
-Swapchain timing properties may change dynamically at any time without prior notification. For example, enabling power-saving mode on a device may cause it to lower the display panel's refresh rate. To allow applications to detect changes in those properties, a monotonically increasing counter is used by the implementation to identify the current state. This counter increases every time the swapchain properties are modified. `pSwapchainTimingPropertiesCounter` is a pointer to a `uint64_t` set by the implementation to the value of the current timing properties counter. Further updates to those properties are communicated back to the application when querying presentation timings via `vkGetPastPresentationTimingEXT`.
+Swapchain timing properties may change dynamically at any time without prior notification. For example, enabling power-saving mode on a device may cause it to lower the display panel's refresh rate. To allow applications to detect changes in those properties, a monotonically increasing counter is used by the implementation to identify the current state. This counter increases every time the swapchain properties are modified. `pSwapchainTimingPropertiesCounter` is a pointer to a `uint64_t` set by the implementation to the value of the current timing properties counter. Further updates to those properties are also communicated back to the application when querying presentation timings via `vkGetPastPresentationTimingEXT`.
 
 The `VkSwapchainTimingPropertiesEXT` structure is defined as:
 [source,c]
@@ -140,7 +140,7 @@ typedef struct VkSwapchainTimingPropertiesEXT {
 } VkSwapchainTimingPropertiesEXT;
 ----
 * `refreshDuration` is the duration in nanoseconds of the refresh cycle the presentation engine is operating at.
-* `variableRefreshDelay` is a duration in nanoseconds indicating the maximum theoretical delay for the presentation engine to start a new refresh cycle upon receiving a presentation request. If this value is the same as `refreshDuration`, the presentation engine is operating in FRR mode.
+* `variableRefreshDelay` is a duration in nanoseconds indicating the maximum theoretical delay for the presentation engine to start a new refresh cycle upon receiving a presentation request. If this value is `UINT64_MAX`, the presentation engine is operating in FRR mode.
 
 When the presentation engine is operating in VRR mode, `refreshDuration` is the minimum refresh duration.
 
@@ -172,7 +172,7 @@ typedef struct VkSwapchainTimeDomainPropertiesEXT {
 ----
 * `timeDomainCount` is an input specifying the size of the `pTimeDomains` and `pTimeDomainIds` arrays. If it is 0, it is set by the implementation upon return of `vkGetSwapchainTimeDomainPropertiesEXT` to the number of available time domains. Otherwise, it is set to the number of elements written in `pTimeDomains` and `pTimeDomainIds`.
 * `pTimeDomains` is an array of `VkTimeDomainEXT` currently supported by the swapchain.
-* `pTimeDomainIds` is an array of unique identifiers for each supported time domain. This is used to differentiate between multiple swapchain-local time domains that have the same `VkTimeDomainEXT` scope.
+* `pTimeDomainIds` is an array of unique identifiers for each supported time domain. Time domains are assigned a unique identifier within a swapchain by the implementation. This id is used to differentiate between multiple swapchain-local time domains of the same scope.
 
 Two new swapchain-local time domains are added in this proposal as `VkTimeDomainEXT` values:
 [source,c]
@@ -186,8 +186,6 @@ typedef enum VkTimeDomainEXT {
 * `VK_TIME_DOMAIN_PRESENT_STAGE_LOCAL_EXT` is a stage-local and swapchain-local time domain. It allows platforms where different presentation stages are handled by independent hardware to report timings in their own time domain. It is required to be supported.
 * `VK_TIME_DOMAIN_SWAPCHAIN_LOCAL_EXT` is a swapchain-local time domain, shared by all present stages.
 
-Time domains are assigned a unique identifier within a swapchain by the implementation. This id is used to differentiate between multiple swapchain-local time domains.
-
 To calibrate a swapchain-local or stage-local timestamp with another time domain, a new structure can be chained to `VkCalibratedTimestampInfoKHR` and passed to `vkGetCalibratedTimestampsKHR`:
 [source,c]
 ----