https://bugs.kde.org/show_bug.cgi?id=523539
--- Comment #1 from Dávid Jeszenszki <[email protected]> --- (In reply to Dávid Jeszenszki from comment #0) > Created attachment 194631 [details] > 2 different drm_info output ran while ingame directly in direct scanout > first test ran without live nudge second with it. > > SUMMARY > When an HDR surface initializes with direct scanout (or recreates its > swapchain via ReShade/Luma), KWin programs the amdgpu DRM color pipeline > incorrectly. It leaves 1D curve/matrix operations active while keeping the > 3D LUT and downstream 1D LUT bypassed, leading to severe signal quantization > and posterization. > > Updating any SDR/Paper White property live while the broken plane is active > immediately forces a full, working colorop configuration. > > STEPS TO REPRODUCE > 1. Set Paper White / SDR Brightness in KDE System Settings to any baseline > value (e.g., 200 nits). > 2. Launch an HDR game (or trigger an scRGB / FP16 surface re-init with > ReShade/Luma). > 3. OBSERVE (Broken Init State): Direct scanout engages, but output suffers > from severe posterization, crushed gradients, and heavy bit-depth > quantization. > 4. While the game is actively presenting in the broken state, adjust the > Paper White slider live in System Settings (e.g., from 200 nits to 210 nits). > 5. OBSERVE (Fixed State): The pipeline immediately recovers, output smooths > out to proper 10-bit output, and Direct Scanout remains active. > > OBSERVED RESULT > Initial surface creation leaves the colorop pipeline partially > bypassed/misconfigured. Re-setting the static baseline nits prior to launch > does not fix it; only a dynamic property update on an actively presenting > plane forces KWin to push a clean atomic commit. > > EXPECTED RESULT > Initial Direct Scanout surface creation should bind and program the 3D LUT > and downstream LUTs cleanly on first commit without requiring a mid-flight > property change. > > SOFTWARE / HARDWARE ENVIRONMENT > Operating System: Arch Linux > KDE Plasma Version: 6.7.3 > KDE Frameworks Version: 6.28.0 > Qt Version: 6.11.1 > Kernel Version: 7.1.4-1-cachyos (64-bit) > Graphics Platform: Wayland > Processors: 16 × AMD Ryzen 7 5700X3D 8-Core Processor > Memory: 32 GiB of RAM (31.2 GiB usable) > Graphics Processor: AMD Radeon RX 6900 XT > Display: Titan Army P275MV Plus (10-bit HDR / Wide Gamut / DP-2) > > ADDITIONAL INFORMATION / ROOT CAUSE (drm_info diff) > Comparing `drm_info` between initial surface creation (broken) and live > paper white adjustment (fixed) reveals the exact atomic state desync: > > - Initial Launch (Broken): > - ColorOp 315 (1D Curve PQ): BYPASS = 0 > - ColorOp 320 (Multiplier): BYPASS = 0 > - ColorOp 325 (3x4 CTM Matrix): BYPASS = 0 > - ColorOp 342 (3D LUT): BYPASS = 1 (Bypassed!) > - ColorOp 354 (1D LUT): BYPASS = 1 (Bypassed!) > > - Live Adjustment (Fixed): > - ColorOp 315, 320, 325: BYPASS = 1 (Bypassed) > - ColorOp 342 (3D LUT): BYPASS = 0 (Active with populated blob 557) > - ColorOp 354 (1D LUT): BYPASS = 0 (Active with populated blob 559) > > On surface initialization, KWin fails to program the required 3D LUT colorop > on AMD, leaving an incomplete curve chain active until a dynamic property > delta forces a re-evaluation. > > (KWIN_DRM_USE_COLOR_PIPELINE=1 Was enabled in /etc/environment during my > testing) One Small correction it doesnt seem to happen on scrgb games only on hdr10 ones -- You are receiving this mail because: You are watching all bug changes.
