Turning off an external monitor does not necessarily disconnect it from macOS. If the cable, dock, or monitor electronics keep the display connection alive, WindowServer can continue composing an extended desktop that no human can see.
That was the state of an EIZO EV3285 connected to a base M4 Mac. The panel was off, while the monitor still supplied power and exposed its USB hub. macOS reported the display as online, with a 4096 × 2304 backing resolution and a 2048 × 1152 user interface at 60 Hz.
Tool and install: mextdisplay is open source and available from the marianposaceanu Homebrew tap:
brew tap marianposaceanu/tap
brew install mextdisplay
mextdisplay
A controlled comparison found roughly 100 to 150 MiB of additional unified-memory pressure while that desktop was enabled. WindowServer's CPU reading rose by about eight percentage points in this single run. Those are A/B deltas, not direct per-display counters, and the CPU result is much noisier than the memory result.
The panel was off, the desktop was alive
A monitor has several states that are easy to collapse into one word: off. Its LCD or backlight can be off while the USB-C controller, DisplayPort link, USB hub, and power-delivery controller remain active. Some monitors and docks continue advertising the display path because disconnecting the whole device would also interrupt charging or USB peripherals.
macOS does not see the physical front of the monitor. It sees the connection state reported through the display stack. If that state still says that a display is online, an extended desktop remains a legitimate configuration. Windows can still occupy that coordinate space and WindowServer still has a surface to compose.
In that state, the pointer can disappear toward the dark monitor and application windows can reopen outside the visible built-in display.
Proving that macOS still had the display
The direct check was system_profiler, not the panel's power light:
system_profiler SPDisplaysDataType
With the external desktop enabled, the relevant block was:
EV3285:
Resolution: 4096 x 2304
UI Looks like: 2048 x 1152 @ 60.00Hz
Mirror: Off
Online: Yes
Rotation: Supported
The key field is Online: Yes. The physical panel state did not change the logical display state that macOS was using.
After disabling the video output, system_profiler listed only the built-in Liquid Retina display. The external monitor, charger, and USB devices remained physically connected, but the extended desktop no longer existed inside the login session.
Why automatic detection is not trustworthy
The first idea was to detect that the monitor was off and remove it automatically. The display protocol does not provide a reliable generic distinction for this topology. From macOS's point of view, the enabled panel and the dark panel presented the same useful fact: a connected display endpoint was still available.
Monitor-specific DDC/CI queries can sometimes report a power mode, but that is not a universal Apple display contract. Support varies by monitor, adapter, dock, transport, and security boundary. A transient failed query would also be a dangerous reason to rearrange desktops and move windows.
A generic tool can know whether macOS considers a display online. It cannot safely infer that a physically dark panel should always be removed from the desktop.
The resulting policy is deliberately manual. The user chooses which external video output to disable. That is less magical, but it does not guess whether a sleeping, switched-input, or temporarily dark monitor is unwanted.
Separating video from USB-C power and data
Disconnecting the cable solved the desktop problem and created two new ones: the Mac stopped charging and the monitor's USB hub disappeared. Display settings needed to change without treating the complete USB-C connection as disposable.
CoreGraphics already models display configuration separately from USB and power delivery. Removing the display from the current session does not issue a command to power off the monitor or detach the USB device. On this EV3285 setup, disabling only the macOS display output preserved both charging and the hub.
That result depends on hardware topology. A display tool cannot guarantee how every monitor, dock, cable, and firmware combination will route power and data. It can only avoid changing those subsystems itself.
Rolling a small display manager
The result became mextdisplay, a small open-source Rust program for Apple Silicon Macs. It provides a Ratatui interface for interactive use and ordinary subcommands for scripts.
mextdisplay # open the TUI
mextdisplay list
mextdisplay disable EV3285
mextdisplay enable EV3285
The TUI lists display name, enabled state, role, numeric ID, short UUID, resolution, and hardware identifiers. Arrow keys or j/k move the selection; Enter or Space toggles it; r refreshes; q quits. Disabling requires confirmation.
Command-line selectors can be a full UUID, an unambiguous UUID prefix, a numeric display ID, or an unambiguous part of the display name. off and on are aliases for disable and enable.
The private CoreGraphics boundary
Display discovery is mostly conventional. CGGetOnlineDisplayList supplies display IDs; CoreGraphics supplies pixel dimensions, vendor and model numbers, built-in state, the main-display ID, and a stable UUID; AppKit supplies the human-readable NSScreen.localizedName.
The public Quartz Display Services configuration API can change modes, origins, mirroring, and the main display. It does not expose the session-level enabled toggle needed here. mextdisplay therefore resolves the private CoreGraphics symbol CGSConfigureDisplayEnabled with dlsym.
The change is wrapped in a normal CoreGraphics configuration transaction:
- begin a display configuration;
- stage the enabled or disabled state;
- commit it for the current login session;
- poll CoreGraphics and verify that the expected display disappeared or returned.
The private call is the compatibility risk. The program checks that the symbol exists before making a change and reports an error if a future macOS release removes it. This is not an App Store API and it should not be presented as one.
Making disable reversible
Disabling worked immediately. Enabling exposed the harder design problem: once the display is disabled, it disappears from the normal online-display enumeration that supplied its ID.
Before making the change, mextdisplay atomically stores the stable display UUID, current numeric ID, name, and hardware identity in the current user's Application Support directory. The disabled record is tied to both the boot-session UUID and the macOS audit-session ID. A saved numeric ID is therefore eligible for recovery only inside the boot and login session that created it.
When enabling, the tool uses that session-local ID, waits for the display to return, and verifies that the returning ID still maps to the saved UUID. If the ID belongs to a different device, recovery stops rather than enabling the wrong output.
Several guardrails avoid the obvious self-inflicted failures:
- the built-in display cannot be disabled;
- the main display cannot be disabled;
- the final active display cannot be disabled;
- a failed disable is rolled back when possible;
- logging out or restarting restores the ordinary session configuration.
This recovery path is why the tool does more than call one private function. The toggle is a line of code; proving which display can be toggled back is the feature.
What macOS can actually measure
macOS does not publish a counter named "memory used by display 2" or "GPU watts for the EV3285." Apple silicon also has unified memory rather than separate CPU RAM and dedicated VRAM. The CPU, GPU, WindowServer, applications, and display surfaces can participate in overlapping accounting views of the same physical memory.
The useful approach is therefore differential:
- measure the machine with the external desktop disabled;
- enable only that desktop and leave the workload otherwise unchanged;
- measure again after the display configuration settles;
- disable it and take a second off-state measurement;
- compare the on median with the average of the two off medians.
Three local counters were available without administrator privileges:
- AGX
In use system memoryfrom the accelerator'sPerformanceStatisticsdictionary inioreg; - WindowServer RSS from
psand resident size fromtop; - WindowServer's process CPU percentage from
ps.
These remain whole-process or whole-GPU counters. The display's cost is inferred from the controlled delta, not directly attributed by macOS.
The M4 test setup
| Property | Test value |
|---|---|
| Mac model identifier | Mac16,12 |
| SoC | Base Apple M4, 10-core GPU |
| Unified memory | 16 GiB |
| Operating system | macOS 26.6.2, build 25G83 |
| Built-in display | 2560 × 1664, active and main throughout |
| External monitor | EIZO EV3285 |
| External backing mode | 4096 × 2304 |
| External UI mode | Looks like 2048 × 1152 at 60 Hz |
| Mirroring | Off |
The external monitor's panel remained physically off. The same applications stayed open during the run. This was an idle desktop comparison, not a scrolling, video, game, or animation benchmark.
An OFF-ON-OFF experiment
The external desktop was already disabled when the test began. Ten samples were taken approximately one second apart. mextdisplay then enabled the EV3285, the system was given eight seconds to settle, and ten more samples were taken. The display was disabled again, followed by another eight-second pause and ten final samples.
OFF before: 10 samples
enable EV3285
settle: 8 seconds
ON: 10 samples
disable EV3285
settle: 8 seconds
OFF after: 10 samples
A shell trap called mextdisplay disable EV3285 on exit, interruption, or error. The final explicit state check confirmed that the EV3285 was disabled and the built-in display remained enabled and main.
The two off measurements matter because the machine was not perfectly stationary. AGX's first off series contained values from 314.3 to 497.3 MiB, while the final off series was quieter at 288.6 to 322.6 MiB. Using only one endpoint would have made the result depend too heavily on when the benchmark happened to start.
The measured deltas
Each table entry is the median of ten samples, with the observed range in parentheses.
| State | AGX memory | WindowServer RSS | WindowServer resident size | WindowServer CPU |
|---|---|---|---|---|
| Off before | 335.4 MiB (314.3–497.3) | 154.0 MiB (154.0–154.0) | 640.0 MiB (639.0–679.0) | 21.2% (14.7–27.6) |
| On | 469.5 MiB (461.2–866.6) | 254.5 MiB (253.9–256.6) | 730.0 MiB (722.0–769.0) | 27.4% (20.2–33.2) |
| Off after | 310.5 MiB (288.6–322.6) | 157.3 MiB (157.1–157.5) | 600.5 MiB (599.0–602.0) | 16.6% (7.8–22.0) |
The on state minus the average of the two off medians produced:
| Counter | Measured change |
|---|---|
| AGX in-use system memory | +146.6 MiB |
WindowServer RSS from ps | +98.8 MiB |
WindowServer resident size from top | +109.8 MiB |
| WindowServer CPU | +8.4 percentage points |
The measurement summary is available as CSV.
The framebuffer explains the scale
The reported external backing mode contains 9,437,184 pixels:
At four bytes per pixel, one full uncompressed 32-bit surface is exactly 37,748,736 bytes, or 36 MiB:
Two such buffers require 72 MiB; three require 108 MiB. That simple lower-bound arithmetic lands close to WindowServer's observed 99 to 110 MiB increase.
This agreement is useful but not a proof that the measured delta consists of exactly three framebuffers. WindowServer and Core Animation also manage window surfaces, composition intermediates, cursor and color resources, scaled output, and IOSurface allocations. Some resources can be compressed, shared, reused, or charged elsewhere. The calculation explains why an approximately 100 MiB result is plausible.
Multiplying 36 MiB by 60 frames per second would describe more than 2 GiB/s of full-surface traffic, but that is not a measured GPU bandwidth requirement. Desktop composition can reuse unchanged surfaces, update damaged regions, and use dedicated display hardware. Framebuffer size is a capacity calculation, not an energy or bandwidth measurement.
CPU and GPU interpretation
WindowServer rose from an average off median of 18.9% CPU to 27.4% while the external desktop was present. The resulting 8.4-point delta is the least stable headline number in the test. Process CPU percentage is sensitive to desktop changes, application redraws, sampling windows, and ordinary user activity. The off endpoints themselves differed by 4.6 points.
The correct reading is not that every scaled external monitor consumes exactly 8.4% of one core. This one run showed a visible WindowServer cost. Repeated tests, longer sampling windows, a static desktop, and a second order such as ON-OFF-ON would be needed for a stronger CPU estimate.
The AGX registry also exposed Device Utilization %, Renderer Utilization %, and Tiler Utilization %. Idle snapshots frequently read zero even while the display remained active. They were too instantaneous and coarse to serve as a reliable per-display utilization measurement.
The 146.6 MiB AGX delta is more useful. It says that the GPU-facing memory view moved materially when the display was enabled. It does not say that all 146.6 MiB belongs uniquely to scanout, nor does it distinguish compositor surfaces from application GPU resources that became visible on the restored desktop.
Measuring GPU power with administrator access
This first experiment stayed non-root, so it did not produce a GPU wattage number. The installed macOS release exposes a gpu_power sampler through powermetrics, but the tool requires administrator privileges.
A controlled power pass can use the same display sequence:
display=EV3285
trap 'mextdisplay disable "$display" >/dev/null 2>&1 || true' EXIT INT TERM
mextdisplay disable "$display"
sleep 10
sudo powermetrics \
--samplers gpu_power \
--sample-rate 1000 \
--sample-count 30 \
--output-file "$HOME/Desktop/mext-gpu-off.txt"
mextdisplay enable "$display"
sleep 10
sudo powermetrics \
--samplers gpu_power \
--sample-rate 1000 \
--sample-count 30 \
--output-file "$HOME/Desktop/mext-gpu-on.txt"
The useful fields vary by macOS and SoC, but generally include GPU active residency, frequency distribution, and estimated GPU power. Compare medians from the two files rather than one sample.
powermetrics explicitly describes its power values as estimates. They are suitable for comparing two configurations on the same Mac, close together in time. They are not laboratory-grade electrical measurements and may not cleanly assign display-controller, DRAM, fabric, or monitor-side power to the GPU rail.
A wall meter answers a different question: the electrical change for the complete monitor, hub, charger, and Mac system. In this topology the monitor supplies the Mac, so a wall reading would include USB-C conversion losses and monitor electronics even with the panel dark.
Reproducing the memory experiment
The AGX memory value can be read as a property-list field rather than parsed from the very large text form of ioreg:
ioreg -r -c AGXAccelerator -d 1 -a |
plutil -extract \
'0.PerformanceStatistics.In use system memory' \
raw -o - -
WindowServer's two memory views and CPU percentage came from:
pid="$(pgrep -x WindowServer)"
ps -p "$pid" -o rss=,%cpu=
top -l 1 -pid "$pid" -stats pid,rsize -ncols 120
For each state, collect ten or more one-second samples and use medians. Keep the built-in display, desktop contents, animation, brightness, open applications, and charger state unchanged. Wait after every display transition. An OFF-ON-OFF or ON-OFF-ON sequence is preferable to a single before-and-after pair because it exposes drift.
Always preserve the original display state. For an experiment that begins with the external display disabled, a shell trap is enough:
trap 'mextdisplay disable EV3285 >/dev/null 2>&1 || true' EXIT INT TERM
Do not use kill -9 WindowServer as a measurement technique. It terminates the graphical session, can lose unsaved work, and changes far more than the display under test.
The useful answer
The original question was binary: if the external monitor is off, is macOS still rendering an extra desktop? On this setup, yes. system_profiler reported the EV3285 online at a 4096 × 2304 backing mode even though its panel was dark.
The second question was whether that hidden desktop could be removed while retaining power and USB. On this hardware, yes. A session-level CoreGraphics display toggle removed it without detaching the USB-C connection. Automatic physical-panel detection was not reliable enough to control that toggle, so mextdisplay makes the decision explicit.
The final question was cost. The best non-root A/B estimate was approximately 100 to 150 MiB of incremental unified-memory pressure. WindowServer CPU also moved upward, but that single-run delta needs more repetition before it deserves a universal number. Exact GPU watts remain a separate privileged experiment.
The dark panel was not evidence that the desktop had gone away. The operating system's display list was the source of truth, and the OFF-ON-OFF delta was the closest available measure of what that invisible desktop cost.
Sources
- External-display A/B measurement summary, collected on the tested
Mac16,12. - EIZO FlexScan EV3285 official product page and product image.
- mextdisplay source, README, safety checks, and CoreGraphics implementation.
- Homebrew tap containing the mextdisplay formula.
- Ratatui documentation.
- Apple Quartz Display Services Programming Topics: Overview.
- Apple Developer Documentation: Quartz Display Services.
- macOS manual page for
powermetrics(1). - macOS manual page for
ioreg(8). - macOS manual page for
system_profiler(8).
The private CGSConfigureDisplayEnabled function is documented here by the open-source implementation that used it, not by Apple. Its presence and behavior can change in future macOS releases.