I just brought a new Zcer Aspire 3 A315-21G-91JL about a week ago and installed Arch Linux in its default form. i did not install any drivers as am using the kernel driver amdgpu provided with the kernel. ever since i installed arch, i have been experiencing screen flickering issues. i have included as much info about my system as possible. if you need more, please ask me.
Created attachment 285093 [details] dmesg info
Created attachment 285095 [details] hwinfo complete
Created attachment 285097 [details] journalctl details
Created attachment 285099 [details] xorg setup information
i've even tried other linux distros like opensuse ubuntu manjaro and still get the same result. quite concerned that it might be hurting my screen with all this flashing
Created attachment 285101 [details] Current Application List - Installed Apps
Created attachment 285107 [details] xorg.conf settings i would assume that the default settings would work, so i made no changes
What kind of flickering is it? - Are the contents of the screen flickering or the backlight? - Is the whole screen flickering or only a part of it? - Is the flickering constant or does it happen only at random intervals? - Does anything trigger it (e.g., a movement on the screen) or does it happen automatically? - Does the flickering also occur when you switch to the framebuffer console (Ctrl-Alt-F<n>)? I've seen at least three kinds: 1. The whole content of the screen rapidly flickers, non-stop. The framebuffer console is unaffected. 2. The screen shows visual artifacts like flickering black lines triggered by e.g. scrolling (but not the movement of the cursor); for a video of the issue, see https://bugs.freedesktop.org/show_bug.cgi?id=110199 3. The backlight flickers randomly for about 30 seconds and then stops until the next resume from suspend. The flickering also happens on the framebuffer console. In the meantime, I'd try one of these to see if anything changes: - switching to linux-lts kernel - setting amdgpu.dc=0 on the kernel command line - workarounds from the above bug (if it's the same issue)
(In reply to Lukáš Krejčí from comment #8) > What kind of flickering is it? > - Are the contents of the screen flickering or the backlight? it seems like the contents and the backlight are flashing, however, this flashing is very brief. > - Is the whole screen flickering or only a part of it? the whole screen flashes, and contents stay the same with no noticeable artifacts > - Is the flickering constant or does it happen only at random intervals? as far as i'm aware it seems to be sometimes constant and sometime intermittent. i guess it can be true that it is at random intervals > - Does anything trigger it (e.g., a movement on the screen) or does it > happen automatically? loading into the desktop this flickering doesn't seem to happen too often. however, when i start using evloution or chromium it does seem to have more effect on the flashing, meaning that it flashes a bit more. > - Does the flickering also occur when you switch to the framebuffer console > (Ctrl-Alt-F<n>)? it seems to happen whether you are on your desktop or in the console ie alt+ctrl+f2 upwards > > I've seen at least three kinds: > > 1. The whole content of the screen rapidly flickers, non-stop. The > framebuffer console is unaffected. > > 2. The screen shows visual artifacts like flickering black lines triggered > by e.g. scrolling (but not the movement of the cursor); for a video of the > issue, see https://bugs.freedesktop.org/show_bug.cgi?id=110199 > > 3. The backlight flickers randomly for about 30 seconds and then stops until > the next resume from suspend. The flickering also happens on the framebuffer > console. > > In the meantime, I'd try one of these to see if anything changes: > - switching to linux-lts kernel i have seen posts stating that it was the kernel 4.15.x which was without this issue, however, since 4.16 upwards this issue crept in somehow > - setting amdgpu.dc=0 on the kernel command line i have tried this command and i get a black screen on boot > - workarounds from the above bug (if it's the same issue)
Created attachment 285161 [details] dmesg 25-09-2019
very interesting. i have changed to the 4.19.75 lts kernel and the flashing seems to have disappeared. i'll let you know if the flashing returns
i think i might have found the issue with kernel 5.3.1. in kinfocentre while running the kernel 5.3.1 under OpenGL it said the driver was radeon. with kernel 4.19.75-1-lts under OpemGL in kinfocentre it says the driver is amdgpu. i think this might be the problem. the driver probably not being picked up properly
hmmm, with kernel 5.3.1 when i used the radeon driver also i had flashing. however, with kernel 4.19.75-1-lts when using the radeon driver there is no flashing so far. will keep on this. will let you know after some time
i have even done a fresh install of arch linux and installed the lts kernel as the default. this flashing problem has now disappeared completely i'll get you a an application list together for you so you know what's installed. i will also add a dmesg file too, for you to spot differences. they seem to be very different.
Created attachment 285167 [details] My Application List
Created attachment 285169 [details] dmesg done at 9pm 25-sep-2019 - fresh install
looking though my dmesg this morning i found this error: [drm:amdgpu_pci_probe [amdgpu]] *ERROR* Mixing atomic and non-atomic capable GPUs! it might be the fact that i have an APU and a dedicated GPU. i would assume that the driver amdgpu would take care of both of them??
(In reply to John Shand from comment #17) > looking though my dmesg this morning i found this error: > > [drm:amdgpu_pci_probe [amdgpu]] *ERROR* Mixing atomic and non-atomic capable > GPUs! > > it might be the fact that i have an APU and a dedicated GPU. i would assume > that the driver amdgpu would take care of both of them?? i should also mention this is using the 4.19.75 kernel
Created attachment 285185 [details] Patch that restores the previous backlight level rounding mode (In reply to John Shand from comment #17) > looking though my dmesg this morning i found this error: > > [drm:amdgpu_pci_probe [amdgpu]] *ERROR* Mixing atomic and non-atomic capable > GPUs! Linux kernel 4.19 is the last to have this warning (removed by commit 351c4dbe4fae ("drm/amdgpu: Use per-device driver_features to disable atomic")), so it's probably not relevant to this bug. Anyway, I too have a flickering backlight issue on AMD Stoney Ridge, though a different brand of laptop from yours. You may or may not be experiencing the same issue as me. The last kernel without the bug was 4.20. In the 5.0 merge window, there were a few commits that touched the backlight code and I did manage to track down the commit that seems to have introduced the issue: 262485a50fd4 ("drm/amd/display: Expand dc to use 16.16 bit backlight") With it reverted, the backlight was no longer flickering, although I can't really be sure because the issue is sporadic and doesn't happen on every boot. The commit was missing the rounding of the backlight value that was there before. When I removed the rounding again, the issue reappeared. I'm including a smaller commit that applies to kernel v5.3.1 and only adds the rounding back. It is not clear to me why it works, but I haven't encountered any issues so far. You can test it and see if it fixes the issue for you too.
(In reply to Lukáš Krejčí from comment #19) > Created attachment 285185 [details] > Patch that restores the previous backlight level rounding mode > > (In reply to John Shand from comment #17) > > looking though my dmesg this morning i found this error: > > > > [drm:amdgpu_pci_probe [amdgpu]] *ERROR* Mixing atomic and non-atomic > capable > > GPUs! > > Linux kernel 4.19 is the last to have this warning (removed by commit > 351c4dbe4fae ("drm/amdgpu: Use per-device driver_features to disable > atomic")), so it's probably not relevant to this bug. > > Anyway, I too have a flickering backlight issue on AMD Stoney Ridge, though > a different brand of laptop from yours. You may or may not be experiencing > the same issue as me. The last kernel without the bug was 4.20. In the 5.0 > merge window, there were a few commits that touched the backlight code and I > did manage to track down the commit that seems to have introduced the issue: > 262485a50fd4 ("drm/amd/display: Expand dc to use 16.16 bit backlight") > With it reverted, the backlight was no longer flickering, although I can't > really be sure because the issue is sporadic and doesn't happen on every > boot. > > The commit was missing the rounding of the backlight value that was there > before. When I removed the rounding again, the issue reappeared. I'm > including a smaller commit that applies to kernel v5.3.1 and only adds the > rounding back. It is not clear to me why it works, but I haven't encountered > any issues so far. You can test it and see if it fixes the issue for you too. thanks for your hard efforts. really appreciated. would you have an idea when the next 5.3.x kernel will come, because until then, i will continue to use 4.19.75.
(In reply to John Shand from comment #20) > (In reply to Lukáš Krejčí from comment #19) > > Created attachment 285185 [details] > > Patch that restores the previous backlight level rounding mode > > > > (In reply to John Shand from comment #17) > > > looking though my dmesg this morning i found this error: > > > > > > [drm:amdgpu_pci_probe [amdgpu]] *ERROR* Mixing atomic and non-atomic > > capable > > > GPUs! > > > > Linux kernel 4.19 is the last to have this warning (removed by commit > > 351c4dbe4fae ("drm/amdgpu: Use per-device driver_features to disable > > atomic")), so it's probably not relevant to this bug. > > > > Anyway, I too have a flickering backlight issue on AMD Stoney Ridge, though > > a different brand of laptop from yours. You may or may not be experiencing > > the same issue as me. The last kernel without the bug was 4.20. In the 5.0 > > merge window, there were a few commits that touched the backlight code and > I > > did manage to track down the commit that seems to have introduced the > issue: > > 262485a50fd4 ("drm/amd/display: Expand dc to use 16.16 bit backlight") > > With it reverted, the backlight was no longer flickering, although I can't > > really be sure because the issue is sporadic and doesn't happen on every > > boot. > > > > The commit was missing the rounding of the backlight value that was there > > before. When I removed the rounding again, the issue reappeared. I'm > > including a smaller commit that applies to kernel v5.3.1 and only adds the > > rounding back. It is not clear to me why it works, but I haven't > encountered > > any issues so far. You can test it and see if it fixes the issue for you > too. > > thanks for your hard efforts. really appreciated. > > would you have an idea when the next 5.3.x kernel will come, because until > then, i will continue to use 4.19.75. i am also not confident enough yet to recompile a kernel, which is why i'm waiting. with your fix, do the other developers know about it? are they testing it? i use my computer for production
after a little testing of the test kernel for arch linux, i have found that the screen flashing hasn't been solved. this is a very annoying bug. can we please get this sorted with linus torvalds
Unfortunately I have had to go back to kernel 4.19.75 until this flashing issue is resolved. I would rather be using 5.3.2
Can anyone update me on this issue please.
Created attachment 285355 [details] PKGBUILD
(In reply to John Shand from comment #20) > would you have an idea when the next 5.3.x kernel will come, because until > then, i will continue to use 4.19.75. (In reply to John Shand from comment #22) > after a little testing of the test kernel for arch linux, i have found that > the screen flashing hasn't been solved. Upcoming patches should be visible in dri-devel [0] or amd-gfx [1] mailing lists. As far as I know, no patch has been submitted at this time (for the issue I have). (In reply to John Shand from comment #21) > with your fix, do the other developers know about it? are they testing it? I don't know, probably not. This category (Drivers > Video(Other)) does not get resent to the dri-devel [0] mailing list, so chances are that no one from AMD has yet seen it. But really, there's no way to tell. Some bugs here do have a response from AMD. (In reply to John Shand from comment #21) > i am also not confident enough yet to recompile a kernel, which is why i'm > waiting. I've prepared instructions for you to follow to build the patched kernel that you can then test. It's really important to determine whether we have the same issue or not. Because amdgpu.dc=0 did not not do anything for you, you really might be facing a different bug. --- [0] https://lists.freedesktop.org/archives/dri-devel/ [1] https://lists.freedesktop.org/archives/amd-gfx/ --------------------------------- # install the necessary packages sudo pacman -S --needed asp wget # download linux build files to a new 'linux' directory asp update linux asp checkout linux cd linux/trunk # switch to PKGBUILD version 5.3.2.arch2-1 git checkout f1c97a49a09b0fd8d7d1c3f6e8e635ef45974373 # replace the provided PKGBUILD with the one from me # It has three modifications: # 1. applies the patch in this bug report to the kernel sources # 2. modifies MAKEFLAGS to use all available processors to speed up the build # 3. disables compression of the generated packages (a slight speed-up) wget 'https://bugzilla.kernel.org/attachment.cgi?id=285355' -O PKGBUILD # (optional) obtain a shallow clone of the Arch Linux's linux source repo (downloads ~190 MB instead of ~2.3 GB for a full clone) # if this step is skipped, makepkg will automatically download the whole linux repository git clone --depth=1 -b v5.3.2-arch2 'https://git.archlinux.org/linux.git' archlinux-linux # download and install other required dependencies, prepare the kernel sources and build the kernel makepkg -s # install the generated package sudo pacman -U linux-backlight-fix-5.3.2.arch2-1-x86_64.pkg.tar linux-backlight-fix-headers-5.3.2.arch2-1-x86_64.pkg.tar
And one more thing I forgot in the instructions above, the base-devel group needs to be installed (makepkg does not check for that): sudo pacman -S --needed base-devel
what i'm facing at the moment is a pgp key not being recognised. all files with repo are checked and fine. just wonder if i have to setup gpg2
just added the gpg2 key for the kernel maintainter. this should help
coming back with failed result: with the folder archlinux i got signature not found
(In reply to John Shand from comment #30) > coming back with failed result: > > with the folder archlinux i got signature not found so i couldn't go any further. is there a way to turn that off??
Yes, you can run: makepkg -s --skippgpcheck
(In reply to Lukáš Krejčí from comment #32) > Yes, you can run: > makepkg -s --skippgpcheck thaks for that. compiling now. i will let you know more once installed and logged in an hour or so
damn something went wrong, so i deleted the linux folder by mistake and now i can't use asp update linux or asp checkout linux. i get the error 502 each time i run the first command
You should be able to just run `asp checkout linux` without the first (update) command because the PKGBUILD repository is cached in ~/.cache/asp/
hey thanks for your hard work and your patience. your tweak fixed my problem. is there a way you could add this to linux kernel github and apply this patch??
(In reply to John Shand from comment #36) > hey thanks for your hard work and your patience. your tweak fixed my > problem. is there a way you could add this to linux kernel github and apply > this patch?? because i have been compiling the kernel myself with great success, however, i am still having to add your patch to it :(
(In reply to John Shand from comment #37) > (In reply to John Shand from comment #36) > > hey thanks for your hard work and your patience. your tweak fixed my > > problem. is there a way you could add this to linux kernel github and > apply > > this patch?? > > because i have been compiling the kernel myself with great success, however, > i am still having to add your patch to it :( is there a way you can send your patch to the kernel developers??
CAN I ASK WHY THIS PATCH HASN'T BEEN INCLUDED WITH THE KERNEL YET!! it takes my computer along time to compile a kernel everytime there is an update.
Created attachment 285521 [details] Hack to disable backlight fractional duty cycles Please give this patch a shot. We've seen some panels flicker when fractional pwm is enabled. Let me know if this fixes the issue.
(In reply to John Shand from comment #39) > CAN I ASK WHY THIS PATCH HASN'T BEEN INCLUDED WITH THE KERNEL YET!! > All caps sounds yelly on public forums. I'm not sure this was intended. Please keep in mind that Linux is developed partly by volunteers. As for people with company affiliations, they are often not the decision makers and generally work hard to make Linux work as well as possible. Harry
(In reply to Leo Li from comment #40) > We've seen some panels flicker when fractional pwm is enabled. Ah, I see. Commit 3be0a0b85015 ("drm/amd/display: Add switch for Fractional PWM on or off") even mentions it. (In reply to Leo Li from comment #40) > Let me know if this fixes the issue. Thank you for the patch and yes, it does appear to fix the issue. Tested on Ubuntu 19.04, vanilla v5.3.6 kernel with the patch applied, no issues so far after 7 reboots. (The issue could be reproduced on Ubuntu kernel v5.3.6 from kernel-ppa/mailine on first boot.)
I am running the latest version of Arch Linux. i have patched the kernel with the patch given and the problem goes away completely. if i used mainline kernel without patch the system has the flashing issue, and i have also noticed that they system does seem to run slower than it would with the patch applied many thanks
it does work well. however, i have no idea on how to contact these AMD people over this issue. i am not in the know or a developer
(In reply to Leo Li from comment #40) > Created attachment 285521 [details] > Hack to disable backlight fractional duty cycles > > Please give this patch a shot. We've seen some panels flicker when > fractional pwm is enabled. Let me know if this fixes the issue. yes this patch works. thanks for that. is there a way you can include this patch upstream??
(In reply to John Shand from comment #45) > yes this patch works. thanks for that. is there a way you can include this > patch upstream?? Can't include the hack unfortunately, that would indiscriminately disable fractional pwm for all panels. I sent a proper fix here that adds a boot parameter for optionally disabling it: https://patchwork.freedesktop.org/series/68335/#rev3 Add the following to your linux cmdline to disable, and give it a spin! amdgpu.dcfeaturemask=0x4 Please feel free to also add your Tested-by's
(In reply to Leo Li from comment #46) > (In reply to John Shand from comment #45) > > yes this patch works. thanks for that. is there a way you can include > this > > patch upstream?? > > Can't include the hack unfortunately, that would indiscriminately disable > fractional pwm for all panels. I sent a proper fix here that adds a boot > parameter for optionally disabling it: > https://patchwork.freedesktop.org/series/68335/#rev3 > > Add the following to your linux cmdline to disable, and give it a spin! > amdgpu.dcfeaturemask=0x4 > > Please feel free to also add your Tested-by's hi there, with this patch, will i need to apply it everytime a new version of the kernel comes out or, is this patch going to be included with the next upcoming stable versions? i haven't tested it yet, will let you know
(In reply to John Shand from comment #47) > hi there, with this patch, will i need to apply it everytime a new version > of the kernel comes out or, is this patch going to be included with the next > upcoming stable versions? > > i haven't tested it yet, will let you know I applied the change yesterday with Lukáš's Tested-by, and should be mirrored on agd5f/linux soon. It should be included in the next stable release.
(In reply to Leo Li from comment #48) > (In reply to John Shand from comment #47) > > hi there, with this patch, will i need to apply it everytime a new version > > of the kernel comes out or, is this patch going to be included with the > next > > upcoming stable versions? > > > > i haven't tested it yet, will let you know > > I applied the change yesterday with Lukáš's Tested-by, and should be > mirrored on agd5f/linux soon. It should be included in the next stable > release. thanks for working on a more permanent fix. i appreciate it
is there a possible way to detect those LEDs that have an allergy to fractional pwm? if so, perhaps cause an automatic disabling of fractional pwm
since the patch has already been added. i saw that the stable version of the kernel 5.3.8 has just been released. i checked the source for those changes, and couldn't find them applied yet. maybe it is upstream??
(In reply to John Shand from comment #50) > is there a possible way to detect those LEDs that have an allergy to > fractional pwm? if so, perhaps cause an automatic disabling of fractional > pwm I tried the hack last night, and it fixed the issue for me. I will try the kernel parameter tonight (with 5.5.0). The strange thing to me is that I started seeing this issue when I got a new monitor, but it is happening on both screens. The older monitor worked fine before adding the new one. It would certainly be preferable to have a way to detect the LEDs that have the problem, than to make anyone with one of these screens pass a kernel parameter in. If I can provide any help triaging/testing, I would be happy to.
I have this problem (flashing), but I have also the problem described in: https://bugzilla.kernel.org/show_bug.cgi?id=203905 For me the fix by the kernel parameter: amdgpu.dcfeaturemask=0x4 has not fixed the flashing... :(
I have written a Bugreport to Ubuntu, but maybe it has some information for you too: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1861925 If you need more info files please let me know!
(In reply to Patrick McLean from comment #52) > (In reply to John Shand from comment #50) > > is there a possible way to detect those LEDs that have an allergy to > > fractional pwm? if so, perhaps cause an automatic disabling of fractional > > pwm > > I tried the hack last night, and it fixed the issue for me. I will try the > kernel parameter tonight (with 5.5.0). > Could you check the value in the file in your machine: /sys/class/backlight/amdgpu_bl0/actual_brightness Thanks!
the value in that file is 64000 On Sat, 2020-02-15 at 19:39 +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=204957 > > --- Comment #55 from Sandor Ecker (esanya@freemail.hu) --- > (In reply to Patrick McLean from comment #52) > > (In reply to John Shand from comment #50) > > > is there a possible way to detect those LEDs that have an allergy > > > to > > > fractional pwm? if so, perhaps cause an automatic disabling of > > > fractional > > > pwm > > > > I tried the hack last night, and it fixed the issue for me. I will > > try the > > kernel parameter tonight (with 5.5.0). > > > > Could you check the value in the file in your machine: > /sys/class/backlight/amdgpu_bl0/actual_brightness > > Thanks! >
(In reply to Sandor Ecker from comment #55) > (In reply to Patrick McLean from comment #52) > > (In reply to John Shand from comment #50) > > > is there a possible way to detect those LEDs that have an allergy to > > > fractional pwm? if so, perhaps cause an automatic disabling of > fractional > > > pwm > > > > I tried the hack last night, and it fixed the issue for me. I will try the > > kernel parameter tonight (with 5.5.0). > > > > Could you check the value in the file in your machine: > /sys/class/backlight/amdgpu_bl0/actual_brightness > > Thanks! /sys/class/backlight is empty on my machine. To make sure things are clear, this is a desktop machine with a Radeon RX 5700 XT. The monitor that I am seeing this issue with is a Gigabyte Aorus F127Q-P.
Created attachment 287417 [details] hwinfo.txt My computer is a laptop. my graphics card is an APU. i enclosed a file which has my hardware configuration On Sat, 2020-02-15 at 22:16 +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=204957 > > --- Comment #57 from Patrick McLean (chutzpah@gentoo.org) --- > (In reply to Sandor Ecker from comment #55) > > (In reply to Patrick McLean from comment #52) > > > (In reply to John Shand from comment #50) > > > > is there a possible way to detect those LEDs that have an > > > > allergy to > > > > fractional pwm? if so, perhaps cause an automatic disabling of > > fractional > > > > pwm > > > > > > I tried the hack last night, and it fixed the issue for me. I > > > will try the > > > kernel parameter tonight (with 5.5.0). > > > > > > > Could you check the value in the file in your machine: > > /sys/class/backlight/amdgpu_bl0/actual_brightness > > > > Thanks! > > /sys/class/backlight is empty on my machine. To make sure things are > clear, > this is a desktop machine with a Radeon RX 5700 XT. The monitor that > I am > seeing this issue with is a Gigabyte Aorus F127Q-P. >
My machine is a laptop too. Aspire A315-41 https://www.acer.com/ac/en/US/content/support-product/7540?b=1 And can you change the brightness of the laptop display? Is the value of file max_brightness (same directory) 255 too? Thx! (In reply to John Shand from comment #56) > the value in that file is 64000 >
My computer is a laptop too. with Ryzen5 2500. (In reply to John Shand from comment #58) > Created attachment 287417 [details] > hwinfo.txt > > My computer is a laptop. > > my graphics card is an APU. > In this document https://wiki.ubuntu.com/Kernel/Debugging/Backlight there is mentioned a command "sudo fwts" which executes a lot of tests on the system. For my computer the test: FAILED [HIGH] BrightnessOutofRange: Test 1, Actual brightness for amdgpu_bl0 not failed.
Created attachment 287427 [details] results.log here's my results.log file: On Sun, 2020-02-16 at 18:01 +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=204957 > > --- Comment #60 from Sandor Ecker (esanya@freemail.hu) --- > My computer is a laptop too. with Ryzen5 2500. > > (In reply to John Shand from comment #58) > > Created attachment 287417 [details] > > hwinfo.txt > > > > My computer is a laptop. > > > > my graphics card is an APU. > > > > In this document https://wiki.ubuntu.com/Kernel/Debugging/Backlight > > there is mentioned a command "sudo fwts" which executes a lot of > tests on the > system. > > For my computer the test: > > FAILED [HIGH] BrightnessOutofRange: Test 1, Actual brightness for > amdgpu_bl0 > not > > failed. >
Ok, thanks, so at least You have a bit different HW (you: AMD-A9 cpu, me Ryzen5-2500), but the the same issue as me... (In reply to John Shand from comment #61) > Created attachment 287427 [details] > results.log > > here's my results.log file: >
I found this thread after searching for a solution to the flickering-on-resume problem. I have found a workaround and posting it here in case it helps someone else or assists in the diagnosis. Desktop: Gigabyte X570 Aorus Pro Wifi Gigabyte Radeon 5700 XT Samsung 144hz display connected via Displayport Kernel: 5.5.5-arch1-1 #1 SMP PREEMPT Symptom: After `systemctl suspend` and subsequent resume, X display flickers intermittently. This impacts only Xorg, not text consoles. Workaround: xrandr --output DisplayPort-2 --mode 2560x1440 --rate 120.00; xrandr --output DisplayPort-2 --mode 2560x1440 --rate 144.00; resetting the screen refresh rate via xrandr will completely resolve the issue for me.
I have same issue with kernels 5.5.x (latest tested 5.5.6) on xorg/plasma 5 (with opengl rendering) With kernels 5.4.x there is no flickering after resume. Desktop: Gentoo, Mesa 20.0.0, Plasma 5.67.0 Ryzen 9 3900X + Asrock Taichi x570 Saphire Radeon 5700 XT Nitro+ Screen size UHD/4K kernels are build as generic with ebuild sys-kernel/gentoo-kernel
Same issue with kernels 5.5.* (latest tested 5.5.7) also on Xorg/Plasma 5, also with OpenGL rendering. Desktop: Gentoo, Mesa 20.0.0, KDE Frameworks 5.67.0, Plasma 5.17.5 Ryzen 9 3900x Gigabyte Aorus Pro x570 Gigabyte Radeon RX 5700 XT Gaming OC 8GB Screen resolution: FHD Using xrandr doesn't fix it for me.
Using xrandr to change to a lower resolution and then changing back to the default one fixes the issue for me. Thanks Robert for the workaround. What I did on my FHD screen was: xrandr --output HDMI-A-0 --mode 1680x1050 --rate 60.00; xrandr --output HDMI-A-0 --mode 1920x1080 --rate 60.00;