vulkan/wsi/x11: Fix behavior of vkGetPhysicalDeviceSurfacePresentModesKHR
authorEduardo Lima Mitev <elima@igalia.com>
Fri, 28 Oct 2016 12:34:39 +0000 (14:34 +0200)
committerEduardo Lima Mitev <elima@igalia.com>
Fri, 28 Oct 2016 14:53:06 +0000 (16:53 +0200)
commitb677b99db5c48ffd1eeef538b962080ac5fd65d9
treecb6ae58962af6bfb8c63a1f7036e5046fe24de13
parent7d059bdfb96a59043000e9d8c378ca077f473774
vulkan/wsi/x11: Fix behavior of vkGetPhysicalDeviceSurfacePresentModesKHR

x11_surface_get_present_modes() is currently asserting that the number of
elements in pPresentModeCount must be greater than or equal to the number
of present modes available. This is buggy because pPresentModeCount
elements are later copied from the internal modes' array, so if
pPresentModeCount is greater, it will overflow it.

On top of that, this assertion violates the spec. From the Vulkan 1.0
(revision 32, with KHR extensions), page 581 of the PDF:

    "If the value of pPresentModeCount is less than the number of
     presentation modes supported, at most pPresentModeCount values will be
     written. If pPresentModeCount is smaller than the number of
     presentation modes supported for the given surface, VK_INCOMPLETE
     will be returned instead of VK_SUCCESS to indicate that not all the
     available values were returned."

So, the correct behavior is: if pPresentModeCount is greater than the
internal number of formats, it is clamped to that many present modes. But
if it is lesser than that, then pPresentModeCount elements are copied,
and the call returns VK_INCOMPLETE.

This fix is similar (but simpler and more readable) than the one I provided
in 750d8cad72a for vkGetPhysicalDeviceSurfaceFormatsKHR, which was suffering
from the same problem.

Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
src/vulkan/wsi/wsi_common_x11.c