Hi Nicolas, I've sent some preliminary work here that should help you with this, and the HDMI helpers.
https://lore.kernel.org/r/[email protected] On Mon, Feb 16, 2026 at 02:01:16PM +0100, Nicolas Frattaroli wrote: > +/** > + * enum drm_color_format_enum - color model description > + * > + * This enum is a high-level description of the component makeup of the image > + * data. It says nothing about how the components are ordered or how many > bits > + * they take up (i.e. is unlike MEDIA_BUS_FMT\_ or DRM_FORMAT\_), but > + * describes the type of components (Luminance-Chrominance vs. RGB) and the > + * sub-sampling. > + * > + * &enum drm_color_format_enum makes statements about the same attribute of > + * an image as the DRM_COLOR_FORMAT\_ bitfields do. Its purpose is to inform > + * choices made by display protocol specific implementations when it comes to > + * translating it to e.g. &enum hdmi_colorspace or &enum dp_pixelformat, both > + * of which also describe the same attribute of the image at the same level > of > + * specificity. > + * > + * In precise terms, this enum describes a color model. It makes no > statements > + * about the primaries, gamma, or current phase of the moon used in > conversion > + * from one to the other. Furthermore, it also makes no statements about the > + * order of components (e.g. RGB vs. BGR), their depth in bits, or their > binary > + * packing. > + */ > +enum drm_color_format_enum { > + /** > + * @DRM_COLOR_FORMAT_ENUM_AUTO: The choice of format is left up to the > + * display protocol implementation. All implementations of the same > + * display protocol (e.g. HDMI) are supposed to behave the same way, > + * though display protocols may choose to behave differently compared to > + * each other (e.g. HDMI's "AUTO" does not have to match DP's "AUTO"). > + * > + * Implementations may rely on @DRM_COLOR_FORMAT_ENUM_AUTO to be falsy. > + */ The HDMI (and others if they exist) behaviour should be documented, and referred to here. > + DRM_COLOR_FORMAT_ENUM_AUTO = 0, > + > + /** > + * @DRM_COLOR_FORMAT_ENUM_RGB444: Image components are encoded as RGB > + * values of equal resolution. > + */ > + DRM_COLOR_FORMAT_ENUM_RGB444, > + > + /** > + * @DRM_COLOR_FORMAT_ENUM_YCBCR444: Image components are encoded as > + * luminance and chrominance of equal resolution. > + */ > + DRM_COLOR_FORMAT_ENUM_YCBCR444, > + > + /** > + * @DRM_COLOR_FORMAT_ENUM_YCBCR422: Image components are encoded as > + * luminance and chrominance with the chrominance components having half > + * the horizontal resolution. > + */ > + DRM_COLOR_FORMAT_ENUM_YCBCR422, > + > + /** > + * @DRM_COLOR_FORMAT_ENUM_YCBCR420: Image components are encoded as > + * luminance and chrominance with the chrominance components having half > + * the horizontal and vertical resolution. > + */ > + DRM_COLOR_FORMAT_ENUM_YCBCR420, > + > + /** > + * @DRM_COLOR_FORMAT_ENUM_NUM: The number of valid color format values > + * in this enum. Itself not a valid color format. > + */ > + DRM_COLOR_FORMAT_ENUM_NUM, > + > + /** > + * @DRM_COLOR_FORMAT_ENUM_INVALID: Error return value for conversion > + * functions encountering unexpected inputs. > + */ > + DRM_COLOR_FORMAT_ENUM_INVALID = -EINVAL, > +}; So, I think with my series mentioned above, we can settle on having this enum as the property value (and called drm_connector_output_format or something?) and drm_output_color_format used internally by everyone that needs to list the supported formats, or the one being enforced. Assuming we use the names I mentioned before, that means the drm_connector_output_format -> drm_output_color_format conversion needs to be done by the driver (or helpers like HDMI) to expand what "auto" means, and could be fallible, but the drm_output_color_format -> drm_connector_output_format conversion is infallible. Which should also simplify your code paths. Maxime
signature.asc
Description: PGP signature
