MagicBeanDev/Longshot

Watch

Fork 98

WIP: fix(vk): say why HDR stays SDR when Windows has HDR on #424

Draft

Jiro113 wants to merge 3 commits from Jiro113/Longshot:fix/correctif-hdr into main

Jiro113 commented

2026-11-14 13:10:46 +00:00

First-time contributor

Why

With HDR on in the menu and no HDR picture, the log asks "is HDR on in the display settings?" even when Windows has HDR on, which sends the player to a setting that is already right. That happened on an RTX 4090: Windows was in HDR, but NVIDIA's Vulkan driver listed no HDR10 surface until the same driver was reinstalled clean.

What changed

vk: create_swapchain in gpu/vk/vk_main.cpp still takes an HDR10 surface when one is listed and the SDR one otherwise; what changes is the word on why it is SDR. It sets dev.hdr_sdr_why (HdrSdrWhy in gpu/vk/vk_internal.h): no VK_EXT_swapchain_colorspace, HDR off in Windows, HDR on in Windows but none from the driver, or not known. The vk: HDR: line names the display asked about and is said again when the reason or the display changes, or after the menu's HDR was turned off and on.
vk: the new system_hdr_on in gpu/vk/vk_main.cpp asks Windows whether HDR is on for the window's display (QueryDisplayConfig, then advanced colour info 2 of Windows 11 24H2, else the older one). It is called only when the menu's HDR is on and no HDR10 surface is listed. On Linux it answers "not known", which keeps the old question.
menu: hn_hdr in gpu/vk/vk_menu.cpp adds the same reason, and what to do, under the HDR row's help when the picture stays SDR.
docs: a help entry in docs/common-issues.md ("Windows: HDR is on, but the game stays SDR") and a row in the README's troubleshooting table.
tests: tests/test_hdr_sdr_why.py cuts the HDR block of create_swapchain, hn_hdr and system_hdr_on out of the source. It checks each reason's line and hint, holds the renderer's own copy of the 24H2 structure against the Windows SDK's, and prints what Windows answers for the desktop's display and the time a call takes.
Two run records in docs/tested/.

Flags and settings

No new switch, option or ini key. One menu row changes:

Flag	What it does	Default now	Recommendation	Helps on	Doesn't help on	Untested on
The HDR row's help (Graphics)	Adds a line saying why the picture stays SDR, and what to do, when HDR is on and no HDR10 surface is listed	Shown in that case only; nothing to turn on	On for everyone: it is text only	Windows, where the system's setting can be asked	Linux, which keeps the old question ("Is HDR on in the display settings?")	In the game, everywhere: the test only so far

Measurements

main: 5e072fc8 (2026-11-14)
this PR: fix/correctif-hdr @ c949795e
Hardware: RTX 4090 24 GB, NVIDIA 621.24 (clean install), Core i9-13900K, 64 GB, Windows 11 Home (26300); a Samsung Odyssey G93SC, 5120x1440 at 120 Hz over HDMI
Scene: the intro (the logos), a 2560x720 window, HDR Off then Expanded, paper white 200 nits, peak 1000 nits
Method: a fix, so its measurement is the new game-free test on main's source and on this PR's, and the vk: HDR: lines of two runs in the game (one with HDR on in Windows, one with it off). No fps is claimed; the test prints the time one system_hdr_on call takes.
How to reproduce: python -I -B tests/test_hdr_sdr_why.py on each side. In the game: python -I scripts/longshot_ctl.py launch <game folder>, then option set hdr 1 and wait present --frames 120, and read the vk: HDR: lines of the run's log.txt.

	main @ `5e072fc8`	this PR @ `c949795e`
`tests/test_hdr_sdr_why.py` (this PR's test, on each side's source)	FAIL	PASS
The line with HDR on in Windows and no HDR10 surface from the driver	`(is HDR on in the display settings?)` (read from the source)	`though Windows has HDR on for this display: the graphics driver offers the game none (a clean reinstall of the driver, then a restart: longshot.magicbean.dev/help)` (the test; not seen in the game)
What Windows answers for the display (`system_hdr_on`)	no such function	1 with HDR on in Windows, 0 with it off; 0.02 to 0.03 ms a call
In the game, HDR Expanded, HDR on in Windows (run01)	not run	`vk: HDR: an HDR10 surface (format 64)`, said again after Off and Expanded
In the game, HDR Expanded, HDR off in Windows (run02)	not run	`vk: HDR: an HDR10 surface (format 64)`: the driver lists HDR10 all the same, so no SDR line
`tests/run_all.py --jobs 12`	505 passed, 12 failed, 44 skipped	508 passed, 10 failed, 44 skipped

The two runs in the game were made with the fix commit, 0b042eb3, before its rebase: the same patch on main 0caf0618, as a renderer pack over a base at 0caf0618. The rebase onto 5e072fc8 brought gpu/vk/vk_temporal.cpp, gpu/vk/dlss_actor.h, the scene tone map pass and their tests, none of them a file this PR touches, so the lines still hold. After the rebase the renderer was built again from 0b042eb3's sources (a dev_packs.py pack over a base at 5e072fc8, 0 failed) and the checks run again; the two later commits add only the run records. The game was not run again.

The 10 failures of this PR all fail on main @ 5e072fc8 too on this PC (some for a Python module it lacks, such as zstandard): test_bake_portability, test_bug_report, test_fpx_sticky, test_framegen_resources, test_lift_cache, test_module_ids, test_oot_state_tap, test_pad_layout, test_spawn_emit, test_tested_configurations. main was run from a git archive copy, which adds two failures of its own that need a git checkout (the byte-compile of tracked files and test_dev_packs).

main @ 5e072fc8, tests/test_hdr_sdr_why.py:
FAIL: vk_internal.h has no enum HdrSdrWhy (why the swapchain is SDR with HDR on)

this PR @ c949795e, tests/test_hdr_sdr_why.py (HDR off in Windows):
PASS: with HDR on and an SDR swapchain, the log and the HDR row say why (Windows' setting asked)
PASS: system_hdr_on: not known with no window; the desktop's display (Odyssey G93SC): 0, 0.02 ms a call; AdvancedColorInfo2 held against the SDK's

this PR, in the game, HDR off in Windows (run02, 0b042eb3 before its rebase):
vk: HDR: an HDR10 surface (format 64), paper white 200 nits, peak 1000 nits

Testing

Tested: on the PC above.

The game-free checks, the table above. The existing checks that read gpu/vk/vk_internal.h, gpu/vk/vk_main.cpp and gpu/vk/vk_menu.cpp pass unchanged: none needed an update.
The renderer built for Windows with llvm-mingw, from the sources at c949795e.
Two runs in the game through the control bridge, each recorded in docs/tested/. run01, HDR on in Windows: the HDR10 line, HDR10 swapchain no: SDR with the menu's HDR Off, and the HDR10 line said again with Expanded. run02, HDR off in Windows: the driver still lists an HDR10 surface and the game takes it.
system_hdr_on on the real Windows in both states, through the test: 1 with HDR on, 0 with it off, the display named "Odyssey G93SC".
The bug itself, before the fix: Windows in HDR, no HDR10 surface listed for Vulkan with 621.01 and with 621.24 installed over it, and HDR10 listed again after a clean reinstall of 621.24.

Not tested:

The SDR lines and the HDR row's hint in the game, on any hardware. On this PC the driver now lists HDR10 whether HDR is on or off in Windows, so neither reason can be reached; they are covered by the test only.
A Windows before 11 24H2 (the fallback to the older advanced colour info): this PC answers through the 24H2 one.
Linux: not built and not run here. Its branch of system_hdr_on is (void)display; return -1;.
A PC with two displays (the display named in the line): one display here.
AMD and Intel.
How the HDR10 picture looks on a desktop with HDR off in Windows (run02). main makes the same choice there; this PR doesn't change it.

Needs other testers:

Windows, an AMD or Intel GPU, an HDR display: with Use HDR off in Windows and the menu's HDR on, expecting vk: HDR: the display (<the monitor>) lists no HDR10 surface (HDR is off for this display in Windows' display settings): SDR in the log, the same reason under the HDR row's help (a screenshot), and the HDR10 line once Use HDR is on. A driver that lists HDR10 anyway, as NVIDIA's does here, is a result too (T-EWTV; a maintainer has to add testing wanted before it can be claimed)
Linux: the build, and python -I -B tests/run_all.py hdr_sdr_why, expecting it to pass (T-A3SJ; it waits for the same label)

Screenshots

None yet. The change shows on screen only as the HDR row's help line when the picture stays SDR, which this PC cannot reach (Testing); T-EWTV asks for the screenshot.

Risk and rollback

Which surface the swapchain takes is unchanged, so the picture is the same as on main. What could go wrong is the word: a Windows that answers wrongly would give the wrong reason in the log and under the HDR row. system_hdr_on runs only while the menu's HDR is on and no HDR10 surface is listed, at each swapchain (0.02 to 0.03 ms measured). There is no switch: reverting the commit is enough.

Reviewer notes

Read first the HDR block of create_swapchain and system_hdr_on in gpu/vk/vk_main.cpp, then hn_hdr in gpu/vk/vk_menu.cpp.
AdvancedColorInfo2 is the renderer's own copy of the Windows SDK's DISPLAYCONFIG_GET_ADVANCED_COLOR_INFO_2 (the toolchain's headers keep it behind NTDDI_VERSION): a layout and two numbers, held against the SDK's by static_asserts in the test.
dev.hdr_sdr_why is written by create_swapchain and read by the menu on the presenting thread both, as dev.hdr is.
Left for a follow-up on purpose: with HDR off in Windows, NVIDIA 621.24 lists an HDR10 surface and the game takes it. Whether the game should stay SDR there is another question than this PR's.
The PR stays WIP until the SDR lines were seen in a game run.

Issues

None.

Checklist

For everyone

One topic.
The title is a Conventional Commit (type(scope): description).
Rebased on current main.
python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above).
Tested in the game, or what wasn't is named under Testing.
Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests).
Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (the test fails on main and passes here, but the SDR lines were not seen in a game run yet: T-EWTV)
No game files, dumps, build output or generated files.
third_party/ untouched (a new folder with a PROVENANCE.md instead).
The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

If applicable

AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
Screenshots for a change that shows on screen. (the hint can't be reached on this PC: asked in T-EWTV)
A file in docs/tested/ for each new measured run (format in docs/tested-configurations.md; no appended row or assembled view).
A game-free test added for the fix, failing on main and passing here.
Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (Windows built; Linux not built here: asked in T-A3SJ)
Docs updated.

🤖 Generated with Claude Code

## Why With HDR on in the menu and no HDR picture, the log asks "is HDR on in the display settings?" even when Windows has HDR on, which sends the player to a setting that is already right. That happened on an RTX 4090: Windows was in HDR, but NVIDIA's Vulkan driver listed no HDR10 surface until the same driver was reinstalled clean. ## What changed - vk: `create_swapchain` in `gpu/vk/vk_main.cpp` still takes an HDR10 surface when one is listed and the SDR one otherwise; what changes is the word on why it is SDR. It sets `dev.hdr_sdr_why` (`HdrSdrWhy` in `gpu/vk/vk_internal.h`): no `VK_EXT_swapchain_colorspace`, HDR off in Windows, HDR on in Windows but none from the driver, or not known. The `vk: HDR:` line names the display asked about and is said again when the reason or the display changes, or after the menu's HDR was turned off and on. - vk: the new `system_hdr_on` in `gpu/vk/vk_main.cpp` asks Windows whether HDR is on for the window's display (`QueryDisplayConfig`, then advanced colour info 2 of Windows 11 24H2, else the older one). It is called only when the menu's HDR is on and no HDR10 surface is listed. On Linux it answers "not known", which keeps the old question. - menu: `hn_hdr` in `gpu/vk/vk_menu.cpp` adds the same reason, and what to do, under the **HDR** row's help when the picture stays SDR. - docs: a help entry in `docs/common-issues.md` ("Windows: HDR is on, but the game stays SDR") and a row in the README's troubleshooting table. - tests: `tests/test_hdr_sdr_why.py` cuts the HDR block of `create_swapchain`, `hn_hdr` and `system_hdr_on` out of the source. It checks each reason's line and hint, holds the renderer's own copy of the 24H2 structure against the Windows SDK's, and prints what Windows answers for the desktop's display and the time a call takes. - Two run records in `docs/tested/`. ## Flags and settings No new switch, option or ini key. One menu row changes: | Flag | What it does | Default now | Recommendation | Helps on | Doesn't help on | Untested on | |---|---|---|---|---|---|---| | The **HDR** row's help (Graphics) | Adds a line saying why the picture stays SDR, and what to do, when HDR is on and no HDR10 surface is listed | Shown in that case only; nothing to turn on | On for everyone: it is text only | Windows, where the system's setting can be asked | Linux, which keeps the old question ("Is HDR on in the display settings?") | In the game, everywhere: the test only so far | ## Measurements main: 5e072fc8 (2026-11-14) this PR: fix/correctif-hdr @ c949795e Hardware: RTX 4090 24 GB, NVIDIA 621.24 (clean install), Core i9-13900K, 64 GB, Windows 11 Home (26300); a Samsung Odyssey G93SC, 5120x1440 at 120 Hz over HDMI Scene: the intro (the logos), a 2560x720 window, HDR Off then Expanded, paper white 200 nits, peak 1000 nits Method: a fix, so its measurement is the new game-free test on main's source and on this PR's, and the `vk: HDR:` lines of two runs in the game (one with HDR on in Windows, one with it off). No fps is claimed; the test prints the time one `system_hdr_on` call takes. How to reproduce: `python -I -B tests/test_hdr_sdr_why.py` on each side. In the game: `python -I scripts/longshot_ctl.py launch <game folder>`, then `option set hdr 1` and `wait present --frames 120`, and read the `vk: HDR:` lines of the run's `log.txt`. | | main @ 5e072fc8 | this PR @ c949795e | |---|---|---| | `tests/test_hdr_sdr_why.py` (this PR's test, on each side's source) | FAIL | PASS | | The line with HDR on in Windows and no HDR10 surface from the driver | `(is HDR on in the display settings?)` (read from the source) | `though Windows has HDR on for this display: the graphics driver offers the game none (a clean reinstall of the driver, then a restart: longshot.magicbean.dev/help)` (the test; not seen in the game) | | What Windows answers for the display (`system_hdr_on`) | no such function | 1 with HDR on in Windows, 0 with it off; 0.02 to 0.03 ms a call | | In the game, HDR Expanded, HDR on in Windows (run01) | not run | `vk: HDR: an HDR10 surface (format 64)`, said again after Off and Expanded | | In the game, HDR Expanded, HDR off in Windows (run02) | not run | `vk: HDR: an HDR10 surface (format 64)`: the driver lists HDR10 all the same, so no SDR line | | `tests/run_all.py --jobs 12` | 505 passed, 12 failed, 44 skipped | 508 passed, 10 failed, 44 skipped | The two runs in the game were made with the fix commit, 0b042eb3, before its rebase: the same patch on main 0caf0618, as a renderer pack over a base at 0caf0618. The rebase onto 5e072fc8 brought `gpu/vk/vk_temporal.cpp`, `gpu/vk/dlss_actor.h`, the scene tone map pass and their tests, none of them a file this PR touches, so the lines still hold. After the rebase the renderer was built again from 0b042eb3's sources (a `dev_packs.py` pack over a base at 5e072fc8, 0 failed) and the checks run again; the two later commits add only the run records. The game was not run again. The 10 failures of this PR all fail on main @ 5e072fc8 too on this PC (some for a Python module it lacks, such as `zstandard`): `test_bake_portability`, `test_bug_report`, `test_fpx_sticky`, `test_framegen_resources`, `test_lift_cache`, `test_module_ids`, `test_oot_state_tap`, `test_pad_layout`, `test_spawn_emit`, `test_tested_configurations`. main was run from a `git archive` copy, which adds two failures of its own that need a git checkout (the byte-compile of tracked files and `test_dev_packs`). ``` main @ 5e072fc8, tests/test_hdr_sdr_why.py: FAIL: vk_internal.h has no enum HdrSdrWhy (why the swapchain is SDR with HDR on) this PR @ c949795e, tests/test_hdr_sdr_why.py (HDR off in Windows): PASS: with HDR on and an SDR swapchain, the log and the HDR row say why (Windows' setting asked) PASS: system_hdr_on: not known with no window; the desktop's display (Odyssey G93SC): 0, 0.02 ms a call; AdvancedColorInfo2 held against the SDK's this PR, in the game, HDR off in Windows (run02, 0b042eb3 before its rebase): vk: HDR: an HDR10 surface (format 64), paper white 200 nits, peak 1000 nits ``` ## Testing **Tested:** on the PC above. - The game-free checks, the table above. The existing checks that read `gpu/vk/vk_internal.h`, `gpu/vk/vk_main.cpp` and `gpu/vk/vk_menu.cpp` pass unchanged: none needed an update. - The renderer built for Windows with llvm-mingw, from the sources at c949795e. - Two runs in the game through the control bridge, each recorded in `docs/tested/`. run01, HDR on in Windows: the HDR10 line, `HDR10 swapchain no: SDR` with the menu's HDR Off, and the HDR10 line said again with Expanded. run02, HDR off in Windows: the driver still lists an HDR10 surface and the game takes it. - `system_hdr_on` on the real Windows in both states, through the test: 1 with HDR on, 0 with it off, the display named "Odyssey G93SC". - The bug itself, before the fix: Windows in HDR, no HDR10 surface listed for Vulkan with 621.01 and with 621.24 installed over it, and HDR10 listed again after a clean reinstall of 621.24. **Not tested:** - The SDR lines and the HDR row's hint in the game, on any hardware. On this PC the driver now lists HDR10 whether HDR is on or off in Windows, so neither reason can be reached; they are covered by the test only. - A Windows before 11 24H2 (the fallback to the older advanced colour info): this PC answers through the 24H2 one. - Linux: not built and not run here. Its branch of `system_hdr_on` is `(void)display; return -1;`. - A PC with two displays (the display named in the line): one display here. - AMD and Intel. - How the HDR10 picture looks on a desktop with HDR off in Windows (run02). main makes the same choice there; this PR doesn't change it. **Needs other testers:** - Windows, an AMD or Intel GPU, an HDR display: with **Use HDR** off in Windows and the menu's HDR on, expecting `vk: HDR: the display (<the monitor>) lists no HDR10 surface (HDR is off for this display in Windows' display settings): SDR` in the log, the same reason under the **HDR** row's help (a screenshot), and the HDR10 line once **Use HDR** is on. A driver that lists HDR10 anyway, as NVIDIA's does here, is a result too (T-EWTV; a maintainer has to add `testing wanted` before it can be claimed) - Linux: the build, and `python -I -B tests/run_all.py hdr_sdr_why`, expecting it to pass (T-A3SJ; it waits for the same label) ## Screenshots None yet. The change shows on screen only as the **HDR** row's help line when the picture stays SDR, which this PC cannot reach (Testing); T-EWTV asks for the screenshot. ## Risk and rollback Which surface the swapchain takes is unchanged, so the picture is the same as on main. What could go wrong is the word: a Windows that answers wrongly would give the wrong reason in the log and under the HDR row. `system_hdr_on` runs only while the menu's HDR is on and no HDR10 surface is listed, at each swapchain (0.02 to 0.03 ms measured). There is no switch: reverting the commit is enough. ## Reviewer notes - Read first the HDR block of `create_swapchain` and `system_hdr_on` in `gpu/vk/vk_main.cpp`, then `hn_hdr` in `gpu/vk/vk_menu.cpp`. - `AdvancedColorInfo2` is the renderer's own copy of the Windows SDK's `DISPLAYCONFIG_GET_ADVANCED_COLOR_INFO_2` (the toolchain's headers keep it behind `NTDDI_VERSION`): a layout and two numbers, held against the SDK's by static_asserts in the test. - `dev.hdr_sdr_why` is written by `create_swapchain` and read by the menu on the presenting thread both, as `dev.hdr` is. - Left for a follow-up on purpose: with HDR off in Windows, NVIDIA 621.24 lists an HDR10 surface and the game takes it. Whether the game should stay SDR there is another question than this PR's. - The PR stays WIP until the SDR lines were seen in a game run. ## Issues None. ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. - [x] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). - [ ] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (the test fails on main and passes here, but the SDR lines were not seen in a game run yet: T-EWTV) - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### If applicable - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [ ] Screenshots for a change that shows on screen. (the hint can't be reached on this PC: asked in T-EWTV) - [x] A file in `docs/tested/` for each new measured run (format in `docs/tested-configurations.md`; no appended row or assembled view). - [x] A game-free test added for the fix, failing on `main` and passing here. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (Windows built; Linux not built here: asked in T-A3SJ) - [x] Docs updated. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Jiro113 added 3 commits

2026-11-14 13:10:46 +00:00

fix(vk): say why HDR stays SDR when Windows has HDR on 0b042eb3e6

With the menu's HDR on and no HDR10 surface listed, the log asked "is HDR
on in the display settings?" even when it was. NVIDIA's Vulkan driver can
list no HDR10 surface while Windows has HDR on (seen on an RTX 4090 with
621.01 and 621.24, where NvAPI's own HDR capabilities query failed too; a
clean reinstall of the same driver brought HDR10 back to Vulkan).

create_swapchain now asks Windows whether HDR is on for the window's display
(QueryDisplayConfig, advanced colour info 2, else 1) and says which case it
is: no VK_EXT_swapchain_colorspace, HDR off in Windows, HDR on in Windows
but none from the driver, or not known. The line names the display asked
about, and is said again when the reason or the display changes, or the
menu's HDR was turned off in between. The HDR row's hint shows the same
reason and what to do. A help entry in docs/common-issues.md and a row in
the README's troubleshooting give the steps: a clean reinstall of the
graphics driver, then a restart.

Windows before 11 24H2 only tells "advanced colour": on with wide colour
enforced is answered "not known" rather than guessed. The 24H2 structure is
the renderer's own copy (the toolchain's headers keep it behind
NTDDI_VERSION); tests/test_hdr_sdr_why.py holds its layout and numbers
against the SDK's and prints the time a call takes (0.03 ms here).

Co-Authored-By: Claude Fable 5.2 <[email protected]>

docs(tested): the HDR line in the game on an RTX 4090 (run01) 55169a23b1

The run of the fix (0b042eb3, before its rebase) on this PC: HDR Expanded, Off
and Expanded again over the control bridge, with the log's lines.

Co-Authored-By: Claude Fable 5.2 <[email protected]>

docs(tested): with Windows' HDR off, NVIDIA still lists HDR10 (run02)

CI / Conventional Commit title (pull_request) Blocked by required conditions

Details

CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Blocked by required conditions

Details

CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Blocked by required conditions

Details

CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions

Details

CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions

Details

Third-party parts / As their notes say (pull_request) Blocked by required conditions

Details

Third-party parts / The same as upstream (pull_request) Blocked by required conditions

Details

Website / Website on Cloudflare (pull_request) Blocked by required conditions

Details

PR description / Description follows the template (pull_request_target) Successful in 3s

Details

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

c949795e3b

The run of the fix (0b042eb3, before its rebase) with HDR turned off in
Windows: the driver lists an HDR10 surface all the same and the game takes it,
so the SDR lines do not show here.

Co-Authored-By: Claude Fable 5.2 <[email protected]>

Jiro113 commented

2026-11-14 13:11:21 +00:00

Author

First-time contributor

Test request T-EWTV is open for the SDR lines and the HDR row's hint on a Windows PC with an AMD or Intel GPU and an HDR display: this PC's NVIDIA driver lists HDR10 whether HDR is on or off in Windows, so neither reason shows here. It needs the testing wanted label from a maintainer before it can be claimed.

Jiro113 commented

2026-11-14 13:15:41 +00:00

Author

First-time contributor

Test request T-A3SJ is open for Linux: the build, and python -I -B tests/run_all.py hdr_sdr_why. The description names it and the Testing box is ticked now that both requests are open. Both T-EWTV and T-A3SJ wait for a maintainer to add the testing wanted label.