Repository navigation
drm/apple: Keep sink primaries as reported in firmware-derived EDIDs - #561
Merged
Merged
Conversation
An MSI MPG 325CQRXF on the second external processor of the M4 Pro came up with an empty EDID: no monitor name and no HDR capability in userspace. Its DisplayAttributes report the red primary as x 0.6904, y 0.3203, the 10-bit values 707 and 328 of its own EDID. Their sum is above 1, and the parser refused any chromaticity whose coordinates sum above 1, so the whole of DisplayAttributes was dropped and no EDID was built. Primaries are the sink's description of itself, and real EDIDs carry such values. Pass them on as reported. The EDID builder still requires each coordinate to be representable, the primaries to span a triangle and the white point to lie inside it; the white point, which the gamma belongs to, must still be a chromaticity. The same sink reports its luminance without a minimum. Read a missing minimum as 0 and a missing frame-average maximum as the maximum, rather than dropping the luminance range. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Contributor
Author
|
Hardware check on the J616s (fleet4 + this commit as a test module): DP-2 (MSI MPG 325CQRXF, Type-C on the second external processor) now logs |
This was referenced Oct 29, 2026
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.
A second external display on the J616s (an MSI MPG 325CQRXF, Type-C to Type-C on the second external processor, DP-2) came up with a 0-byte EDID. GNOME showed no monitor name and saw none of its HDR or colour data, while the dock Acer on DP-1 had its 256-byte firmware-derived EDID.
Cause. The firmware-derived EDID path (from #530 and #553) works the same on both external processors. On DP-2 the parser rejected the sink's DisplayAttributes outright. The MSI reports its red primary as x 0.6904, y 0.3203. Those are the 10-bit values 707 and 328 from its own EDID, and they sum to more than 1. The parser refused any chromaticity summing above 1, so the whole dictionary was dropped and nothing was built. Feeding the captured DisplayAttributes blob through the host-selftest parser reproduces it:
parse_display_metadata()returns-EINVALat Chromaticity.Fix.
Min. A missing minimum now reads as 0 and a missing frame-average as the maximum, instead of the whole range being dropped (which would have lost its HDR block luminance).Tests.
Minluminance. It checks that the primaries survive into the EDID as 707/328 and that min is 0. The rejected-chromaticity case moves to the white point.🤖 Generated with Claude Code