Skip to content

Exclude software-dimming overlay windows from screen capture#1877

Open
cgchiroyasu-dev wants to merge 2 commits into
MonitorControl:mainfrom
cgchiroyasu-dev:fix/exclude-dimming-overlay-from-screen-capture
Open

Exclude software-dimming overlay windows from screen capture#1877
cgchiroyasu-dev wants to merge 2 commits into
MonitorControl:mainfrom
cgchiroyasu-dev:fix/exclude-dimming-overlay-from-screen-capture

Conversation

@cgchiroyasu-dev

Copy link
Copy Markdown

Problem

When a display is dimmed using software dimming (the black "shade" overlay), screenshots and screen recordings of that display come out darkened — the capture includes the dimming overlay. This is most visible on displays that have no DDC and no gamma support, such as DisplayLink / virtual displays, where the shade overlay is the only dimming mechanism available.

Reported in:

Root cause

DisplayManager.createShadeOnDisplay(...) creates a full‑screen black NSWindow to act as the dimming shade, but never sets its sharingType. The default is .readOnly, so the shade window is visible to the screen‑capture system (CGWindowList / ScreenCaptureKit). Any screenshot or recording taken while a display is dimmed therefore captures the shade and looks dark. The same applies to the 1×1 gammaActivityEnforcer helper window.

Fix

Set sharingType = .none on the shade windows and the gamma activity enforcer. These windows are display‑only chrome; excluding them from capture does not change what the user sees on screen — the display stays visibly dimmed, but captures are taken from the content underneath.

shade.sharingType = .none
self.gammaActivityEnforcer.sharingType = .none

Verification (macOS 15, DisplayLink displays)

Enumerated MonitorControl's on‑screen windows via CGWindowListCopyWindowInfo and read kCGWindowSharingState:

Window Before (main) After (this PR)
Window Shade for Display (full‑screen) 1 (ReadOnly → captured) 0 (None → excluded)
Gamma Activity Enforcer 1 (captured) 0 (excluded)

With the fix, the dimmed display still looks dimmed to the eye, but screencapture of that display no longer includes the shade — screenshots come out at normal brightness. An isolated test window with sharingType = .none confirmed it is excluded from capture (content behind shows through) rather than rendered black.

No behavior change for users who don't use software dimming.

For displays without DDC or gamma support (e.g. DisplayLink / virtual
displays), MonitorControl dims via a full-screen black 'shade' NSWindow.
Because the shade window's sharingType defaults to .readOnly, it is
captured by screenshots and screen recordings, so any capture taken
while a display is dimmed comes out darkened (see discussions MonitorControl#1453,
MonitorControl#866, MonitorControl#1446).

Set sharingType = .none on the shade windows and the gamma activity
enforcer so they no longer appear in screen captures. This is
display-only chrome; excluding it from capture does not change what the
user sees on screen.
Virtual displays (AirPlay/Sidecar/DisplayLink) are themselves presented
to the physical monitor via screen capture. Setting sharingType=.none on
their shade would remove the dimming from the actual monitor, not just
from screenshots. Guard the opt-out with !isVirtual so DisplayLink etc.
keep dimming, while real displays using shade (e.g. Mac mini HDMI) still
get screenshot-clean dimming.
@cgchiroyasu-dev

Copy link
Copy Markdown
Author

Revised: limited the sharingType = .none opt-out to non-virtual displays. On virtual displays (AirPlay / Sidecar / DisplayLink) the OS composites the display itself through screen capture, so excluding the shade from capture also removes the dimming from the physical monitor. Real displays using shade dimming (e.g. Mac mini HDMI / blacklisted) still benefit; virtual displays keep their existing behavior.

@waydabber waydabber added the AI contribution / fork recommendation Unplanned PR (typically AI) with improvements which may be of interest to the community label Jun 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI contribution / fork recommendation Unplanned PR (typically AI) with improvements which may be of interest to the community

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants