Repository navigation
drm/apple: start and light the Neo's internal panel from the resume, as macOS does - #1631
Merged
Merged
Conversation
When the panel was off by DPMS before a sleep, as it is when KWin blanks the outputs for it, the DCP firmware stays stopped through the resume. It starts only when KWin turns the output on again after the thaw: on the Neo that is 0.57 s into the wake, and the warm restart then runs inside the modeset. macOS doesn't wait for that. In both wakes of the recording with the display in use, the display domains go on 78-82 ms into the wake, DCP's HELLO comes 0.5 ms later and its first display call about 10 ms after that, which by its timing comes from the kernel's power path, not WindowServer. Frames follow from about 0.3 s. Start the firmware from the DCP's resume on a work item, so it comes up while the other devices resume, and leave the panel dark. That is the state a refused idle leaves: the firmware running and the display off. DPMS on, DPMS off and the next sleep already handle it, and they now wait for the start first. DPMS on then only sends set_power_state(1) and waits for the scanout DART, as on a refused idle. If DPMS on doesn't come within wake_prewarm_ms (10 s), the firmware stops again as DPMS off stops it, so a closed lid or a session that keeps the output off ends up as before. A dark wake doesn't start it. wake_prewarm_ms=0 keeps the old behaviour. Signed-off-by: Diljit Singh <hey@djdev.me>
With the firmware started from the resume (the previous patch), the panel itself still waits for KWin's DPMS on, 0.57 s into a wake on the Neo. macOS doesn't wait for WindowServer there either: about 10 ms after DCP's HELLO, 90 ms into the wake, its power path sends the display-on calls, A414(0), A478 twice, A476(1) (the clamshell state), A478, A412 and set_power_state(1), and frames follow from about 0.3 s. Its backlight comes on after the first frame. On a full wake with the lid open, do the same from the resume work: after the warm restart, send those calls and wait for D572, as DPMS on would. The panel is then powered with its backlight at the DPMS-off level, 0. When KWin turns the output on, DPMS on finds the panel already on and leaves only the mode set and the first frame to the commit. That frame carries the backlight level from before the sleep, as DPMS on already brings it back. If DPMS on doesn't come within wake_prewarm_ms, set_power_state(0) and the firmware stop turn it off again, and a sleep before then does the same. The backlight's own present reuses the retained scanout, and after a sleep that's the frame from before it, which needn't be what KWin shows next: the session may lock as it resumes. Hold that present after a wake until KWin's first frame, which then carries the level, so nothing from before the sleep is shown. The log says when the old frame would have been reused, also with wake_light=0. The lid comes from the SMC: its noirq resume now reads MSLD on every wake, not only on a wake for the lid alone, and the sleep driver keeps it for the display. With the lid read closed, the firmware and panel stay off, as macOS keeps the internal display off with the lid closed. A dark wake lights nothing, as before. A lid that couldn't be read gives the previous patch's behaviour. wake_light=0 gives the previous patch's behaviour, and wake_prewarm_ms=0 the behaviour before both. Signed-off-by: Diljit Singh <hey@djdev.me>
DjDeveloperr
marked this pull request as ready for review
November 12, 2026 04:39
This was referenced Nov 12, 2026
Merged
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.
On a wake from a DRAM-kept sleep, the Neo (J700) starts the internal display only when KWin turns the output back on after the thaw. macOS powers the DCP about 80 ms after the wake, from its kernel. These two commits start the internal DCP's firmware from the resume and, on a full wake with the lid open, light the panel from the resume too. The backlight still comes with KWin's first frame.
Everything below was measured on the Neo, including real lid wakes.
Commits (on integration
2b05915f, #1445 merged)21b2d172drm/apple: start the internal display's firmware from the resumeset_power_state(1).wake_prewarm_ms(default 10000).wake_prewarm_ms=0restores today's behaviour.b5989a04drm/apple: light the internal panel from the resume, as macOS doeswake_light=0gives the first commit alone.Measured on the Neo (J700), 2026-11-11
The patched kernel was booted from the SSD. Both arms ran on one boot, interleaved: A is
wake_prewarm_ms=0(today), C is the defaults. Times are seconds after the PMU RTC alarm, medians of 12 wakes, on the ARM generic counter.no D572, display power-on, firmware start or crash line in any arm.Lid wakes (2026-11-11 23:37, patched kernel, defaults)
The owner closed and opened the Neo's lid, and the panel came back each time and looked fine. The Neo's log has six lid cycles from 23:37:34 to 23:37:58, each with logind's "Lid closed." and "Lid opened.", 1-3 s apart. All six were DRAM-kept sleeps, woken by the lid (SMC wake record
MBSW 00 04 ...: lid, wake source the MTP DockChannel or the SMC outbox), and all returned.wake: panel on in 56 ms (firmware 1 ms), dark until the first framefrom the resume;DPMS on: panel already on, 213-215 ms after the resume lit it;wake: first new frame, backlight back with it.Details:
migration/neo-continuation-20261108/dcp-wake-macos/README.md(macOS's order from the recording, and the design) andRESULT.md(this A/B).🤖 Generated with Claude Code