Skip to content

drm/apple: Keep sink primaries as reported in firmware-derived EDIDs - #561

Merged
RyanTheTide merged 1 commit into
integration/aurorafrom
edid/sink-primaries
Oct 29, 2026
Merged

RyanTheTide merged 1 commit into
integration/aurorafrom
edid/sink-primaries

Conversation

@RyanTheTide

Copy link
Copy Markdown
Contributor

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 -EINVAL at Chromaticity.

Fix.

  • Primaries are passed on as the sink reports them, as a real EDID would carry them. The builder still requires each coordinate to be representable, the primaries to form a triangle and the white point to lie inside it. The white point, which the gamma belongs to, must still sum to 1 or less. The MSI's primaries pass those checks.
  • The same sink reports Luminance without 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.

  • apple-dcp host selftests: 80/80. The rate fixture gains a sink with the MSI's red primary and no Min luminance. 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.
  • The captured MSI DisplayAttributes now parse.
  • Hardware check on the J616s with the MSI on DP-2: pending a slot. The module builds cleanly against the fleet4 kernel.

🤖 Generated with Claude Code

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>
@RyanTheTide

Copy link
Copy Markdown
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 using firmware-derived EDID metadata, its EDID is 256 bytes (name MPG 325CQRXF, serial DC1H514A00211, primaries 0.6904/0.3203 red as the sink reports them, HDR block), GNOME names it Microstep 32" and offers bt2100; 2560x1440@280 and 280+vrr are listed; HDR at 280 Hz applies as PQ BT.2020 YCbCr 4:4:4 (element 124) with no flip failures. DP-1 (Acer) and the internal panel are unchanged. Machine restored to stock afterwards.

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