On Mon, Feb 26, 2018 at 06:04:37PM +0200, Ville Syrjälä wrote: > On Mon, Feb 26, 2018 at 03:59:21PM +0000, Alexandru Gheorghe wrote: > > This is an attempt to revive the color space conversation that started > > here [1] and was materialized with the color encoding and color range > > properties for converting YUV2RGB, the last version of this patch > > series is here [2]. > > > > However, we still need a way of specifing the color gamut and transfer > > function(gamma) for a given plane, in order to be sure that the > > blending is done in the same domain space, which is not an issue for > > similar gammuts, but not so good when mixing wider gamuts like Rec2020 > > and DCI-P3 with narrow ones. > > > > In consequence, the userspace needs to control what is the color gamut > > used for blending. > > > > On Mali DP hardware, a complete color processing pipeline for a plane > > looks like this: > > > > YUV2RGB -> DEGAMA -> RGB2RGB(Gammut conv) -> GAMMA. > > > > Of course, depending on hardware generation some of this elements are > > not present or disabled if we are dealing with a RGB buffer already > > in linear space. But it's up to the usperspace to decide what it wants > > when the hardware doesn't provide full support for its needs. > > > > What this patchset proposes is to add plane degamma, ctm and gamma > > properties to be applied in this order after the yuv2rgb conversion > > specified by the color encoding property[2]. We already have this sort > > of pipeline(degamma, ctm, gamma) at the other end of a CRTC, so it > > wouldn't be a totaly new interface for userspaces to figure it out how > > to use. > > > > There are still some things to be done before getting this patchset in > > mergeable shape like: mali-dp driver implementation, real userspace > > (drm_hwcomposer is the likely candidate here, but I'm open to > > suggestions here), reuse some of the code for both crtc and plane. > > > > But first, I would like to see what everybody things about this idea, > > or if it has a different perspective of how this should be handled. > > > > [1] https://lkml.org/lkml/2017/3/16/681 > > [2] https://www.spinics.net/lists/intel-gfx/msg156211.html > > How is this related to eg. > https://patchwork.freedesktop.org/series/30876/ ? I wasn't aware of this patchset. Thanks. Same idea, almost identical implementation, I suppose it's true that some topics pop-up periodically. @Uma, is there an updated patchset anywhere that I missed. > > > > > Mihail Atanassov (1): > > drm: Add per-plane color management > > > > drivers/gpu/drm/drm_atomic.c | 28 ++++++++++++++ > > drivers/gpu/drm/drm_atomic_helper.c | 9 +++++ > > drivers/gpu/drm/drm_color_mgmt.c | 76 +++++++++++++++++++++++++++---------- > > include/drm/drm_color_mgmt.h | 5 +++ > > include/drm/drm_mode_config.h | 20 +++++----- > > include/drm/drm_plane.h | 8 ++++ > > 6 files changed, 117 insertions(+), 29 deletions(-) > > > > -- > > 2.7.4 > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Ville Syrjälä > Intel OTC > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
