All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jyri Sarha <jsarha@ti.com>
Cc: Liviu.Dudau@arm.com, dri-devel@lists.freedesktop.org,
	tomi.valkeinen@ti.com, laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
Date: Mon, 24 Apr 2017 19:55:01 +0300	[thread overview]
Message-ID: <20170424165501.GB30290@intel.com> (raw)
In-Reply-To: <1a0ed660-89ff-3883-c2a2-cd15f490c591@ti.com>

On Mon, Apr 24, 2017 at 06:49:04PM +0300, Jyri Sarha wrote:
> On 04/24/17 18:13, Ville Syrjälä wrote:
> >> What about the uapi structs? In the patch there is an explicit struct
> >> naming each coefficient for what they are for in YCbCr to RGB
> >> conversion. Is this Ok, or should we go with a generic (CTM style)
> >> matrix, that could be used for RGB to YCbCr conversion too?
> > Not sure what we're talking about here, but like I said I think we
> > should stick to a fairly limited set of standard props and just have
> > each driver map the hardware resources to them as best they can.
> > 
> 
> Just about the implementation detail, if we should have a separate uapi
> struct for YCbCr to RGB CSC and RGB to YCbCr CSC. If we are going to use
> the same struct, then we could as well use the already existing CTM struct.
> 
> > If you just have csc+(de)gamma then I guess it might make sense
> > to just expose the YCbCr->RGB and degamma. If you have
> > degamma+csc+gamma then it might make sense to expose both
> > YCbCr->RGB, degamma, CTM, and gamma, and just refuse any
> > combination that can't be done. Eg. can't do YCbCr->RGB if
> > degamma is used, and YCbCr->RGB + CTM would require multiplying
> > the matrices together which you may or may not want to bother
> > with, I guess we could try to put some matrix math helpers into
> > the core to make such things less painful for drivers?
> 
> In fact we have plane specific YCbCr to RGB CSC (only preoffset
> possible), then (per crtc) gamma table, and finally a (per crtc) RGB to
> YCbCr CSC with optional post offset (so it can be used either as CSC or
> CTM).

So with that plane hw you could perhaps do:
- YCbCr->RGB if you input is not linear, but then you must
  blend using non-linear data
- colorspace conversion if your input is alredy linear

And with your crtc hw you could do:
- degamma + CTM
- gamma + RGB->YCbCr

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

  reply	other threads:[~2017-04-24 16:55 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21  9:51 [PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion Jyri Sarha
2017-04-21  9:51 ` [PATCH RFC 1/6] drm: drm_color_mgmt.h needs struct drm_crtc declaration Jyri Sarha
2017-04-21 11:46   ` Laurent Pinchart
2017-04-21  9:51 ` [PATCH RFC 2/6] drm: Make drm_atomic_replace_property_blob_from_id() more generic Jyri Sarha
2017-04-21 11:47   ` Laurent Pinchart
2017-05-02  8:31     ` Daniel Vetter
2017-04-21  9:51 ` [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties Jyri Sarha
2017-04-21 11:17   ` Ville Syrjälä
2017-04-21 12:10     ` Laurent Pinchart
2017-04-21 13:08       ` Ville Syrjälä
2017-04-21 12:58     ` Sharma, Shashank
2017-04-21 13:39     ` Jyri Sarha
2017-04-21 13:52       ` Ville Syrjälä
2017-04-21 14:53         ` Brian Starkey
2017-04-21 15:21           ` Ville Syrjälä
2017-04-21 15:34             ` Brian Starkey
2017-04-21 16:49               ` Ville Syrjälä
2017-04-24 12:58                 ` Brian Starkey
2017-04-24  9:02         ` [PATCH] RFC: Design: DRM: Blending pipeline using DRM plane properties Shashank Sharma
2017-04-24 13:21         ` [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties Jyri Sarha
2017-04-24 15:13           ` Ville Syrjälä
2017-04-24 15:49             ` Jyri Sarha
2017-04-24 16:55               ` Ville Syrjälä [this message]
2017-04-26 12:56                 ` Jyri Sarha
2017-04-26 13:28                   ` Sharma, Shashank
2017-04-26 17:22                   ` Ville Syrjälä
2017-05-02  8:33   ` Daniel Vetter
2017-05-02  9:29     ` Jyri Sarha
2017-04-21  9:51 ` [PATCH RFC 4/6] drm/omap: cleanup color space conversion Jyri Sarha
2017-04-21 11:53   ` Laurent Pinchart
2017-04-21  9:51 ` [PATCH RFC 5/6] drm/omap: csc full range support Jyri Sarha
2017-04-21 11:55   ` Laurent Pinchart
2017-04-21  9:51 ` [PATCH RFC 6/6] drm/omap: Enable ycbcr_to_rgb_properties for omapdrm planes REVISIT Jyri Sarha
2017-04-21 12:53 ` [PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion Sharma, Shashank
2017-04-21 13:50 ` Liviu Dudau
2017-04-24  9:18 ` ✓ Fi.CI.BAT: success for RFC: Design: DRM: Blending pipeline using DRM plane properties Patchwork

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=20170424165501.GB30290@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jsarha@ti.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=tomi.valkeinen@ti.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.