set_time_stamp of commit-timing-v1 and VK_EXT_present_timing

If we use commit-timing-v1 to specify a time stamp for presentation by the compositor as part of VK_EXT_present_timing implementation, what would be the closest presentation stage as per spec ?

I'd say VK_PRESENT_STAGE_IMAGE_FIRST_PIXEL_OUT_BIT_EXT: The Wayland compositor ensures that the new buffer is scanned out no earlier than the specified timestamp.

Can you please provide any reference to back this up ?

From the spec of present-timing

VK_PRESENT_STAGE_IMAGE_FIRST_PIXEL_OUT_BIT_EXT is the stage after which data for the first pixel of the presentation request associated with the image has left the presentation engine for a display hardware.

I couldn't find any words in the spec of commit-timing-v1 close to display hardware. For set_timestamp Can we implicitly assume that compositor is intended to present to the display hardware ?

A set_timestamp request may be made before a wl_surface.commit to tell the compositor that the content is intended to be presented as closely as possible to, but not before, the specified time. The time is in the domain of the compositor's presentation clock.

From the current commit-timing v1 Wayland protocol spec:

      This protocol provides a method for adding a time constraint to surface
      content. This constraint indicates to the compositor that a content
      update should be presented as closely as possible to, but not before,
      a specified time.

I.e. the timestamp is a constraint for when the content update is presented, not for when it's latched.

Furthermore, the only frame of reference available to Wayland clients is the timestamps in presented events of the presentation time Wayland protocol:

        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.

Note that in practice, all Wayland compositors I know of use the timestamps from KMS flip completion events for this, which correspond to start of scanout. (See #175 for more details, TL;DR: Wayland clients getting reliable information about "first pixel visible" timing would likely require at least a revision of this protocol)

In summary, at this point the commit-timing timestamps can only meaningfully correspond to VK_PRESENT_STAGE_IMAGE_FIRST_PIXEL_OUT_BIT_EXT.

---

Assuming setting a timestamp constraint for when a content update is latched is useful (which isn't clear to me), it would require a revision of the commit-timing protocol, and another new protocol extension which provides information about future / past latching deadlines to clients.

Thank you. This makes sense.