Le 14/08/2025 à 12:03, Daniel Stone a écrit :
Hi Rob, On Wed, 13 Aug 2025 at 18:06, Robert Mader <[email protected]> wrote:@@ -60,6 +71,21 @@ static int vkms_wb_atomic_check(struct drm_connector *connector, if (ret < 0) return ret; + if (conn_state->writeback_color_encoding != DRM_COLOR_YCBCR_BT601 && + conn_state->writeback_color_encoding != DRM_COLOR_YCBCR_BT709 && + conn_state->writeback_color_encoding != DRM_COLOR_YCBCR_BT2020) { + DRM_DEBUG_KMS("Invalid color encoding %u\n", + conn_state->writeback_color_encoding); + return -EINVAL; + } + + if (conn_state->writeback_color_range != DRM_COLOR_YCBCR_LIMITED_RANGE && + conn_state->writeback_color_range != DRM_COLOR_YCBCR_FULL_RANGE) { + DRM_DEBUG_KMS("Invalid color range %u\n", + conn_state->writeback_color_range); + return -EINVAL; + }I didn't think you needed this check, as the core property code should already disallow setting an enum not in the supported list?
I think too
As this only takes effect on YUV, I suspect you might be better off adding a PASSTHROUGH or NOOP or similar value, which would be required to be used for RGB framebuffers, with it being required to specify the range and primaries for YUV formats. That being said, I don't think these are specific to YUV, as RGB can also have the same 16-235 squash applied to it. So maybe it is better off being generic?
I think there is exactly the same issue with the plane color property, and there is no RGB-specific values, they only apply on YUV. The current vkms plane composition code just ignore those values if not YUV.
Cheers, Daniel
-- -- Louis Chauvet, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
