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

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2600 bytes --]

On Tue, 22 Sep 2020 10:44:38 +0300
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?
> > 
> > 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.

Hi,

yes.

When I have been thinking about using the KMS pipeline elements for
Weston, I didn't take "degamma" or "gamma" literally. I just think of
them as arbitrary LUTs at specific points in the pipeline.

Legacy KMS UAPI implementation for drmModeSetGamma() ioctl or whatever
could use the same heuristic: look at all the pipeline blocks after the
blending step, set everything to identity except for the last (or
first? or largest?) LUT which is used as "the gamma LUT".

> While using degamma for gamma sounds a bit illogical, but thinking of it as:
> 
> pregamma -> ctm -> postgamma
> 
> sounds fine.

Indeed. Better naming for new blocks in the future, I hope. :-)

I think even "gamma" is a little too much meaning, they're just LUTs.
Not sure if 3x 1D vs. 3D LUTs should be different blocks in the
pipeline, depends if the UAPI can handle both kinds.

Having blending -> degamma -> CTM even implies incorrect pipeline,
because blending should happen in linear space while degamma is about
converting from non-linear space into linear space.



Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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