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. 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. > > 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. > > > > > 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
signature.asc
Description: PGP signature
