[WIP/RFC] Improve buffer data space handling v2
This series aims to be the userspace reference for Uma Shankar's PLANE_DEGAMMA, PLANE_CTM, PLANE_GAMMA properties sent here 1.
What 1 proposes is using something similar with the already existing crtc properties DEGAMMA_LUT, CTM, GAMMA_LUT, but attach them to the drm_plane. This transformations will be applied before composition.
Android-O defines buffer dataspace as a bitmask of Range, Transfer and Standard More details about the exact meaning of each bitfield could be found here 2.
Looking at the KMS API we have just a partial way of passing this information to the driver:
-
FOR YUV buffers we should use COLOR_RANGE and COLOR_ENCODING properties which have been already merged to mainline. That's what the bellow commit does, it is not properly tested, but I think it should be here as part of the conversation.
- 50fda03 drm_hwcomposer: Put YCbCr encoding in the atomic commit
-
For RGB we should use the PLANE_DEGAMMA, PLANE_CTM, PLANE_GAMMA properties.
Now, although android-o defines a lot of dataspaces, looking at surfaceflinger GLRender the only case that is handled differently is when one of the buffer is in HAL_DATASPACE_DISPLAY_P3. In this case setColorMode will be called with HAL_COLOR_MODE_DISPLAY_P3 and all other buffers need to be converted to HAL_DATASPACE_DISPLAY_P3, before composition.
So, for now, I just added support for handling composition in HAL_DATASPACE_DISPLAY_P3 when the buffer is in sRGB, what that means is that we have to apply the following transformations:
- PLANE_DEGAMMA (to_linear)
- PLANE_CTM (CSC BT709 to DCI_P3)
- PLANE_GAMMA (to_non_linear)
Now, this is not properly tested(It's not unrun :), but far from mergebility), because of missing content and a hardware that support all three matrix transforms for a plane, but I'm hoping to overcame this for the future series.
For now, please feel free to rip it apart.
[1] https://www.spinics.net/lists/dri-devel/msg168609.html.
Dependencies: !16 (closed)