Re: [RFC 0/1] Color space conversion uapi part2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/ ?

> 
> 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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux