Created attachment 179753 [details] Sample video file that demonstrates the issue SUMMARY Lack of BT.1866 support causes color to render incorrectly when using direct scanout, such as with mpv --vo=dmabuf-wayland. STEPS TO REPRODUCE 1. Play a video with mpv --vo=dmabuf-wayland OBSERVED RESULT 2. The color changes depending on whether direct scanout is enabled in fullscreen or not (such as moving the mouse, or exiting fullscreen) EXPECTED RESULT 3. Color remains consistent SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.17 KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.3 Kernel Version: 6.14.0-20R5-sched-ext (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i5-10310U CPU @ 1.70GHz Memory: 7.5 GiB of RAM Graphics Processor: Intel® UHD Graphics ADDITIONAL INFORMATION https://github.com/mpv-player/mpv/issues/16112
Color information on the surface does not differentiate between compositing and direct scanout. The transfer function not being supported does not make a difference for this bug. On my desktop, this caused a kernel nullptr dereference, so I couldn't test it there, but on my laptop there is no visible difference between compositing and direct scanout. Are you using night light? Please also attach the output of > kscreen-doctor -o and (ideally run it while the video is getting direct scanout) > drm_info
(In reply to Zamundaaa from comment #1) > Color information on the surface does not differentiate between compositing > and direct scanout. The transfer function not being supported does not make > a difference for this bug. > > On my desktop, this caused a kernel nullptr dereference, so I couldn't test > it there, but on my laptop there is no visible difference between > compositing and direct scanout. > > Are you using night light? Please also attach the output of > > kscreen-doctor -o > and (ideally run it while the video is getting direct scanout) > > drm_info I am not using night light. $ kscreen-doctor -o Output: 1 eDP-1 enabled connected priority 1 Panel Modes: 1:1920x1080@60*! 2:1280x1024@60 3:1024x768@60 4:1280x800@60 5:1920x1080@60 6:1600x900@60 7:1368x768@60 8:1280x720@60 Geometry: 0,0 1920x1080 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic HDR: incapable Wide Color Gamut: incapable ICC profile: none Color profile source: sRGB Color power preference: prefer efficiency and performance Brightness control: supported, set to 50% and dimming to 100%
Created attachment 181535 [details] drm_info run during direct scanout. I used sleep so it would run after the video started playing in direct scanout.
Getting same issue with Minecraft with patched GLFW libraries (https://github.com/IMS212/glfw/tree/hdr). Color changes when opening chat causing cursor to appear.
Issue still occurs with https://invent.kde.org/plasma/kwin/-/merge_requests/6896 applied.
(In reply to ctj9512 from comment #4) > Getting same issue with Minecraft with patched GLFW libraries > (https://github.com/IMS212/glfw/tree/hdr). Color changes when opening chat > causing cursor to appear. What GPU/kernel/Mesa are you using? I was not able to produce this on my desktop with Intel B580.
(In reply to Avraham Hollander from comment #6) > (In reply to ctj9512 from comment #4) > > Getting same issue with Minecraft with patched GLFW libraries > > (https://github.com/IMS212/glfw/tree/hdr). Color changes when opening chat > > causing cursor to appear. > > What GPU/kernel/Mesa are you using? > > I was not able to produce this on my desktop with Intel B580. Operating System: Arch Linux KDE Plasma Version: 6.3.90 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 Kernel Version: 6.15.0-rc7-1-mainline (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 7735HS with Radeon Graphics Memory: 96 GiB of RAM (93.5 GiB usable) Graphics Processor 1: AMD Radeon 680M Graphics Processor 2: AMD Radeon RX 7700S mesa 1:25.0.5-1 It might be because I used the new HDR calibration wizard in 6.4 beta.
With HDR, depending on the GPU and driver capabilities, very slight color differences aren't entirely unexpected. (In reply to Avraham Hollander from comment #3) > Created attachment 181535 [details] > drm_info run during direct scanout. I used sleep so it would run after the > video started playing in direct scanout. hmm, so there's no LUTs, no CTM, just the buffer in direct scanout without any additional color operations. Maybe the YUV->RGB matrix i915 uses don't exactly match the matrix KWin uses (and amdgpu)... Not sure how to test for that though. We just set > │ ├───"COLOR_ENCODING": enum {ITU-R BT.601 YCbCr, ITU-R BT.709 YCbCr} = ITU-R BT.709 YCbCr > │ ├───"COLOR_RANGE": enum {YCbCr limited range, YCbCr full range} = YCbCr limited range
Issue does not occur when using "Prefer color accuracy"
Have you tried newest git master version of MPV? wp-color-representation protocol support for mpv has just merged 2 weeks ago.
Please check if this still happens with the latest mpv and KWin releases.
(In reply to Zamundaaa from comment #11) > Please check if this still happens with the latest mpv and KWin releases. I upgraded quite a while ago to hardware where this bug doesn't occur. I atill have the old machine, but not its exact OS, but I could technically pull it back out and install a new OS and test. If ctj9512 can quickly test again it would be helpful. Otherwise let's just close this as fixed. Unless you want to close it now and let someone make a nrw bug report if it happens again?
Yeah, let's close it. If anyone sees this again, just open a new bug report about it.