Repository navigation
drm/apple: Derive an EDID for T6041 external displays - #530
Closed
RyanTheTide wants to merge 1 commit into
Closed
RyanTheTide wants to merge 1 commit into
RyanTheTide wants to merge 1 commit into
Conversation
The external display processors of the M4 Pro/Max (apple,t6041-dcpext, desktop 26.6 IOMFB) announce no dcpav-service-epic, so the EDID read through the DCPAV service never runs and every connector they drive has an empty EDID. Userspace then names the monitor "Unknown". The firmware still exports the TimingElements and DisplayAttributes of each sink it drives, including the sink's ProductAttributes. Build the base EDID block from them as the T8140 (H17P) external path already does: enable the firmware metadata for the desktop external processors, check the property extent and parse the sink identity from DisplayAttributes, and read the IsPreferred, IsInterlaced, SyncPolarity and PixelRepetition keys of each timing so the preferred timing can be described. The published modes keep their flags; only the EDID's detailed timing takes the polarity. These processors have no cable generation of their own (their HDMI output has no Type-C session), so count sinks instead: the first is the one found at boot, and each cable attach or detach, Type-C route change or HDMI unplug starts a new one, which an earlier sink's metadata can never match. A firmware HPD loss alone does not drop it, as the link can bounce without the sink being described again. The H17P external, the other DCPs and the internal panels are unchanged. The firmware 27 path of t6050/dcp gets its EDID through the DCPAV service and its display product query only identifies an Apple display, so there was nothing there to port to 26.6. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
This was referenced Oct 28, 2026
Contributor
Author
|
Landed in integration/aurora through #533 (J616s consolidation, 2026-10-28). |
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.
The M4 Pro/Max external display processors (t6041 dcpext, desktop 26.6) have no DCPAV service, so every external connector they drive had an empty EDID and GNOME showed the monitor as "Unknown".
This builds the base EDID block from the firmware's TimingElements and DisplayAttributes, the same way the T8140 (H17P) external path already does. The sink count stands in for a cable generation, since these processors have none of their own. The H17P external, the other DCPs and the internal panels are unchanged.
Testing
🤖 Generated with Claude Code