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