https://bugs.kde.org/show_bug.cgi?id=523539
Bug ID: 523539
Summary: [Wayland/amdgpu] Direct Scanout HDR init fails to
enable 3D LUT (ColorOp 342), causing posterization
until dynamic property update
Classification: Plasma
Product: kwin
Version First 6.6.3
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: colour-management
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Created attachment 194631
--> https://bugs.kde.org/attachment.cgi?id=194631&action=edit
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)
--
You are receiving this mail because:
You are watching all bug changes.
