I’m experiencing a strange glitching issue on my AMD FW13 with the 7840 that only seems to affect externally-connected monitors. I haven’t found any reference to quite the same sort of issue in the forums.
This does not look to me like a purely hardware issue as it only affects parts of the screen at any given time. The regions occupied by GDE bars on the side and top, for instance, don’t seem to be impacted at all. What happens looks to me like bits of an earlier framebuffer flashing in at random places. Mostly it will be over whatever parts of the desktop aren’t covered by the currently active window, but the currently active window will also glitch quite a lot. Sometimes large portions of the screen will become like a strobe light for 10-15 seconds at a time. It’s less noticeable in regions that are playing video, but even that will occasionally “stutter,” seeming to flash an earlier frame up momentarily every 10 seconds or so. For whatever reason, Google Chrome seems to bring out this behavior most, but any window brought to the external monitor will exhibit this issue before long.
This happens in Unity and Gnome with or without Wayland.
So far I’ve seen this on one LG monitor connected directly via an HDMI module, and the same monitor connected via a Lenovo TB3 dock using either HDMI or DisplayPort. I don’t currently have a DP module or a type-c to DP or HDMI adapter available to test. I’m running the OEM kernel 22.214.171.1245-oem.
My best guess right now is a driver or firmware issue. It looks like the graphical flashes I’m getting contain parts of a video framebuffer from the same screen. I’d say maybe there’s a refresh rate or v-sync issue, but it never affects the whole screen, only specific draw regions.
FWIW, I also have an Asus laptop with RDNA3 graphics on a 7940, but it does not have the same issue. (It has plenty of other issues the Framework doesn’t have.) For reference, that’s running a locally-compiled 6.3.5 kernel.
Has anyone else experienced this issue or know what might solve it?
The external monitor through the docking station is my primary use case for a laptop, and it’s currently unusable for that purpose, so any help solving this issue would be much appreciated.
Without a photo, I am speculating here. But it sounds like it may be related to this thread.
If this is related, this will help with a firmware fix coming as well.
Thanks for the help. I tried the
amdgpu.sg_display=0 kernel parameter and it visibly improved the situation. I’d say the flickers are about 25% as prevalent now as they were without it.
So, it’s likely related as you said, although in my case it’s only showing up on the external monitor, not the built-in, and I’m running 22.04 with the oem kernel.
Let me know if it will help to upload a video of if there’s any other info or troubleshooting that’s useful for me to do. What I’m seeing now is not exactly like the other user’s glitches, but it’s similar enough. Before the kernel parameter the glitches were sometimes taking most of the screen similar to the other user’s video.
For now, Thanks! This makes the machine mostly usable for me and I can wait hopefully for the firmware fix to make its way to Ubuntu.
Appreciate it. If you able to send your experience to this tracker, this is where the resolution will becoming through as they feed in the fix with the OEM C kernel. Issues · drm / amd · GitLab
Thanks, I’ve added a report to the link provided.
Just a small update here: this seems to be some sort of initialization issue. The problem happens on a cold boot, or on a warm reboot without the external monitor connected. If it warm reboots with the monitor connected, there’s no flicker. After a lot of troubleshooting and trying a new graphics unit firmware build, I discovered this.
I still think it must go back to the display drivers or firmware, but thought I’d mention it here too, in case anyone else has a similar problem.
Appreciate it. Anything newly discovered, please, please add it to the existing report.
Hrm - I wonder if this is EDID training issues?
Maybe dump the Monitors EDID from a ‘good’ state to a bin and add it into the initramfs as a KMS overide for the output and see if you continue to get the behaviour.
Other lower effort root cause things to check ;
Use Display Port v HDMI and vs versa
Swapping cables, DisplayPort, HDMI, and variants: previously accomplished. No change observed.
Re: dumping EDID and adding KMS override, I’d be willing to try that. Could you link to/outline the procedure?
Update: I just installed the 6.1.0-1026-oem kernel from the repo and it made a small improvement. Now if I cold boot with the dock or external monitor plugged in, I get no flicker. I don’t have to warm reboot.
If I cold boot without the external monitor connected, then I connect the monitor, it still flickers.
It’s a minor change, but still an improvement. I guess there must’ve been some revision to the graphics drivers in the most recent oem kernel.
It sounds like cable/converter and training issues to me. I get similar flickering on my RDNA3 Desktop GPU from the DP → HDMI conversion path (DP-> DP-in → DP-ALT over USB-C → HDMI) which is currently the only way to support HDMI2.1 4K@120hz under linux due to HDMI consortia issues with FRR mode implementations in the Open and AMD/INTEL being scared to put implementations of FRR into open source code bases.
Arch wiki has a good step by step on adding edid to kernel initramfs for overides during boot : Kernel mode setting - ArchWiki