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