*** This bug has been marked as a duplicate of bug 480799 ***

oops, that was the wrong one. I didn't see the one I was actually thinking about, let's just track it here then.

When the brightness stays constant, is performance okay?

> Used other ICC and have same issue
Does it also happen without an ICC profile?

Intresting(In reply to Zamundaaa from comment #3)
> When the brightness stays constant, is performance okay?
> 
> > Used other ICC and have same issue
> Does it also happen without an ICC profile?

I have no issues with the ICC profile. I had previously only tried the built-in one. I upgraded to Plasma 6.2.2 and still see the same problem. There is no frame drop if you don't change the brightness. Here are the results with the ICC profile:

So I have the following behavior:

1. Without ICC - No night mode - Brightness change - no frame drop
2. Without ICC - With night mode - Brightness change - frame drop

3. With built-in ICC - No night mode - Brightness change - No frame drop
4. With built-in ICC - With night mode - brightness change - frame drop


5. With any ICC - No night mode - Brightness change - No drop

6. With ICC sRGB - With night mode - Brightness change - no frame drop

7. With ICC AdobeRGB1998 - With night mode - Brightness change - no frame drop

8. With ICC Bluish - With night mode - Brightness change - no frame drop

9. With ICC Rec709 - With night mode - Brightness change - No frame drop

10. With ICC SMPTE-C-RGB - With night mode - Brightness change - no frame drop

!!! 11. With ICC x11-colors.icc - With night mode - Brightness change - frame drop

Okay, I can confirm that there are some frame drops. It's not very pronounced here, but still measurable.
It's almost certainly caused by calculating or by programming lookup tables - if you set an ICC profile that KWin successfully loads, then a shader is used instead, so it doesn't happen there.

I can also reproduce this issue on my device:

Processors: 16 × AMD Ryzen 7 7840U w/ Radeon™ 780M Graphics
Memory: 14.9 GB of RAM
Graphics Processor: AMD Radeon 780M

When I change the brightness via keyboard button during the night light transition period, it does not respond smoothly.

*** Bug 496316 has been marked as a duplicate of this bug. ***

I looked into this a bit more, and my theory was correct - it takes consistently less than 200µs to do a commit for normal presentation, but with LUT changes it takes 1-2ms instead, making KWin miss the deadline for the frame. I'm not sure if this is a bug in amdgpu or if it's just how long the hardware takes to respond, but either way we can improve the situation by measuring how much time we spend in the kernel and adjusting the safety margin accordingly.

Same experience on my system:

Operating System: Fedora Linux 41
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.9.0
Qt Version: 6.8.1
Kernel Version: 6.12.4-200.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics
Memory: 58.5 GiB of RAM
Graphics Processor: AMD Radeon 780M

(In reply to Zamundaaa from comment #8)

> I'm not sure if this is a bug in amdgpu

This started to happen direclty after upgrading to 6.2 on laptops without any AMD graphics. Night Light cannot be used at all.

Right, yours is a different case, I shouldn't have marked that as a duplicate.

I also have this issue. Toggling Night light in the systray Brightness and color poppup, the kwin_wayland process is pegged at 100% during the transition.

Plasma 6.2.5

Can reproduce regardless of ICC profile (none, ICC profile, built-in)
Intel graphics.

*** Bug 453701 has been marked as a duplicate of this bug. ***

Duplicating previous comment from duplicate bug report  Bug 453701 
Still affected:
kde: 6.3.2-1.fc41
system info: https://gist.github.com/vst-name/35f647cf2c9f02e41f6db1220a4c3236 
❯ cat /etc/os-release 
NAME="Aurora"
VERSION="latest-41.20250304 (Kinoite)"
RELEASE_TYPE=stable
ID=aurora
ID_LIKE="fedora"
VERSION_ID=41
VERSION_CODENAME=""
PLATFORM_ID="platform:f41"
PRETTY_NAME="Aurora (Version: latest-41.20250304 / FROM Fedora Kinoite 41)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:universal-blue:aurora:41"
DEFAULT_HOSTNAME="aurora"
HOME_URL="https://getaurora.dev/"
DOCUMENTATION_URL="https://docs.getaurora.dev"
SUPPORT_URL="https://github.com/ublue-os/aurora/issues/"
BUG_REPORT_URL="https://github.com/ublue-os/aurora/issues/"
SUPPORT_END=2025-12-15
VARIANT="Kinoite"
VARIANT_ID=aurora-dx-hwe-nvidia
OSTREE_VERSION='latest-41.20250304'
BUILD_ID="d0733e0"
IMAGE_ID="aurora-dx-hwe-nvidia"

(In reply to Vladislav Stishenko from comment #15)
> Duplicating previous comment from duplicate bug report  Bug 453701 
> Still affected:
> kde: 6.3.2-1.fc41
> system info:
> https://gist.github.com/vst-name/35f647cf2c9f02e41f6db1220a4c3236 
> ❯ cat /etc/os-release 
> NAME="Aurora"
> VERSION="latest-41.20250304 (Kinoite)"
> RELEASE_TYPE=stable
> ID=aurora
> ID_LIKE="fedora"
> VERSION_ID=41
> VERSION_CODENAME=""
> PLATFORM_ID="platform:f41"
> PRETTY_NAME="Aurora (Version: latest-41.20250304 / FROM Fedora Kinoite 41)"
> ANSI_COLOR="0;38;2;60;110;180"
> LOGO=fedora-logo-icon
> CPE_NAME="cpe:/o:universal-blue:aurora:41"
> DEFAULT_HOSTNAME="aurora"
> HOME_URL="https://getaurora.dev/"
> DOCUMENTATION_URL="https://docs.getaurora.dev"
> SUPPORT_URL="https://github.com/ublue-os/aurora/issues/"
> BUG_REPORT_URL="https://github.com/ublue-os/aurora/issues/"
> SUPPORT_END=2025-12-15
> VARIANT="Kinoite"
> VARIANT_ID=aurora-dx-hwe-nvidia
> OSTREE_VERSION='latest-41.20250304'
> BUILD_ID="d0733e0"
> IMAGE_ID="aurora-dx-hwe-nvidia"

Though for me the bug(lag, low fps) only appears with fast switching of night light:
- suspend night light
- switching via - always on/off via settings

KDE is rendering on intel built-in GPU (Iris Xe Graphics)
With ICC: None - it still lags under  condition above, but less noticeable
Same with RGB Range: limited/full

It appears to me that the same symptom (high CPU usage) is present when changing brightness on a laptop when external monitor is connected - which very newly also dims the external monitor image signal, also by modifying LUT I assume.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7438

Git commit 85eeafa09282cd6bda8effb0523ee656cb0eab2f by Vlad Zahorodnii, on behalf of Xaver Hugl.
Committed on 08/04/2025 at 06:40.
Pushed by zamundaaa into branch 'master'.

backends/drm: dynamically adjust the safety margin based on commit time

Atomic (test) commits can take a varying amount of time, and that depends on
the content of the commits as well as CPU frequency. For example, changing
GAMMA_LUT can take a whole additional millisecond on my desktop PC, and may
take even longer on laptops in power saving mode.

To mitigate that, as well as the scheduler not necessarily waking up the commit
thread at the desired time, the added logic compares the desired vs. achieved
commit completion timestamp after every atomic commit, and adjusts the safety
margin accordingly.

As we currently don't know exactly when the atomic commit is actually applied,
and the timestamp for when the ioctl returns is just an approximation (which
fails on NVidia), this keeps the base safety margin at 1.5ms. We can reduce
that once we have some API to actually know when the commit is applied.

M  +25   -2    src/backends/drm/drm_commit_thread.cpp
M  +2    -0    src/backends/drm/drm_commit_thread.h
M  +2    -0    src/backends/drm/drm_pipeline.cpp

https://invent.kde.org/plasma/kwin/-/commit/85eeafa09282cd6bda8effb0523ee656cb0eab2f