All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Cc: nd@arm.com, airlied@linux.ie, liviu.dudau@arm.com,
	dri-devel@lists.freedesktop.org, mihail.atanassov@arm.com
Subject: Re: [RFC 0/1] Color space conversion uapi part2
Date: Mon, 26 Feb 2018 18:04:37 +0200	[thread overview]
Message-ID: <20180226160437.GV5453@intel.com> (raw)
In-Reply-To: <1519660762-16981-1-git-send-email-alexandru-cosmin.gheorghe@arm.com>

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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2018-02-26 16:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26 15:59 [RFC 0/1] Color space conversion uapi part2 Alexandru Gheorghe
2018-02-26 15:59 ` [PATCH 1/1] [RFC] drm: Add per-plane color management Alexandru Gheorghe
2018-02-26 16:04 ` Ville Syrjälä [this message]
2018-02-26 16:48   ` [RFC 0/1] Color space conversion uapi part2 Alexandru-Cosmin Gheorghe
2018-02-27  8:25     ` Shankar, Uma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180226160437.GV5453@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=alexandru-cosmin.gheorghe@arm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=liviu.dudau@arm.com \
    --cc=mihail.atanassov@arm.com \
    --cc=nd@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.