Repository navigation
Conversation
HDMI 2.1 sinks may declare only one extension block in the base EDID and carry the real extension count in an HDMI Forum EDID Extension Override Data Block (HF-EEODB) at the start of the first CTA-861 extension. DCP returns all blocks, but dcpavserv_copy_edid() trusts only the base block's count, so the size check fails, every hotplug logs "copy_edid failed: -EIO" and the connector ends up without an EDID. Honour HF-EEODB before the size check. drm_edid already handles HF-EEODB once the EDID is allocated. Log the sizes if a mismatch remains. Seen with a Samsung Odyssey G7 G75F (5120x2160) on the J414c HDMI port: DCP reports 520 bytes (8-byte header plus 4 blocks), the base block declares 1 extension, HF-EEODB declares 3. Signed-off-by: Radovan Skolnik <[email protected]> Co-authored-by: Claude Opus 5.5 <[email protected]>
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.
HDMI 2.1 sinks may declare only one extension block in the base EDID and carry the real extension count in an HDMI Forum EDID Extension Override Data Block (HF-EEODB) at the start of the first CTA-861 extension. DCP returns all blocks, but
dcpavserv_copy_edid()trusts only the base block's count, so its size check fails, every hotplug logscopy_edid failed: -EIO, and the connector's EDID stays empty. Userspace then can't identify the monitor; modes still work because DCP parses the EDID itself.This honours HF-EEODB before the size check.
drm_edidalready handles HF-EEODB once the EDID is allocated. A remaining mismatch now logs the sizes.Tested on MacBook Pro 14" M2 Max (J414c), built-in HDMI port, DCP firmware 13.5, with a Samsung Odyssey G7 G75F (5120x2160) on HDMI:
used_size = 520(8-byte header + 4 blocks); base block byte 0x7E = 1; first CTA block starts withe2 78 03(HF-EEODB, 3 extensions) →-EIOon every hotplug.edidsysfs file is 512 bytes, byte-identical to what DCP returned;edid-decodereports base + 2× CTA-861 + DisplayID 2.0 with no failures; KWin identifies the monitor.Built out of tree against Ubuntu's 7.2.0-1001-asahi-arm, whose copy of this file is identical to
asahiat a7c69b6.Unrelated, not changed here: the
afk_service_call()in this function passessizeof(resp) + EDID_BUF_SIZE(pointer size) as the reply buffer length wheresizeof(*resp)looks intended. It's harmless for EDID-sized replies.