Repository navigation
fix(utils): fix GetHDREnabled fallback check that mistakes WCG for HDR - #728
Open
SERGEYDJUM wants to merge 1 commit into
Open
SERGEYDJUM wants to merge 1 commit into
SERGEYDJUM wants to merge 1 commit into
Conversation
This branch has not been deployed
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
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.
On old Windows builds, the
GetHDREnabledfunction relies on the value of theadvancedColorEnabledflag inDISPLAYCONFIG_GET_ADVANCED_COLOR_INFOstruct as a fallback. When user toggles HDR off (with a Win + Alt + B shortcut), some (possibly most) displays start to output wide gamut SDR that still counts as advanced color and the flag stays enabled. Meaning,advancedColorEnabledcannot reliably discriminate between HDR and not-HDR.One of my own projects relies on an HDR check adapted from
GetHDREnabled. I received a report from a Windows 11 23H2 user that encountered an issue that stems from the problem above.After some tests, I learned that another flag (
wideColorEnforced) does change when toggling HDR. Meaning,advancedColorEnabled && !wideColorEnforcedcan act as an indicator of HDR. I cannot say that the new fallback is reliable, but it's arguably better.