Repository navigation
HDR: the display's own peak by model, launcher rows for the peak and paper white, and the packed-conversion probe (stacked on seedds/nxnative#1176) - #9
Open
oliverames wants to merge 3 commits into
Conversation
Codex Review Summary: ❌ FailedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
added 3 commits
November 7, 2026 14:24
…er sets the peak and the paper white Symptom: a phone's highlights were reported as "super bright" and nothing in the launcher could change them; the game was told a fixed 1,000 nits (DM_HDR_PEAK, no launcher setting) on a panel that reaches 1,600. Fix: front_hdr_device_peak() (front_ios.m, by hardware model) supplies the default: 1,600 for the iPhone 12 Pro and later and the M-series iPad XDR panels, 1,200 for the iPhone X to 11, else 1,000. DM_HDR_PEAK overrides and 0 is automatic. The launcher gets HDR peak brightness and HDR paper white rows, shown once HDR output is on; both are untested at other values. Checked: t_present_hdr (31 checks, four new), the settings, launcher, env-switch and docs tests, and front_ios.m against the iPhoneOS SDK; the game told 1,600 nits ran on an iPhone 19,4 with Mario Kart World 1.8.0. Front-ends: interface: front_hdr_device_peak() in front.h, the display's peak in nits by hardware model (0 = unknown, answered 1,000); a front end that makes an HDR layer implements it, and a weak default answers 0
…e repository root
oliverames
force-pushed
the
hdr-calibration
branch
from
November 7, 2026 19:24
dc67952 to
1ef287d
Compare
1 of 3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Not fully tested.
What and why
Stacked on seedds#1176 (
maxdavidson:feat/switch2-hdr-output):mainhas no HDR presentation code, so this is meant to be merged into seedds#1176's branch, or rebased ontomainwhen seedds#1176 lands. The base branchpr-1176-headis seedds#1176's head (69676b97).front_hdr_device_peak,front_ios.m).vi::QueryDisplayHdrStatusanswered a fixed 1,000 nits (DM_HDR_PEAK, no launcher setting) on a panel that reaches 1,600. Now: 1,600 for the iPhone 12 Pro and later and the M-series iPad XDR panels, 1,200 for the iPhone X to 11, else 1,000.DM_HDR_PEAKoverrides and0is automatic. The Mac keeps 1,000.NOT_RUNMakefile line merged; if this lands, Add an opt-in packed HDR conversion measurement tool seedds/nxnative#1168 is redundant.Update after two more runs: with HDR on the owner saw flicker; with
DM_HDR=0it was mostly gone. So HDR output is probably part of the flicker; this PR does not fix it. The 1,600-nit peak was in effect in the flickering runs, so it is a candidate; a run withDM_HDR_PEAK=1000would separate it and has not been done. The slow GPU state (26 to 39 ms against 11 to 13) also appeared with HDR off, so it is not an HDR problem.Checked
t_present_hdrpasses on this base (31 checks, four new: a known model's peak, the override, automatic, an unknown model);test_settings.py,test_launcher_settings.py,test_env_switches.py,test_docs.pyandtest_metal_conversion_probe.pypass;front_ios.msyntax-checks against the iPhoneOS SDK.scripts/regress.py check --games: not run: this is stacked on an unmerged HDR PR and only changes what a Switch 2 game is told when HDR output is on.Front ends
Front-ends: interface:
front_hdr_device_peak()infront.h, the display's peak in nits by hardware model (0 = unknown, answered 1,000); a front end that makes an HDR layer implements it, and a weak default answers 0.Docs
docs/settings.md,docs/env_switches.tsvand the Mario Kart World note; no new general mechanismdmsh_chain.py --headerwas run anddm/gfx/nvn/dmsh_chain.his part of the change. Not applicable: no chain tool changed.