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? 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? Cheers, Daniel
