DisplayCapabilities

struct DisplayCapabilities

Declared in Sources/PrismCore/Probe/DisplayCapabilities.swift · PrismCore 3.5.4

What the display this session plays to can actually present.

Phase 4's groundwork made HDR/DV readiness two caller-supplied booleans, with a deliberate false default — an over-claiming manifest is rejected outright (-11868 / -11848) rather than degraded, so "don't know" had to mean "don't claim". This type is the read that replaces the guess.

Why this is a readiness question, not a capability one

displayIsHDRReady documents itself as "is in, or will switch into, the source's dynamic range" — which is what makes tvOS's Match Content the happy path: the panel is SDR-parked right up until playback starts, then follows the content. So the honest read is what the display supports, not what it is showing this instant, and that is exactly what AVPlayer.availableHDRModes reports.

The gap that survives: a tvOS panel that supports HDR with Match Content off stays SDR-parked, accepts nothing PQ, and fails the item with -11848. No API distinguishes that from the Match-Content case, which is precisely why MasterRejection exists — the read is the optimistic half, the rejection fallback is the half that catches it being wrong.

Initializers

init(isHDRReady:isDolbyVisionCapable:panelIsCurrentlyHDR:source:)source

init(isHDRReady: Bool, isDolbyVisionCapable: Bool, panelIsCurrentlyHDR: Bool? = nil, source: Source = .caller)

No documentation comment in the source.

Instance properties

isHDRReady source

let isHDRReady: Bool

Whether an HDR (PQ / HLG) variant may be offered.

isDolbyVisionCapable source

let isDolbyVisionCapable: Bool

Whether Dolby Vision may be claimed on top of it.

panelIsCurrentlyHDR source

let panelIsCurrentlyHDR: Bool?

Whether the panel is presenting HDR right now — true when the EDR headroom is raised at read time, nil when there was nothing to ask.

Only the true is load-bearing: a panel already out of SDR takes an HDR master no matter what the capability read said, so this rescues the session whose availableHDRModes read failed (.conservative) while the panel demonstrably runs HDR. false proves nothing — the headroom is raised around a dynamic-range transition and decays back to 1.0 while the panel keeps presenting HDR — so false never subtracts from isHDRReady. DisplayCriteriaController.currentPanelIsHDR() is the post-handshake read a host feeds back in here for its next session.

source source

let source: Source

No documentation comment in the source.

offersHDR source

var offersHDR: Bool { get }

The routing question: may this session offer an HDR variant at all? Capability is the optimistic read; a panel currently presenting HDR is the certain one.

Type properties

conservative source

static let conservative: DisplayCapabilities

Everything off — what a session gets when nobody asked and nothing could be read. Keeps v0's media-direct shape for HDR sources.

Type methods

current()source

@MainActor static func current() -> DisplayCapabilities

Read the current display.

@MainActor because both underlying reads are: NSScreen.main is main-thread-only, and availableHDRModes reflects UIKit's current screen state. A session is created from the host's playback code, which is already on the main actor, so this costs nothing in practice.

Enumeration

DisplayCapabilities.Source

enum Source

Where the values came from — surfaced because a .unavailable read and a genuinely-SDR display produce identical booleans, and only the first one is worth logging when a host wonders why it never sees HDR.