1// Copyright 2014-2023 The Khronos Group Inc. 2// 3// SPDX-License-Identifier: CC-BY-4.0 4 5include::{generated}/meta/{refprefix}VK_KHR_wayland_surface.adoc[] 6 7=== Other Extension Metadata 8 9*Last Modified Date*:: 10 2015-11-28 11*IP Status*:: 12 No known IP claims. 13*Contributors*:: 14 - Patrick Doane, Blizzard 15 - Faith Ekstrand, Intel 16 - Ian Elliott, LunarG 17 - Courtney Goeltzenleuchter, LunarG 18 - Jesse Hall, Google 19 - James Jones, NVIDIA 20 - Antoine Labour, Google 21 - Jon Leech, Khronos 22 - David Mao, AMD 23 - Norbert Nopper, Freescale 24 - Alon Or-bach, Samsung 25 - Daniel Rakos, AMD 26 - Graham Sellers, AMD 27 - Ray Smith, ARM 28 - Jeff Vigil, Qualcomm 29 - Chia-I Wu, LunarG 30 31=== Description 32 33The `VK_KHR_wayland_surface` extension is an instance extension. 34It provides a mechanism to create a slink:VkSurfaceKHR object (defined by 35the `apiext:VK_KHR_surface` extension) that refers to a Wayland 36code:wl_surface, as well as a query to determine support for rendering to a 37Wayland compositor. 38 39include::{generated}/interfaces/VK_KHR_wayland_surface.adoc[] 40 41=== Issues 42 431) Does Wayland need a way to query for compatibility between a particular 44physical device and a specific Wayland display? This would be a more general 45query than flink:vkGetPhysicalDeviceSurfaceSupportKHR: if the 46Wayland-specific query returned ename:VK_TRUE for a (slink:VkPhysicalDevice, 47`struct wl_display*`) pair, then the physical device could be assumed to 48support presentation to any slink:VkSurfaceKHR for surfaces on the display. 49 50*RESOLVED*: Yes. 51flink:vkGetPhysicalDeviceWaylandPresentationSupportKHR was added to address 52this issue. 53 542) Should we require surfaces created with flink:vkCreateWaylandSurfaceKHR 55to support the ename:VK_PRESENT_MODE_MAILBOX_KHR present mode? 56 57*RESOLVED*: Yes. 58Wayland is an inherently mailbox window system and mailbox support is 59required for some Wayland compositor interactions to work as expected. 60While handling these interactions may be possible with 61ename:VK_PRESENT_MODE_FIFO_KHR, it is much more difficult to do without 62deadlock and requiring all Wayland applications to be able to support 63implementations which only support ename:VK_PRESENT_MODE_FIFO_KHR would be 64an onerous restriction on application developers. 65 66=== Version History 67 68 * Revision 1, 2015-09-23 (Jesse Hall) 69 ** Initial draft, based on the previous contents of VK_EXT_KHR_swapchain 70 (later renamed VK_EXT_KHR_surface). 71 72 * Revision 2, 2015-10-02 (James Jones) 73 ** Added vkGetPhysicalDeviceWaylandPresentationSupportKHR() to resolve 74 issue #1. 75 ** Adjusted wording of issue #1 to match the agreed-upon solution. 76 ** Renamed "`window`" parameters to "`surface`" to match Wayland 77 conventions. 78 79 * Revision 3, 2015-10-26 (Ian Elliott) 80 ** Renamed from VK_EXT_KHR_wayland_surface to VK_KHR_wayland_surface. 81 82 * Revision 4, 2015-11-03 (Daniel Rakos) 83 ** Added allocation callbacks to vkCreateWaylandSurfaceKHR. 84 85 * Revision 5, 2015-11-28 (Daniel Rakos) 86 ** Updated the surface create function to take a pCreateInfo structure. 87 88 * Revision 6, 2017-02-08 (Faith Ekstrand) 89 ** Added the requirement that implementations support 90 ename:VK_PRESENT_MODE_MAILBOX_KHR. 91 ** Added wording about interactions between flink:vkQueuePresentKHR and 92 the Wayland requests sent to the compositor. 93