drm: re-send HDR metadata blob on modeset#250
Merged
Conversation
After a VT switch or sleep/resume, the kernel discards all DRM property blobs. restoreAfterVT() rebuilds the atomic commit with the in-memory HDR metadata, but prepareConnector() skips blob creation because STATE.committed (the "what changed" bitmask) was cleared after the last pre-sleep commit. During a modeset the kernel state is fully reset, so all properties must be re-sent regardless of the committed flags. Add a data.modeset guard to bypass the committed check, matching how max_bpc, colorspace, and VRR are already handled unconditionally. The existing has_value() check prevents false positives: non-HDR modesets (resolution changes etc.) don't populate data.hdrMetadata, so the block is still skipped.
vaxerski
approved these changes
Feb 17, 2026
vaxerski
pushed a commit
that referenced
this pull request
May 10, 2026
A previous compositor (kwin etc.) can leave HDR, gamma, degamma and CTM properties set on a connector when it exits. Aquamarine only re-emitted these on user commits, so anything we don't actively manage stayed at the previous compositor's value, manifesting as washed-out colors or shifted saturation when starting Hyprland after kwin. HDR (#250) and CTM-with-non-identity (#256) were already covered. Extend the modeset path to also: - re-send gamma_lut/degamma_lut on modeset; an empty STATE.gammaLut produces a zero blob, which clears the kernel state. only ride this path when the prop actually exists, otherwise we'd log a spurious "no gamma_lut prop" error on every modeset for connectors without programmable gamma. - re-send CTM unconditionally on modeset, identity included, so the kernel always replaces a stale matrix with our current one. the blob builder produces a real identity matrix when STATE.ctm == Mat3x3(), so we never send blob_id=0 (which #256 documented as problematic). Fixes #127. Co-authored-by: j4kuuu <j4kuuu>
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
2 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.
After sleep/resume, the kernel discards all DRM property blobs including
HDR_OUTPUT_METADATA.restoreAfterVT()correctly copies the in-memory HDR metadata into the commit data, butprepareConnector()skips blob creation becauseSTATE.committedwas cleared byonCommit()after the last pre-sleep commit.The monitor ends up with 10-bit format active but zero HDR metadata and colors wash out permanently until the color mode is changed to standard and back.
This adds a
data.modesetcheck to bypass the committed flag, since a modeset means the kernel state was fully reset and all properties need to be re-sent. Other connector properties (max_bpc,colorspace,content_type,vrr) have noSTATE.committedguard at all — they're sent every commit. HDR metadata was the only one gated behind the committed flag, making it uniquely vulnerable to state loss after suspend/resume. The existinghas_value()guard prevents false positives so non-HDR modesets don't populatedata.hdrMetadata.Tested on NVIDIA RTX 4090 with a HDR display.
Ref: hyprwm/Hyprland#13036