6.5.3 - A panel already in HDR is no longer read as SDR

Reported on an HDR10+ panel with the Apple TV output set to SDR and Match Dynamic Range on: a Dolby Vision Profile 8 title played correctly as HDR10 on the first start, and every replay before the TV had dropped back to SDR played as SDR while the TV itself visibly switched. Traced on device with a continuous panel sampler.

Fixed

• A session that starts on a panel already in HDR is no longer routed as SDR. UIScreen.currentEDRHeadroom is not a readout of the panel's HDMI mode. It is raised around a dynamic-range transition and decays back to 1.0 while the panel keeps presenting HDR: measured as a fall from 1.20 to 1.00 thirteen seconds into a confirmed HDR10 session, with isDisplayModeSwitchInProgress false throughout. A replay that begins before the TV has dropped back to SDR therefore makes no transition at all, so the headroom never rises and the single read taken after waitForSwitch concluded that the panel was SDR. On tvOS that one boolean is the whole master-vs-media routing gate, since builtInPanelEngagesOnDemand is false there, so the session was served media-direct with no HDR signaling and labelled SDR. The first start after the panel had settled back was a real transition and worked, which is why this presented as "only the second play is broken".

  The reading now counts only as a positive. Its absence is answered by what the display has already proven: once a criteria write has driven it into HDR, asking for HDR again puts it there. A panel that never engages, which is what Match Frame Rate on with Match Dynamic Range off looks like through the same combined tvOS toggle, never sets the proof and keeps the conservative answer, so it is still never offered a PQ master it would reject with -11848.

• The settle diagnostics stop accusing a panel that was already in HDR. Headroom 1.0 after an HDR write is not evidence of a refusal, because a panel that needed no transition reads identically to one that refused. Both the Stage 2 settle WARN and the cap line asserted a refusal for either, and on the trace above logged "panel stayed SDR despite HDR criteria" while the TV was reporting HDR. Both now consult the same proof; an unproven panel keeps the WARN and names the two real candidates.

Notes

The engage proof is deliberately never cleared, not by reset() and not by a switch that ends at headroom 1.0. The headroom is a transition artifact, so its absence proves nothing, and any invalidation rule built on it would re-arm the same false negative. The residual case, Match Dynamic Range switched off in Settings without the app being restarted, offers one master to an SDR panel and is recovered by the existing master-to-media fallback (#98) and the startup-readiness gate (#35).

Not addressed here: a replay onto a hot panel still costs two panel mode switches, one from the nil write at teardown and one from re-applying the same criteria, and the pre-flight then waits out its full cap for a transition that is not coming. That is startup latency, not correctness, and every candidate for shortening it trades against the Dolby Vision cold-start budget the wait exists for.

Compatibility

No API changes.