[PATCH 4/7] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix

[Daniel Stone]

Hi,

On Tue, 22 Sep 2020 at 08:44, Tomi Valkeinen <tomi.valkeinen at 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