On Sunday, 1 March 2026 17:47:48 Central European Standard Time Dmitry Baryshkov wrote: > On Fri, Feb 27, 2026 at 08:20:07PM +0100, Nicolas Frattaroli wrote: > > From: Andri Yngvason <[email protected]> > > > > Add a new general DRM property named "color format" which can be used by > > userspace to request the display driver to output a particular color > > format. > > > > Possible options are: > > - auto (setup by default, driver internally picks the color format) > > - rgb > > - ycbcr444 > > - ycbcr422 > > - ycbcr420 > > > > Drivers should advertise from this list which formats they support. > > Together with this list and EDID data from the sink we should be able > > to relay a list of usable color formats to users to pick from. > > > > Signed-off-by: Werner Sembach <[email protected]> > > Signed-off-by: Andri Yngvason <[email protected]> > > Signed-off-by: Marius Vlad <[email protected]> > > Signed-off-by: Nicolas Frattaroli <[email protected]> > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 5 ++ > > drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++ > > drivers/gpu/drm/drm_connector.c | 124 > > ++++++++++++++++++++++++++++++++++++ > > include/drm/drm_connector.h | 103 ++++++++++++++++++++++++++++++ > > 4 files changed, 243 insertions(+) > > It seems and feels that the common code to be used (almost?) everywhere > would be: > > if (!drm_mode_create_color_format_property(connector, supported_formats)) > drm_connector_attach_color_format_property(connector); > > > Please mention somewhere the reason to split that into two functions. >
There isn't one I can think of, I kept it as-is since I inherited the code like this and figured this was the expected convention based on drm_mode_create_hdmi_colorspace_property -> drm_connector_attach_colorspace_property. Quite possibly, the idea is that callers can choose to probe whether a certain set of parameters would allow the property to be created without attaching it during said probing, but that's speculation on my part. Having it work like drm_connector_attach_max_bpc_property may make more sense here, and I'll refactor it to do this in the next revision unless anyone has any objections. Kind regards, Nicolas Frattaroli
