On Thu, Sep 11, 2025 at 08:15:48PM +0300, Marius Vlad wrote: > On Thu, Sep 11, 2025 at 04:50:59PM +0300, Dmitry Baryshkov wrote: > > On Thu, Sep 11, 2025 at 04:07:34PM +0300, Marius Vlad wrote: > > > From: Andri Yngvason <an...@yngvason.is> > > > > > > Adds a new general DRM property named "color format" which can be used by > > > userspace to force the display driver 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 the formats which 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. > > > > It's unclear, who should be combining this data: should it be the kernel > > or the userspace. > Userspace. I've went a bit into why that is in the cover letter. That > was a pain point in the previous versions raised by other folks. Drivers > are free to advertise whatever color formats their HW supports. To > filter what panel/display supports userspace would look at the EDID and do an > intersection with the ones with the driver. This not uncommon, userspace > already looks today at the EDID for color management / HDR purposes. There's > just too much for the kernel to handle and rather than offloading that > to the kernel, people suggested previously to let userspace handle that. > > > > From my POV deferring this to the userspace doesn't make sense: there > > will be different quirks for monitors / panels, e.g. the EDID wrongly > > advertising YUV or not advertising a knowlingly-working capability. > Yeah, for sure. There have been some folks also raising that and discussing > that a bit further in previous thread on similar topic: > https://lore.kernel.org/dri-devel/ty4pr01mb14432b688209b2aa416a9522898...@ty4pr01mb14432.jpnprd01.prod.outlook.com/ > > Note that people have added quirks into libdisplay-info library to > overcome these limitations. It is far more easier to that into a library > than in the kernel.
This forces everybody who wishes to use this property to use that library (or to duplicate the code, making it spread over different projects). > > I think to some extent 'Auto' can fill up this task. Drivers can perform > these checks on their own, including the ability to look at the EDID data. > Most likely some of them do that today and performs actions based on > that (all the Y420 checks for instance). > > > > > I think that the property should reflect the kernel view on the possible > > formats, which should be updated during get_modes() (or every time EDID > > is being read). > The property advertises the supported color formats by display driver. > Userspace just filters these out based on what the sink supports. This > could just a policy in the compositor / UI. There's nothing preventing > you to force push from those advertised formats. What is the expected behaviour if userspace asks for the colorspace which is supported by the driver but not by the display? > > > > And that's not to mention that there are enough use-cases where the > > connector doesn't have EDID at all. > Totally. But what would be the expectation in that case? Drivers can > still advertise 'Auto' if they'd like. I'm trying to point out that this complicates userspace: it is now required to handle EDID and non-EDID cases for no practical reason. For all other usecases it is enough to query available modes from the kernel. > > > > > > > > Signed-off-by: Werner Sembach <w...@tuxedocomputers.com> > > > Signed-off-by: Andri Yngvason <an...@yngvason.is> > > > Signed-off-by: Marius Vlad <marius.v...@collabora.com> > > > --- > > > drivers/gpu/drm/drm_atomic_helper.c | 5 + > > > drivers/gpu/drm/drm_atomic_uapi.c | 4 + > > > drivers/gpu/drm/drm_connector.c | 177 ++++++++++++++++++++++++++++ > > > include/drm/drm_connector.h | 54 ++++++++- > > > 4 files changed, 235 insertions(+), 5 deletions(-) > > > > > > > -- > > With best wishes > > Dmitry -- With best wishes Dmitry
