Draft: migrate color mgmt from AMD driver specific properties to new KMS color API#2113
Open
melissawen wants to merge 15 commits intoValveSoftware:masterfrom
Open
Draft: migrate color mgmt from AMD driver specific properties to new KMS color API#2113melissawen wants to merge 15 commits intoValveSoftware:masterfrom
melissawen wants to merge 15 commits intoValveSoftware:masterfrom
Conversation
Signed-off-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
melissawen
force-pushed
the
kms_color_v2
branch
from
652925d to
d1e4e71
Compare
Signed-off-by: Melissa Wen <mwen@igalia.com>
Store the value of the color pipeline enum for a given plane that fits color pipeline needs. So that we can set plane COLOR_PIPELINE property with this value. Signed-off-by: Melissa Wen <mwen@igalia.com>
Check if there is any color pipeline with the properties needed for plane color mgmt. Signed-off-by: Melissa Wen <mwen@igalia.com>
Add CURVE_1D_TYPE property to colorop, helper for degamma curve using DRM_COLOROP_* predefined curve instead of AMD_TRANSFER_FUNCTIONs, add set degamma 1D curve accordingly Signed-off-by: Melissa Wen <mwen@igalia.com>
Create helper to use DRM_COLOROP curves instead of AMD_TRANSFER_FUNCTIONs and set properties accordingly Signed-off-by: Melissa Wen <mwen@igalia.com>
Create a helper to translate output tf of AMD_TRANSFER_FUNCTION enum type to DRM_COLOROP type Signed-off-by: Melissa Wen <mwen@igalia.com>
Gamescope already use 3x4 matrix, so doesn't needed additional helper. Signed-off-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
Instead of struct drm_color_lut, shaper and 3D LUTs follow struct drm_color_lut32, which means 32-bit for each channel, not 16-bit anymore. Create a helper to make possible reuse LUTs already created for AMD driver-specific color properties. Assisted-by: Claude Code <Sonnet 4.6> Signed-off-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
melissawen
force-pushed
the
kms_color_v2
branch
from
d1e4e71 to
1a56328
Compare
|
@melissawen feel free to just squash this into one of your existing commits or replace it with your own version, but I was getting what appeared to be a "deep-fried" image when testing this on Steam Deck OLED with a kernel built from the branch you linked plus the fixes that have been sent out on amd-gfx while compositing an image. it looked like color management was being applied twice even though scanout was fine. this fixed the issue on my end after digging into why it was only occurring with the color pipeline path: matte-schwartz@e097b54 |
Author
|
Hi @matte-schwartz, thanks for testing and debugging. I'll add your commit to this branch. Indeed, your fix is aligned with the AMD driver-specific-prop path. |
Match the existing behavior of the legacy AMD plane properties, which reset layers to DEFAULT without color management applied to them. Otherwise, stale color pipeline state from the previous scanout frame persists during composition, resulting in double color management and an overly-saturated output image. Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Collaborator
|
Thanks a lot for pushing this forward! I won't have time to review sadly. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With the new KMS color API for plane color mgmt, we can replace most of AMD driver-specific color properties by plane color pipeline and its colorops, except CRTC regamma TF [1] and color_range/color_encoding (bypass on kernel) [2]. As libliftoff doesn't support the colorop objs yet, I'm not sure if what I did is acceptable: to program colorops only after libliftoff has mapped layers-planes. Besides those comments, I'd like to mention that I used Claude code to debug a problem with blobs and figure out that shaper and 3D LUTs use a larger LUT struct with 32-bits per channel (drm_color_lut32 instead of drm_color_lut) and to create a helper that maps uint16 to uint32 values when creating LUTs for a given colorspace.
My main goal is validating and exercising KMS colorop code.
This branch is based on @emersion work at: #1309
Lemme know your thoughts.
[1] custom kernel that still exposes regamma TF: https://gitlab.freedesktop.org/mwen/drm-misc/-/commit/428cc3331d678d8e6ce6de5322a8be62ca2ff08b
[2] https://gitlab.freedesktop.org/agd5f/linux/-/commit/e0edb5809f1ec477b7b969200dc89bc171944ad4