Plasma + Wayland: Maximized windows cause unwanted darkening (with Breeze Dark EOS theme and other)

[Jull3haxor]

I’ve also tried logging it with a few different scripts but no values ​​change when the brightness seems to change when it happens.. Maybe it’s like you say, it’s time for the madhouse…

[1093i3511]

Well, I can’t really tell… my assumption was based on the video and you clarified that the video itself isn’t showing the issue.

Try to switch temporarily to a plain desktop background instead, maybe one that’s plain black or so. You’ve got all those shades of neon going on, which (at least to my eyes) are a bit tough.

But theses are all wild guesses from my side.

[Jull3haxor]

My research continues.. It seems to be related to Nvidia / Wayland.
The screen brightness is not controlled by KDE, X11, Wayland or NVIDIA Settings.
It is probably done via an automatic LUT / gamma control in the NVIDIA driver or firmware, based on image content (e.g. black areas).

[Jull3haxor]

I think I’m the problem on the track.. I was working on FaceSwap a while ago and then I was forced to tinker with some changes for my Nvidia drivers and also run CUDA, this has probably caused:
The screen dims in a strange way LUT table changed by CUDA execution or program

xrandr does not work NVIDIA blocked display access via render-only mode

nvidia-settings not available for display GPU not display provider anymore

Brightness stuck at 0.0 X or Wayland gets wrong info from driver

Working on a fix…

[Jull3haxor]

System:

• GPU: NVIDIA GTX 1060 6GB (Pascal)
• Driver: nvidia-beta-dkms (currently 555.xx)
• Desktop: KDE Plasma 6.3.4
• Kernel: 6.14.4-arch1-2
• Boot: GRUB 2.12
• Init: dracut
• Display server: Tested on both X11 and Wayland

Done so far:

• Replaced NVIDIA driver with nvidia-beta-dkms, removed nvidia-dkms, nvidia-utils, nvidia-settings
• Rebuilt initramfs using:
  sudo dracut --no-uefi --force /boot/initramfs-linux.img $(uname -r)
• Confirmed /boot/efi mount and fixed dracut UEFI path issues
• Regenerated GRUB config: sudo grub-mkconfig -o /boot/grub/grub.cfg
• Booted via GRUB into clean X11 session
• Verified gamma/brightness changes using nvidia-settings and xrandr
• Verified issue persists even with:
  • Brightness = 0.000
  • Contrast = 0.000
  • Gamma = 1.000
• Created watchdog script to monitor brightness/gamma changes every 2 seconds
• Verified changes occur despite no interaction

What does NOT fix the issue:

• Removing Plasma/KWin effects
• Disabling compositing (Alt+Shift+F12)
• Using x11 vs Wayland
• Changing display outputs (HDMI, DP)
• Manually forcing gamma via CLI or GUI
• Starting with clean user profile
• New kernel, reinstalled kernel modules
• Disabling TTY framebuffer or boot options

Possible suspects:

• GPU-level dynamic contrast or color adjustment (maybe firmware-initiated)
• KDE/Plasma LUT conflict on Pascal GPUs
• EDID or display firmware auto-adjustment
• A hidden system daemon or DDC/CI signal reacting to content

Next step:
Trying watchdog logging to identify when/what is triggering the brightness drop. Any ideas how to fully suppress any auto-dimming signal, LUT override, or contrast enforcement on NVIDIA GPUs under Linux are welcome.

[keescase]

Because nothing comes up in the video I would think that it is something that is done by your monitor , maybe freesync, gsync or adaptive sync, something like that.

[Jull3haxor]

I now tried to check the HDMI cable again, it seems that the cable inside the screen was not fully inserted and a minimal gap, it seems that that is what caused my problems. Possible things that cause it:
HDMI signal was almost connected enough for a picture, but not for correct EDID/handshake

NVIDIA/Plasma tried to interpret incorrect EDID = strange LUT/gamma behavior

The screen could not send back the correct color profile or DDC command

It was perceived as “black image”, which triggered auto-dimming attempts.

Thanks for trying to help me with this!

[Jull3haxor]

Update: after I turned off the screen and turned it back on, the error came back… So it is now completely out of the question that the error is in KDE but rather my screen or possibly the GPU…

[MyNameIsRichard]

It could also be the cable which is easier (and cheaper) to check

[Jull3haxor]

So, finally this atrocity was solved!

Root Cause:*
The HDMI port on the monitor used was labeled MHL - Mobile High-Definition Link ( (but so smal text that I didn’t notice it.).

MHL is intended for mobile devices and includes extra handshake, power delivery (up to 900 mA), and CEC features. Some NVIDIA GPUs misinterpret signals from MHL-enabled ports and reset color/gamma profiles when the monitor power state changes.

Fix:
Power off the PC and monitor completely
Reconnect HDMI to a non-MHL port on the monitor
Boot up as usual
Lock the EDID to avoid future handshake inconsistencies:

# Find active HDMI port:
for f in /sys/class/drm/card0-HDMI-*/status; do echo "$f: $(cat "$f")"; done

# Dump EDID:
sudo cat /sys/class/drm/<MY_ACTIVE_PORT>/edid > ~/edid.bin

# Copy to firmware:
sudo mkdir -p /lib/firmware/edid
sudo cp ~/edid.bin /lib/firmware/edid/edid.bin

# Edit GRUB:
sudo nano /etc/default/grub
# Add:
# drm.edid_firmware=<MY_ACTIVE_PORT>:edid/edid.bin

# Regenerate grub and initramfs:
sudo grub-mkconfig -o /boot/grub/grub.cfg
echo 'install_items+=" /lib/firmware/edid/edid.bin "' | sudo tee /etc/dracut.conf.d/edid.conf
sudo dracut --no-uefi --force /boot/initramfs-linux.img $(uname -r)

# Reboot:
sudo reboot

After switching away from the MHL HDMI port and locking the EDID, the issue is completely resolved. No more dimming, gamma shifts, or post-sleep display bugs.

Hope this helps someone with a similar issue!
Thank you to those of you who tried to help me!