My M3 MacBook Air often fails to bring up my external monitor when I plug into my CalDigit dock. The monitor just stays dark, as if there’s no signal. Power-cycling the monitor brings it up every time. My M5 MacBook Pro, on the exact same dock, cable, and monitor, works 100% of the time.

From the desk it looks like the monitor simply won’t turn on. But system_profiler tells a more specific story: macOS has attached the display in a broken fallback state, and that failed handshake is why the panel never lights up. This is an EDID read race, and the failure leaves a distinctive fingerprint.

The Setup

• MacBook Air (M3) and, for comparison, a MacBook Pro (M5)
• CalDigit TS4 dock over a single Thunderbolt cable
• ASUS PG32UQ (32" 4K panel) connected to the dock’s DisplayPort output

The Tell: NOVATEK vs ASUS PG32UQ

When the screen stays dark, check what macOS thinks is attached:

system_profiler SPDisplaysDataType

In the failed state, the display shows up like this, latched to a fallback mode the panel never displays:

NOVATEK:
  Resolution: 1920 x 1080 (1080p FHD - Full High Definition)

After a power-cycle, the same monitor shows up correctly and the picture finally appears:

ASUS PG32UQ:
  Resolution: 5120 x 2880 (5K/UHD+ - Ultra High Definition Plus)
  UI Looks like: 2560 x 1440 @ 100.00Hz

NOVATEK is the scaler chip inside the ASUS panel, not a second device. When macOS can only read a generic, boot-time descriptor instead of the monitor’s real EDID, it has no product name to show and falls back to the chip vendor’s name. The dark screen (NOVATEK at 1080p behind it) and the working picture (ASUS PG32UQ at full resolution) are the same monitor in two states: a failed handshake versus a good one.

Why the Screen Stays Dark: an EDID Read Race

At connect time the Mac reads the monitor’s EDID to learn which resolutions and refresh rates it supports. If the panel isn’t fully awake at that instant, the scaler answers with a fallback descriptor. macOS latches onto it and drives a mode the panel won’t display, so the screen stays dark, and it caches that state until something forces a re-read.

Power-cycling the monitor while the Mac is already running gives it a clean second read: the panel is awake, hands over its real EDID, and macOS negotiates a mode that actually lights it up. You can watch the DisplayPort tunnel re-register in the log when this happens:

/usr/bin/log show --last 2m --predicate 'process == "WindowServer"'

Why the Air loses the race and the Pro doesn’t is the interesting part, and it gets its own section below.

Why the Air and Not the Pro

Both machines run the same macOS build (26.5.2), on the same dock, cable, and monitor. That rules out the operating system and every peripheral. The only variable left is the host silicon: something in how each Mac’s Thunderbolt and display hardware brings up the connection.

Here’s my best explanation, and it’s reasoning rather than something I can prove from the outside. The two machines have different Thunderbolt controller generations. The M3 Air has a Thunderbolt 4 / USB4 controller; the M5 Pro has Thunderbolt 5. Newer controllers tend to add debounce and EDID re-read retries to the hot-plug path, the kind of logic that covers for a sink that isn’t ready yet. Read that as a difference in tolerance, not speed: the Thunderbolt 5 path waits out a panel that answers late, while the older path on the Air commits to the first descriptor it reads. The base M3’s display engine is older silicon too, which likely compounds it.

If that holds, the real fix has to come from Apple, as a macOS update that teaches the older hardware path the same patience. Nothing on the dock or the monitor will change it, and updating the dock’s own firmware (I went from 39.1 to the current 45.1) didn’t touch the problem. Until then, the workarounds below are the answer.

A Side Issue: Check the Thunderbolt Cable

While diagnosing this I found the Mac-to-dock link negotiating at only 20 Gb/s instead of 40, because the cable in use wasn’t a certified Thunderbolt 4 / USB4 40 Gb cable:

system_profiler SPThunderboltDataType | grep -E 'Speed|Link Status'

Swapping to a proper 40 Gb cable brought the link to full speed. That did not fix the dark-screen problem (it’s a separate fault), but a solid 40 Gb link handshakes more reliably and is worth fixing regardless.

Workarounds

In rough order of effort:

1. Power-cycle the monitor after connecting. This is the manual fix and it works every time, but it’s annoying.
2. Wake the monitor before plugging in. Make sure it’s on and showing something before the Thunderbolt cable goes into the Mac. The race only bites when the panel is asleep at the moment of the read.
3. BetterDisplay. It detects the display connecting and re-applies your chosen resolution automatically, and can pin the correct EDID so the fallback never sticks. This is the closest thing to a set-and-forget fix.

If your external monitor won’t light up and you find it identified by its scaler chip’s name in system_profiler (NOVATEK, Realtek, MStar, and friends) instead of its real model, that’s your sign the EDID read failed rather than the cable or the display being at fault.