All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Stone <daniel@fooishbar.org>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jyri Sarha <jsarha@ti.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 4/7] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix
Date: Tue, 22 Sep 2020 11:02:39 +0100	[thread overview]
Message-ID: <CAPj87rP9zmDV+nqLWX+zeSSOZ-kWKQgd9i3+D_J9PjOvaB=sQA@mail.gmail.com> (raw)
In-Reply-To: <b06e3c39-2a87-c5e0-0fdb-162eead5d36e@ti.com>

Hi,

On Tue, 22 Sep 2020 at 08:44, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 21/09/2020 14:49, Pekka Paalanen wrote:
> > would it not be simplest if KMS UAPI specification defined the abstract
> > color pipeline with all the blocks that may be exposed with
> > driver-agnostic UAPI, and then just say that if a block is not present,
> > it behaves as pass-through, a no-op?

Correct, that's the intention and also the result you get today. If
the documentation doesn't make that clear then it should be fixed.

> > Each block would be represented by standardised KMS properties, that
> > either exist or don't.
> >
> > I think that would be fairly easy for userspace to grasp, but I don't
> > know if the abstract model itself would be feasible considering all the
> > hardware out there.
> >
> > If we happened to be limited to
> >
> > FB -> plane-degamma -> plane-CTM -> plane-gamma -> (blending) ->
> > degamma -> CTM -> gamma -> encoder -> wire
> >
> > it would still be tractable.
> >
> > No funny business with new KMS properties changing how old KMS
> > properties behave. Old userspace understands and uses old KMS
> > properties but not new KMS properties, so it wouldn't even work.
>
> Isn't this how it's currently defined for the output side? So if I understand right, your suggestion
> means that a HW that has:
>
> gamma -> CTM -> out
>
> would map those to DRM's degamma and CTM, and the userspace should use degamma to do gamma? I'm ok
> with that, and it's probably more manageable than having properties which would describe the order
> of the blocks.
>
> While using degamma for gamma sounds a bit illogical, but thinking of it as:
>
> pregamma -> ctm -> postgamma
>
> sounds fine.

Totally. 'degamma' and 'gamma' are just normative from most uses,
they're not prescriptive, e.g. userspace can use the 'degamma' LUT to
do gamma whilst leaving the CTM and 'gamma' LUT disabled if it wants.

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-09-22 10:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-02 12:53 [PATCH 0/7] drm/omap: misc improvements Tomi Valkeinen
2019-09-02 12:53 ` [PATCH 1/7] drm/omap: drop unneeded locking from mgr_fld_write() Tomi Valkeinen
2019-09-03 14:14   ` Laurent Pinchart
2019-09-02 12:53 ` [PATCH 2/7] drm/omap: tweak HDMI DDC timings Tomi Valkeinen
2019-09-03 14:23   ` Laurent Pinchart
2019-09-26 12:54     ` Tomi Valkeinen
2019-09-26 14:40       ` Alejandro Hernandez
2019-09-02 12:53 ` [PATCH 3/7] drm/omap: fix missing scaler pixel fmt limitations Tomi Valkeinen
2019-09-03 15:12   ` Laurent Pinchart
2019-09-26 12:55     ` Tomi Valkeinen
2019-09-02 12:53 ` [PATCH 4/7] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix Tomi Valkeinen
2019-09-03 15:24   ` Laurent Pinchart
     [not found]     ` <b44372e2-1bb7-ddb8-d121-ae096b38d918@ti.com>
2019-09-04 11:11       ` Laurent Pinchart
2019-09-04 20:08         ` Jyri Sarha
2019-09-04 20:20           ` Ilia Mirkin
2020-09-21 11:08             ` Tomi Valkeinen
2020-09-21 11:49               ` Pekka Paalanen
2020-09-22  7:44                 ` Tomi Valkeinen
2020-09-22  9:48                   ` Pekka Paalanen
2020-09-22 10:02                   ` Daniel Stone [this message]
2019-09-04 21:52           ` Laurent Pinchart
2019-09-05 10:00             ` Jyri Sarha
2019-09-05 10:05               ` Laurent Pinchart
2019-09-05 13:48                 ` Jyri Sarha
2019-09-02 12:53 ` [PATCH 5/7] drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes Tomi Valkeinen
2019-09-03 15:32   ` Laurent Pinchart
2019-09-05  9:24     ` Jyri Sarha
2019-09-05  9:43       ` Laurent Pinchart
2019-09-02 12:53 ` [PATCH 6/7] drm/omap: dss: platform_register_drivers() to dss.c and remove core.c Tomi Valkeinen
2019-09-03 15:34   ` Laurent Pinchart
2019-09-04  6:47     ` Jyri Sarha
2019-09-02 12:53 ` [PATCH 7/7] drm/omap: hdmi5: automatically choose limited/full range output Tomi Valkeinen
2019-09-03 15:38   ` Laurent Pinchart

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='CAPj87rP9zmDV+nqLWX+zeSSOZ-kWKQgd9i3+D_J9PjOvaB=sQA@mail.gmail.com' \
    --to=daniel@fooishbar.org \
    --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.