Repository navigation
Conversation
A DP2HDMI output asserts its own HPD in dcp_enable_dp2hdmi_hpd(), and its firmware does not send the link-configuration notification that dcp_dptx_connect() waits for, so on that path the wait can only time out and the display is withdrawn before it is ever lit. Continue as the late-HPD case already does instead of failing the connect. The existing `compact` case tolerates the same timeout, but it covers the 26.x firmware's compact endpoints, not a 13.x DP2HDMI output. Seen on a Mac mini (t8112, G14, DP2HDMI out): the DCP boots, reports "DP2HDMI HPD connected:1" and 32 modes, then dcp_dptx_connect: timed out waiting for port 0 link configuration display HPD removed ... set_device_enabled_gated: requested state: 0 and the machine registers a DRM device with no output. With this change the same machine sets the mode and stays up: set_digital_out_mode(...) "3440x1440": 100 ... 3440 ... 1440 ... set_digital_out_mode finished:7866 Tested on that machine only (M2 mini, t8112, firmware-compat 13.x); the T6030/T8122/H17P paths and the compact 26.x path are untouched, and dcp_is_typec_output() keeps Type-C connects where they are. Signed-off-by: twobip <github@twobip.com> Assisted-by: LLM
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.
drm/apple: keep a DP2HDMI connect when no link configuration arrives
On a Mac mini (t8112, G14) with a DP2HDMI output,
appledrmnever gets thedisplay up: the DCP boots and reads the sink's modes, HPD is asserted, and then
dcp_dptx_connect()times out waiting for a link-configuration notificationthat this firmware does not send. The timeout is treated as fatal, so the
connect is withdrawn and the machine ends up with a registered DRM device and
no output.
Note that
dcp_dptx_connect()already tolerates this timeout twice, for thecompact26.x endpoints and for the late-HPD case; this adds the third case itwas missing, a 13.x DP2HDMI output.
A DP2HDMI output asserts its own HPD in
dcp_enable_dp2hdmi_hpd(), so on thatpath the link-configuration wait can only time out; the driver already has the
"proceed without the notification" behaviour for the late-HPD case
(
dcp_ext_dptx_607()). This extends it to DP2HDMI outputs, identified by havingthe HPD GPIO and not being a Type-C output, so Type-C connects keep their
existing path.
With the change, the same machine sets a mode and stays up:
and the compositor reports
HDMI-A-1 3440x1440 @ 100.Scope
apple,firmware-compat13.x — the pre-26.x firmware line, so this is unrelated to the desktop 26.x /
T6041 work in drm/apple: T6041 (M4 Pro/Max) displays on desktop 26.6 firmware (carries #445) #446.
late_hpdanddcp_ext_dptx_607()behave exactly as before, anddcp_is_typec_output()keeps Type-C outputs out of the new branch.
unchanged in
integration/auroraas of99dac994,t8112-dcpextstill fallsthrough to the generic
apple,dcpextdata, and the recent "desktop" commitsare about 26.x firmware and T6040/T6041, not this path.
It would be worth a second opinion on the predicate from someone who knows why
T8122 asserts HPD after the wait — if another property identifies "this
firmware never notifies" more precisely, that would be a better condition than
the HPD GPIO and the Type-C check.