Bug 500019 - Direct scanout is prevented by black point compensation
Summary: Direct scanout is prevented by black point compensation
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: platform-drm (other bugs)
Version First Reported In: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-13 20:24 UTC by Zamundaaa
Modified: 2025-05-26 15:41 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zamundaaa 2025-02-13 20:24:44 UTC
The legacy KMS matrix is only 3x3, but the way we implemented black point compensation uses a 3x4 matrix, preventing direct scanout.

If we apply BPC with the LUTs instead, then we could apply it just fine without preventing direct scanout too.
Comment 1 Syntist 2025-02-21 04:36:10 UTC
Can confirm direct scannout doesn't work when Color profile ICC/Built in is selected with prefer efficiency. But setting color profile to none works as it should.
Comment 2 kodatarule 2025-03-14 07:17:28 UTC
I have noticed that even with color profile set to none the red "Compositing" sign still shows, not triggering direct scanout.
This is a clean install of CachyOS, I was wondering why there was nearly 10fps deficit compared to Gnome for a long time and this seems to be the reason as to why.

Operating System: CachyOS Linux 
KDE Plasma Version: 6.3.3
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2
Kernel Version: 6.13.6-2-cachyos (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor
Memory: 31,3 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3090
Comment 3 kodatarule 2025-03-14 07:26:07 UTC
In addition, I did some more tests and even on a single monitor the red "Compositing" remains, effectively not letting direct scanout work at all(color profile set to none). 
I am not sure if this is nvidia driver bug or something in KDE, if any logs are needed, please let me know so I can provide.
Comment 4 kodatarule 2025-03-14 07:35:01 UTC
Apologies for another reply, just wanted to say that I tested on an amd+nvidia laptop and the red "compositing" still stays on.
Comment 5 Bug Janitor Service 2025-04-27 22:37:10 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7567
Comment 6 Zamundaaa 2025-04-30 15:53:15 UTC
Git commit faac87b9642c47a2afe0228216c0ef9063c138eb by Xaver Hugl.
Committed on 30/04/2025 at 15:39.
Pushed by zamundaaa into branch 'master'.

core/colorpipeline: optimize out black point compensation

M  +14   -0    autotests/test_colorspaces.cpp
M  +28   -0    src/core/colorpipeline.cpp

https://invent.kde.org/plasma/kwin/-/commit/faac87b9642c47a2afe0228216c0ef9063c138eb
Comment 7 Zamundaaa 2025-04-30 16:22:17 UTC
Git commit b97e1a374aa10e528fe361fd87a5df76b5e2017d by Xaver Hugl.
Committed on 30/04/2025 at 16:04.
Pushed by zamundaaa into branch 'Plasma/6.3'.

core/colorpipeline: optimize out black point compensation
(cherry picked from commit faac87b9642c47a2afe0228216c0ef9063c138eb)

M  +14   -0    autotests/test_colorspaces.cpp
M  +28   -0    src/core/colorpipeline.cpp

https://invent.kde.org/plasma/kwin/-/commit/b97e1a374aa10e528fe361fd87a5df76b5e2017d
Comment 8 Harald Weissmueller 2025-05-01 06:46:59 UTC
(In reply to Zamundaaa from comment #7)
> Git commit b97e1a374aa10e528fe361fd87a5df76b5e2017d by Xaver Hugl.
> Committed on 30/04/2025 at 16:04.
> Pushed by zamundaaa into branch 'Plasma/6.3'.
> 
> core/colorpipeline: optimize out black point compensation
> (cherry picked from commit faac87b9642c47a2afe0228216c0ef9063c138eb)
> 
> M  +14   -0    autotests/test_colorspaces.cpp
> M  +28   -0    src/core/colorpipeline.cpp
> 
> https://invent.kde.org/plasma/kwin/-/commit/
> b97e1a374aa10e528fe361fd87a5df76b5e2017d

Is there something else required besides using a kwin with this patch? I tried the Plasma/6.3 branch here and direct scanout doesn't seem to work with an ICC profile or the "built-in" setting. It only works with color profile set to "none". I'm using AMD graphics.

Something else I happened to notice because there's a bug with regards to hardware cursor gamma right now on AMD RDNA 4: kwin seems to switch to a software cursor in fullscreen windows (maybe only with VRR enabled?). The use of a software cursor then also seems to break direct scanout. I tried experimenting with environment variables and setting KWIN_DRM_DONT_FORCE_AMD_SW_CURSOR=1 keeps the hardware cursor enabled for fullscreen.
Comment 9 Zamundaaa 2025-05-02 12:47:44 UTC
> Is there something else required besides using a kwin with this patch? I tried the Plasma/6.3 branch here and direct scanout doesn't seem to work with an ICC profile or the "built-in" setting. It only works with color profile set to "none".

It depends on your settings. If you have color accuracy set to "prefer accuracy", that will prevent direct scanout in most situations. Because driver APIs are still quite lacking, having a visible cursor also often prevents it.

> I tried experimenting with environment variables and setting KWIN_DRM_DONT_FORCE_AMD_SW_CURSOR=1 keeps the hardware cursor enabled for fullscreen.
Right, we can probably disable that workaround by default now
Comment 10 kodatarule 2025-05-08 13:19:32 UTC
Just updated to plasma 6.3.5 on both PC desktop and laptop, both are still not triggering the direct scanout.
I have also tried to make the color profile to none with no success, as well as single monitor setup which still fails to trigger the direct scanout.
Comment 11 Zamundaaa 2025-05-26 15:41:28 UTC
There can still be other things that prevent direct scanout, like active KWin effects or driver bugs