[GehrmannSolutions]

Follow-up to #114 / #103, as suggested in #103: the lid-closed dual-display set on top of the merged J613 dcpext series.

What

On the J613 (MacBook Air 13" M3) with the lid open, one external display runs on dcpext and a second one waits (the log line and takeover from #114). macOS does more with the lid closed: the panel is off, so the internal DCP's pipe drives a second external display on the left-front USB-C port (IOMFBIntDcpUsedForExtWhenLidClose). This series does the same:

• Patch 1 (drm/apple): a typec-routes container with no enabled route no longer takes the internal panel down, for every DCP except the external ones. A route that fails to register on the panel's DCP is disabled, and the panel goes on without it; so is the route of a panel DCP whose probe fails for good, so the left-front port never waits for it. Needed because patch 2 adds a route that stays disabled when the gate does not enable dcpext.
• Patch 2 (DT): the internal DCP gets a disabled Type-C route to the left-front port: ATC1's DP PHY and crossbar, crossbar state 0 (dispext0,0, from the J613 ADT), DPTX target 1, and a second endpoint on the front connector.
• Patch 3 (display gate): enables that route in the same changeset as dcpext, under the same checks and the same boot-loader marker, with one more log line. No dcpext, no route.
• Patch 4 (drm/apple): follows the lid like macOS: tells the panel's IOMFB the lid state (A475), powers the panel off on close (A472), and reports eDP-1 disconnected while the lid is closed (also when booting closed, so the panel is never lit). Lid changes run from a freezable work item, so after a wake by opening the lid they apply only once DRM has restored its state. Only a lid switch with a parent device counts (not a uinput clone). Without this, the firmware takes the pipe for an external display at every panel power-on and the next swap times out.
• Patch 5 (drm/apple): with the lid closed and the panel and its CRTC off, the internal pipe counts as a free pipeline for the left-front port. The DPTX/DPAV endpoints are started as on the external processors, the link is connected as on dcpext, and the 14.7 session handles the description, mode set and swaps of a Type-C display. When the lid opens, the display gives the pipe back first, then takes dcpext if it is free, or waits with the usual log line.
• Patch 6 (drm/apple): moves the left-front display from dcpext to the internal pipe only when a left-back display needs dcpext: a display plugged into the left-back port with the lid closed, the lid closing while a left-back display waits, and boot with the lid closed. A display that takes over a pipeline it waited for logs the display on USB-C Left-front takes over this pipeline.

Other machines and a J613 without the new route (no marker, apple_t8122_display.dcpext=0, older DT) are unchanged. Like #114, the series needs the boot loader to set apple,t8122-dcpext-firmware-ready (the m1n1 half in #103).

Tested

Kernel: this branch on integration/aurora 54f78d60c. W=1 build of every commit with no new warnings in drm/apple and soc/apple (the review fixes: compile-checked per commit, full W=1 build of the head); checkpatch clean apart from the trailers. DTB built from this branch, m1n1 with the marker. Test setup: a 3440x1440 monitor (through its USB-C hub) on the left-back port, a 1080p portable on the left-front port, and Hyprland.

• Lid open: each port alone; second display waits with the log line and desktop hint; takeover both ways when the active display is unplugged (about 3 s). ✅
• Lid close with both displays: panel off at once, left-front display moves to the internal pipe (about 2.5 s), left-back display stays on dcpext. Lid open: panel back, the left-front display waits again. ✅
• Lid closed: unplug and replug either display, each comes back on its pipe without waiting. ✅
• Boot with the lid closed: panel never powered, both external displays lit (internal pipe after about 12 s). ✅
• Suspend with the lid closed, wake by opening the lid: panel back, both external displays restored, then the left-front display gives the pipe back and waits as with the lid open, the left-back display keeps dcpext. 2 of 2 runs with the review fixes, with no Failed to resume any more. Before the fixes (same branch): 2 runs, see the notes below.
• Five lid-open s2idle cycles in a day of normal use on this branch (before the review fixes), all resumed cleanly.

Review

I ran a Claude Code review over the series (GehrmannSolutions#2). Fixed in the patches they belong to: the lid work could run during resume, before DRM restored its state, which made drm_mode_config_helper_resume fail with -22 for every CRTC (that was the error we had taken as harmless); the lid-close black frame could race a commit's swap over which framebuffer is on screen; a Type-C display on the internal pipe had the panel's framebuffer-size rule instead of the external one; a failing panel-DCP probe left the route enabled; any SW_LID device (also uinput) set the lid state; a refused panel power-on was only logged at info level. Left for a follow-up: phys/mux-controls sit on the static dcp node even while the route is disabled (fw_devlink then makes the panel wait for phy-apple-atc, which is loaded on J613 anyway for USB), and some duplicated route helpers in dcp-fabric.c.

Known, not changed here

• After a resume, whichever display is ready first gets dcpext (seen once before the fixes). A monitor whose own hub is still asleep can lose dcpext to the other display, which then runs while the first one waits. Unplugging the running display hands dcpext over as usual.
• Seen once on this branch, after a lid-closed resume: the firmware described the left-back monitor through DCPDPService instead of DCPDP13Service, without link training, with a short TimingElements (48 kB instead of 281 kB) and no usable mode. The driver rejected it (failed to parse modes) and the firmware dropped the display. After that dcpext could not light it again, even after a replug (the link went down in the middle of the mode set), until a reboot. The same run on the series before the rebase passed right after. That resume also ran into the -22 restore failure fixed above, so the dcpext display was not restored by DRM and was set up again from scratch; that may well have been the trigger. Not seen since the fix (2 runs), and I collect the rejected description if it happens again.
• No USB wake from s2idle on this machine (xhci wakeup disabled), so a closed laptop wakes only by opening the lid.
• Userspace: Omarchy suspends on lid close as soon as the external display count is zero for a moment, which can happen during the move to the internal pipe (Lid closed with external displays: logind suspends as soon as the display count drops to zero for a moment omarchy#15368). We run a small user service that suspends a closed laptop only after ten seconds without an external display.

(Code, tests and this text by TARS, my Claude Code agent, with me plugging displays and reviewing; Signed-off-by is mine.)

🤖 Generated with Claude Code

https://claude.ai/code/session_017YMqWu7A3VwEYtHaA1TusK

[GehrmannSolutions]

Rebased onto current integration/aurora (bed544b, the tree packaged as linux-aurora 7.2.11.aurora16) and retested on a J613. New head: 268800455b3b; checkpatch is clean apart from the Co-Authored-By trailer warnings.

Result: a J613 with the lid closed drives two external displays.

• T34w-30 at 3440×1440 runs on dcpext, Left-back.
• M14 at 1920×1080 runs on the internal pipe, Left-front.

lid closed, panel off: the internal pipe drives the display on USB-C Left-front
the display on USB-C Left-front takes over this pipeline
internal pipe: Type-C display mode "1920x1080": 60 148500 …

With the lid open, aurora16's "waits for a free external display pipeline" behaviour is unchanged: the second display waits, and it lights up when the first is unplugged.

Rebase notes:

• 4/6 (lid): resolved against drm/apple: M3 Pro GPU memory leak fix: release replaced framebuffers on 14.7 firmware #325's retained-framebuffer release in iomfb_v14_7_flush(). While the panel is dark, the early return now also calls dcp_release_all_retained_framebuffers(). Nothing reads them with the panel powered off, so they don't pile up while a compositor keeps the internal CRTC on with the lid closed.
• 5/6 (internal pipe): adapted to the new dcp_v14_plane_fits_mode() / dcp_v14_plane_scanout_size() helpers. The internal pipe passes external || typec.
• 5/6: dropped the extra dcp_enable_typec_work() in dcp_clamshell_start(). Since the bind now enables the Type-C work for the internal v14.7 DCP too, the second call tripped workqueue: work disable count underflowed.
• Dropped the drm/apple: M3 Pro GPU memory leak fix: release replaced framebuffers on 14.7 firmware #325 cherry-pick and an unrelated local thermal patch; drm/apple: M3 Pro GPU memory leak fix: release replaced framebuffers on 14.7 firmware #325 is upstream now.

Ordering matters for the DT patch (2/6). I booted the packaged aurora16 kernel once with this series' t8122-j613.dtb. Without 1/6, apple-dcp rejects the internal DCP (Type-C route container is empty, probe -22), and the panel falls back to simple-framebuffer. So 2/6 must not land or ship ahead of 1/6.

The J613 test used a localmodconfig build of the series as an extra Limine entry. The boot.bin was rebuilt once with the series' DTB and restored to the packaged one afterwards.

Disclosure: the rebase, the analysis and this text were made with an AI coding agent (Claude Code). The test ran on my J613, and I checked both displays with the lid closed.