Skip to content

evdi: colour management follow-ups (damage, cursor, color_props) - #1

Open
onetr1ck wants to merge 3 commits into
iDoMeteor:add-crtc-color-managementfrom
onetr1ck:wip/color-mgmt-followups
Open

evdi: colour management follow-ups (damage, cursor, color_props)#1
onetr1ck wants to merge 3 commits into
iDoMeteor:add-crtc-color-managementfrom
onetr1ck:wip/color-mgmt-followups

Conversation

@onetr1ck

@onetr1ck onetr1ck commented Aug 3, 2026

Copy link
Copy Markdown

Based on your software colour management branch. Three small follow-ups from testing DisplayLink with GNOME Night Light.

Colour updates now mark the full scanout dirty so a static desktop re-grabs after GAMMA_LUT or CTM changes. The software cursor blend path applies the same transform as the primary copy. A color_props module parameter (both, gamma, or ctm) can limit which DRM properties are advertised when comparing compositor paths.

Happy for you to take these into the upstream PR as-is, or drop any piece you do not want. No change to the core apply path beyond wiring.

Colour is applied only while copying dirty rects for GRABPIX. A
compositor can update GAMMA_LUT or CTM without repainting, so force a
full-frame dirty on color_mgmt_changed and let the existing update-ready
path re-grab.
When cursor events are disabled the cursor is alpha-blended from the
untinted GEM into the grab buffer after the primary copy. Apply the
same CTM/gamma to the composed pixel so Night Light matches the
desktop under the pointer.
Advertise both colour properties by default. color_props=gamma or
color_props=ctm limits what the CRTC exposes so a compositor can be
forced onto one Night Light path for testing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant