All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: per-plane LUTs and CSCs?
Date: Thu, 10 Sep 2020 14:38:55 +0300	[thread overview]
Message-ID: <20200910113855.GX6112@intel.com> (raw)
In-Reply-To: <20200910081836.GG438822@phenom.ffwll.local>

On Thu, Sep 10, 2020 at 10:18:36AM +0200, Daniel Vetter wrote:
> On Thu, Sep 10, 2020 at 07:50:59AM +0000, Simon Ser wrote:
> > On Wednesday, September 9, 2020 12:57 PM, Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> wrote:
> > 
> > > Hi all,
> > >
> > > I was wondering whether you could give me an advise on how to proceed further
> > > with the following issue as I'm preparing to upstream the next set of patches
> > > for the iMX8MQ display controller(DCSS). The display controller has 3 planes,
> > > each with 2 CSCs and one degamma LUT. The CSCs are in front and after the LUT
> > > respectively. Then the output from those 3 pipes is blended together and then
> > > gamma correction is applied using a linear-to-nonlinear LUT and another CSC, if
> > > needed.
> > >
> > > Currently, downstream, we have all those CSCs and LUTs hard-coded into a header
> > > file. Based on the colorspace, range, gamut selected for the output and/or
> > > plane input, we pick up the right CSCs and LUTs from that header file to
> > > configure our pipes... I guess this solution does the job, userspace doesn't
> > > need to care much about how to generate those tables. But, it's also not very
> > > flexible in case there is an app smart enough to know and actually generate
> > > their own custom tables. :/
> > >
> > > Looking through the dri-devel archives, I've seen that there was a tentative to
> > > implement a more or less generic per-plane LUT/CSC solution but it didn't make
> > > it in due to lack of userspace consumers...
> > 
> > Apart from full color management mentioned by Pekka, are there other
> > use-cases for these per-plane props?
> > 
> > One thing I can think of is that some drivers annoyingly only apply the
> > per-CRTC gamma LUT to the primary plane. I think it would make more
> > sense to not attach a gamma prop to the CRTC and instead only attach it
> > to the primary plane to make that clear. But I guess that would also
> > break existing user-space?
> 
> Uh, which drivers? This would be a driver bug (and there's been plenty of
> those where the cursor has the wrong color temp and fun stuff like that).
> We need to fix these driver issues instead of lamenting in userspace that
> it's all kinda broken :-)

Quite a bit of old hardware simpy couldn't apply the gamma to the
other planes. But hopefully that is no longer the case for any
modern hardware.

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

      parent reply	other threads:[~2020-09-10 11:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09 10:57 per-plane LUTs and CSCs? Laurentiu Palcu
2020-09-10  7:25 ` Pekka Paalanen
2020-09-10  7:52   ` Daniel Vetter
2020-09-10  8:50     ` Pekka Paalanen
2020-09-10  9:30       ` Laurentiu Palcu
2020-09-10 10:28         ` Pekka Paalanen
2020-09-10 10:39           ` Laurentiu Palcu
2020-09-10 10:56           ` Laurent Pinchart
2020-09-10 17:09             ` Vitaly Prosyak
2020-09-10 17:51               ` Laurent Pinchart
2020-09-10 18:07                 ` Vitaly Prosyak
2020-09-10 19:39                   ` Vitaly Prosyak
2020-09-11 12:57                     ` Pekka Paalanen
2020-09-10 10:53       ` Laurent Pinchart
2020-09-10  7:50 ` Simon Ser
2020-09-10  8:18   ` Daniel Vetter
2020-09-10  8:29     ` Simon Ser
2020-09-14  6:13       ` Alex Deucher
2020-09-14 13:32         ` Ville Syrjälä
2020-09-14 14:38           ` Alex Deucher
2020-09-14 15:07             ` Ville Syrjälä
2020-09-10 11:38     ` Ville Syrjälä [this message]

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=20200910113855.GX6112@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=laurentiu.palcu@oss.nxp.com \
    --cc=sam@ravnborg.org \
    /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.