Repository navigation
Conversation
Reuse settings inheritance and game lifetime tracking, with capability checks and restart-safe cleanup through the existing control daemon.
Extend the existing SDR LUT builder with a neutral inverse tone map. Apply the same tables to the game layer on suitable primary-output hardware planes or during composition, leaving SDR overlays and native HDR on their existing paths.
Disk image
Downloads as a zip holding |
Adapt AutoHDR to Gamescope 3.17 while preserving native gamut mapping and repeated-frame caching. Reuse the color-management update checkpoint, derive the LUT descriptor count and register tests without modifying the upstream source list.
JPyke3
left a comment
JPyke3
left a comment
There was a problem hiding this comment.
Some minor changes.
Aside from this I'd love to get @virtudude @FeralAI or @justradical's opinion on if we should add a giant gamescope patch to support this. Just worried about drifting super far away from upstream projects like Gamescope. Personally I am a bit neutral but I am worried about how hard maintenance would be
| index 0000000..986d99d | ||
| --- /dev/null | ||
| +++ b/tests/test_auto_hdr.cpp | ||
| @@ -0,0 +1,347 @@ | ||
| +#include <array> |
There was a problem hiding this comment.
Insure if we really need to patch in a gamescope test file
There was a problem hiding this comment.
Kept this as regression coverage for the new AutoHDR transform and its integration with Gamescope's LUT builder. Existing upstream color tests cover SDR gamut mapping, while Armada's shell tests cover settings and lifecycle; neither exercises AutoHDR's generated LUTs.
It checks peak bounds, RGB/chromaticity preservation after LUT quantization, gain ordering, and curve monotonicity against an independent reference. It reuses the optional gamescope_tests/Catch2 target, with no additional dependency or installed component.
These tests help catch color-processing changes during Gamescope updates. They cannot verify plane allocation, layer selection, or SDR-overlay presentation, which still need source review and device tests; those maintenance boundaries are now called out in the patch header.
@JPyke3 Gamescope does have a native inverse tone mapper, but that forces composition by default And ensuring the AutoHDR isn't applied to undesired layers like the steam overlay stuff While the patch is big it shouldn't be affecting anything if the AutoHDR toggle is disabled, it is mostly adding a separate presentation flow for when AutoHDR is enabled, while reusing existing things as much as possible (at least as far as I tried to ensure) |
Summary
Add opt-in Auto HDR for SDR games on supported HDR-capable primary displays.
The implementation is contained in one Gamescope patch plus Armada Control integration. It adds no packages or kernel patches and does not change the bottom-screen desktop session.
Verification
The changes were verified working on both the Retroid Pocket Nova and the AYN Thor, including direct-scanout Auto HDR presentation and Steam's HDR indication.
Regression coverage is included for settings and runtime lifecycle behavior, along with Gamescope tests for LUT luminance bounds, chromaticity, gain, curve continuity, and output-gamut handling. This does not claim exact visual equivalence between SDR and inverse-tone-mapped HDR or validation on every HDR-capable device.
Development disclosure
AI was used as a supporting tool during development, debugging, and code review. Hardware verification was performed on the Retroid Pocket Nova and AYN Thor.