This means that, effectively, passing HDR metadata puts the display into ST.2084 mode even when the colorSpace chosen for the swapchain is COLOR_SPACE_SRGB_NONLINEAR_KHR, a contradiction. As is, this implementation basically requires users hard-coding undocumented vendor-specific behavior, and leaves important questions unresolved (e.g. what primaries are in use).
The correct way forward, I think, would be to expose support for VK_EXT_swapchain_colorspace, add VK_COLOR_SPACE_HDR10_ST2084_EXT as a valid swapchain color space type, and set the HDMI EOTF depending on this color space.
You implement VK_EXT_hdr_metadata in a way where setting HDR metadata forces the internal swapchain color space to
HDMI_EOTF_SMPTE_ST2084
, completely ignoring the value ofpColorConfig->colorSpace
.This means that, effectively, passing HDR metadata puts the display into ST.2084 mode even when the colorSpace chosen for the swapchain is
COLOR_SPACE_SRGB_NONLINEAR_KHR
, a contradiction. As is, this implementation basically requires users hard-coding undocumented vendor-specific behavior, and leaves important questions unresolved (e.g. what primaries are in use).The correct way forward, I think, would be to expose support for
VK_EXT_swapchain_colorspace
, addVK_COLOR_SPACE_HDR10_ST2084_EXT
as a valid swapchain color space type, and set the HDMI EOTF depending on this color space.