Bug 2292514

Summary: kernel 6.9.4-200.fc40.x86_64 starts to slowly blur screen with milky veil when put on battery power; problem immediately solved when plugged in again
Product: [Fedora] Fedora Reporter: Christopher Klooz <py0xc3>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 40CC: acaringi, adscvr, agurenko, airlied, alciregi, bskeggs, hdegoede, hpa, josef, kernel-maint, linville, masami256, mchehab, ptalbert, steved, suraj.ghimire7
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-06-19 11:27:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Christopher Klooz 2024-06-15 17:52:33 UTC 
1. Please describe the problem:
When booting 6.9.4-200.fc40.x86_64 and power plugged in on my notebook, everything is fine. But once the power plug is removed so that the notebook switches to battery mode, the screen starts to get slowly blurred as if a "milky veil" is slowly added. So it feels like it gets brighter and brighter, but the brightness does not really change but some other value: simplified, everything gets much whiter than before.

This process takes around 10 seconds until the level of whiteness is achieved that remains. It is still possible to work that way, although things look a little strange.

Once I plug in power again, it takes about a second, and then immediately (without any delay), the picture is normal again.

I can change brightness and day/night mode as usual, but the "whiteness" effect remains if I do that while on battery. The settings have not changed, including the battery/plugged-in settings.

When I boot 6.8.11, the problem does not appear.

2. What is the Version-Release number of the kernel:
6.9.4-200.fc40.x86_64

I use Fedora KDE Spin. Tainted = 0. AMD Ryzen 7 PRO 6850U with Radeon Graphics (only internal graphics). I use the SELinux profile sysadm_u (confined user) with the x boolean enabled while working.

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
The problem occurred first with 6.9.4-200.fc40.x86_64. 6.8.11 works fine.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
1) Just boot the kernel 6.9.4-200.fc40.x86_64 on Lenovo T16 Gen1, AMD Ryzen 7 PRO 6850U with Radeon Graphics.
2) Plug off power and watch the subsequent 10 seconds for the "milky white" to come.
3) Plug on power again and wait about 1 second, then the "milky white" is completely gone immediately.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
Rawhide not tested. Just 6.9.4 as newest kernel.

6. Are you running any modules that not shipped with directly Fedora's kernel?:
No. cat /proc/sys/kernel/tainted = 0


7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.
I have created a dedicated boot, once with 6.9.4 that contains the issue, and once with 6.8.11 that contains no problems.

The log of the problem with 6.9.4 is here: https://gitlab.com/py0xc3/tmp_8dc37e8453bbfbd61ad1/-/blob/main/kernel6.9.4/6.9.4-200.screenChanges.log
 -> I plugged off power on 19:03:50 system time (then the issue started until it reached the highest "milky" factor after around 10 seconds), and then I plugged in power again on 19:04:20 (after about 1 second, everything was fine again).

On 6.8.11, everything is fine: https://gitlab.com/py0xc3/tmp_8dc37e8453bbfbd61ad1/-/blob/main/kernel6.9.4/6.8.11-300.screenNormal.log
 -> I plugged of power on 19:01:00 and plugged power in again on 19:01:40: everything fine, no issues.

Issue is reproducible always.

Thanks for taking care. Let me know if you need more.

Reproducible: Always
Comment 1 Christopher Klooz 2024-06-15 18:49:17 UTC 
I have just submitted another bug against kernel, although I am not sure if the other one is really kernel related. In any case, I am quite sure the two cases are not related, but in case you want to check it out: https://bugzilla.redhat.com/show_bug.cgi?id=2292520
Comment 2 Artem S. Tashkinov 2024-06-16 11:53:01 UTC 
Please file here:

https://gitlab.freedesktop.org/drm/amd/-/issues
Comment 3 Christopher Klooz 2024-06-16 12:32:17 UTC 
Upstream: https://gitlab.freedesktop.org/drm/amd/-/issues/3432
Comment 4 Christopher Klooz 2024-06-17 15:41:25 UTC 
Today, I tested 6.9.4 again (switching between plugged in & battery multiple times), and currently, the issue does no longer appear. I now also tested 6.9.5 (which is currently in Fedora testing), which works fine as well (although, on 6.9.5, I could not yet test plug in and plug off but only being on battery).

Since the last test in which I could reproduce the issue, a few updates have been applied to my system.

My expectation is that maybe one (or more) firmware or mesa packages, which were among the updates, solved the issue:

```
amd-gpu-firmware-20240610-1.fc40.noarch
amd-ucode-firmware-20240610-1.fc40.noarch
atheros-firmware-20240610-1.fc40.noarch
brcmfmac-firmware-20240610-1.fc40.noarch
cirrus-audio-firmware-20240610-1.fc40.noarch
intel-audio-firmware-20240610-1.fc40.noarch
intel-gpu-firmware-20240610-1.fc40.noarch
iwlegacy-firmware-20240610-1.fc40.noarch
iwlwifi-dvm-firmware-20240610-1.fc40.noarch
iwlwifi-mvm-firmware-20240610-1.fc40.noarch
libertas-firmware-20240610-1.fc40.noarch
linux-firmware-20240610-1.fc40.noarch
linux-firmware-whence-20240610-1.fc40.noarch
mt7xxx-firmware-20240610-1.fc40.noarch
nvidia-gpu-firmware-20240610-1.fc40.noarch
nxpwireless-firmware-20240610-1.fc40.noarch
realtek-firmware-20240610-1.fc40.noarch
tiwilink-firmware-20240610-1.fc40.noarch

mesa-dri-drivers-24.1.1-3.fc40.x86_64 (obsoleted by the below)
mesa-filesystem-24.1.1-3.fc40.x86_64 (obsoleted by the below)
mesa-libEGL-24.1.1-3.fc40.x86_64 (obsoleted by the below)
mesa-libGL-24.1.1-3.fc40.x86_64 (obsoleted by the below)
mesa-libgbm-24.1.1-3.fc40.x86_64 (obsoleted by the below)
mesa-libglapi-24.1.1-3.fc40.x86_64 (obsoleted by the below)
mesa-libxatracker-24.1.1-3.fc40.x86_64 (obsoleted by the below)
mesa-va-drivers-freeworld-24.1.1-1.fc40.x86_64
mesa-vdpau-drivers-freeworld-24.1.1-1.fc40.x86_64
mesa-vulkan-drivers-24.1.1-3.fc40.x86_64 (obsoleted by the below)

mesa-dri-drivers-24.1.1-5.fc40.x86_64
mesa-filesystem-24.1.1-5.fc40.x86_64
mesa-libEGL-24.1.1-5.fc40.x86_64
mesa-libGL-24.1.1-5.fc40.x86_64
mesa-libgbm-24.1.1-5.fc40.x86_64
mesa-libglapi-24.1.1-5.fc40.x86_64
mesa-libxatracker-24.1.1-5.fc40.x86_64
mesa-vulkan-drivers-24.1.1-5.fc40.x86_64
```

So maybe the bug was the result of some interaction between 6.9.4 and one of the above packages.

If you need the full list of updates that have been applied in the meantime, feel free to let me know.

I will keep this ticket open until Wednesday and stick with 6.9.5, and also test the switch between plugged in and battery later, but if the issue does not reappear, I will close the ticket.

I report if the issue reappears on 6.9.5. Feel free to spare your time until then.

Also, sorry for the above mistake: I forgot to mention that I also have mesa-va-drivers-freeworld and mesa-vdpau-drivers-freeworld for use in Firefox included from the rpmfusion repo (I introduced this a few weeks ago and I am not yet used to it being contained). My bad :(

Thanks for your contributions in either case!

( #2292520 , which I mentioned above, still occurs on 6.9.5)
Comment 5 Christopher Klooz 2024-06-18 11:07:08 UTC 
The issue is still there. Also on 6.9.5. But it seems the issue is only provoked if the machine was booted with power plugged in, and when it is booted this way, plugging off leads to the issue while again plugging in solves it. When the machine is booted on battery, everything is fine. When the machine has been booted on battery, it was also ok to plug in and plug off power later without the issue occurring. What ever "enables" the issue, it occurs when my machine is booted with power plugged in. I report if I experience new behavior. I will now stick with 6.9.5 till 6.9.6 is released. Let me know if you need data or if I shall test something.

It might be added that it is not just "milky": when watching a movie, I also saw it changes contrast and some colors seem to also differ. I checked it a few times with plugging off and in the power plug during the movie ran. This was not that obvious during other activities.
Comment 6 Christopher Klooz 2024-06-19 11:27:23 UTC 
Several people came up with that issue, but it seems to be intended behavior that was intentionally introduced in order to save power when on battery. But it can be disabled if people want.

Here the elaboration from Mario Limonciello:

```
This behavior you're all describing is adaptive backlight modulation in action.  The brightness and contrast are dynamically adjusted for the image being displayed.
Choosing "power saver" will activate a more intense version of it.  Choosing balanced but unplugging will activate a less intense version.
The power savings from it are pretty dramatic depending upon the content, but if you really don't like the image quality as a result there are two ways to permanently disable it described in PPD's README.

Adding amdgpu.abmlevel=0 to the kernel command line. This will disable abm value changes entirely.
By using --block-action=amdgpu_panel_power in the power-profiles-daemon ExecStart command. This will allow you to still change values manually in sysfs but power-profiles-daemon will not change anything.
```

-> https://gitlab.freedesktop.org/drm/amd/-/issues/3432#note_2458864