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. While using degamma for gamma sounds a bit illogical, but thinking of it as: pregamma -> ctm -> postgamma sounds fine. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
