[RFC 0/1] Color space conversion uapi part2

Mon Feb 26 16:48:04 UTC 2018

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 at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel