This may seem unnecessary, but it is required for many Windows Vulkan apps to function correctly on Wayland when using dmabuf in certain situations (like direct scanout). Here is the mesa vulkan wayland WSI source code for reference: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/wsi/wsi_comm... I'll use the examples of Doom Eternal and Wolfenstein Youngblood to show where problems arise: Doom Eternal: 1. VkCreateWin32SurfaceKHR -> create new client surface -> create new wl_surface -> VkCreateWaylandSurfaceKHR -> WSI queries and stores the set of default DMABUF modifiers -> create the per surface dmabuf feedback (but the compositor has no idea where the wl_surface will be placed, so it can't send us any modifiers yet) 3. VkCreateSwapchainKHR 4. [Do some presents] 5. Swapchain becomes suboptimal (because the compositor sent the modifiers for the wl_surface, which end up being different than the default one) 6. VkDestroySwapchainKHR 7. VkCreateSurfaceKHR: The same thing happens as in step 1. This leads us to have default dmabuf modifiers again. (Note: it leaks VkSurface. That is the primary difference compared to Wolfenstein.) 9. VkCreateSwapchainKHR (old swapchain is not passed in) 10. ... and we eventually get another suboptimal since the per wl_surface dmabuf modifiers arrived, which causes the entire process to repeat infinitely. Wolfenstein Youngblood: 1. VkCreateWin32SurfaceKHR -> create new client surface -> create new wl_surface -> VkCreateWaylandSurfaceKHR -> WSI queries and stores the set of default DMABUF modifiers 3. VkCreateSwapchainKHR 4. [Do some presents] 5. Swapchain becomes suboptimal (because the compositor sent the modifiers for the wl_surface, which end up being different from the default one) 6. VkDestroySwapchainKHR 7. VkDestroySurfaceKHR -> destroys the client surface -> destroys the wl_surface from step 1 8. VkCreateSurfaceKHR: The same thing happens as in step 1. This leads us to have default dmabuf modifiers again. 9. VkCreateSwapchainKHR (old swapchain is not passed in) 10. ... and we eventually get another suboptimal since the per wl_surface dmabuf modifiers arrived, which causes the entire process to repeat infinitely. Another non-obvious important piece of information: if we use the same wl_surface for all the VkSurfaces for the same hwnd, then the compositor can remember and send the correct surface feedback much earlier, avoiding the problem. (I believe it is this roundtrip that helps: https://gitlab.freedesktop.org/mesa/mesa/-/blob/2046b79f2f043502a44bd86b64f2...) Therefore, to fix the above two cases, we need to: 1. Use the same wl_surface even after client_surface_release 2. Use the same wl_surface for each successive call to pCreateClientSurface. However, this would conflict with the OpenGL behavior according to dlls/win32u/opengl.c, so we would need to differentiate between an OpenGL and Vulkan client surface. Should I move this to win32u like the unused_drawable member of the WND structure? Note: Mesa 26.1 and lower have a WSI bug that causes this solution to not work in the case of VkSurface leaks, which I have fixed here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34918 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11342