Dithering patterns stretch throughout the entire monitor

matteodev · 2025-07-14 11:30:31

I am having an issue where horizontal dithering patterns extend across the window. I can't capture it on a screen recording. I am not sure if it's a faulty monitor or cable. I tried a different DP port on my GPU. In the example video I am showing a Windows 2000 VM (lol) because you can see it properly. My monitor connected to HDMI doesn't have this problem.

Video: https://drive.proton.me/urls/BDBG67HVCM#6ihFQN9f4cQF

Operating System: Arch Linux
KDE Plasma Version: 6.4.2
KDE Frameworks Version: 6.16.0
Qt Version: 6.9.1
Kernel Version: 6.15.6-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor
Memory: 64 GiB of RAM (62,4 GiB usable)
Graphics Processor: AMD Radeon RX 7800 XT
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7D70
System Version: 1.0

Monitor is: Gigabyte M27Q connected to the RX 7800 XT via DisplayPort

seth · 2025-07-14 14:24:47

That's not a "dithering pattern", what you see stems from the XOR matrix of the window you're moving around in the VM.
Does it only extend to the left or also the right?

Do you get this w/ KDE/X11 as well? sway/hyprland/weston (pick one, just not kwin_wayland)?

What are the outputs of "kscreen-doctor" and "qdbus6 org.kde.KWin /KWin supportInformation"?
Do you get this when using only one (DP) monitor?
What happens if your flip the monitors and attach the HDMI one to the DP port and vv? Does the dither follow the monitor or stay w/ the connection?
What happens if you run the monitor at a lower resolution or refresh rate?

Ideally also post

for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done

You'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/

kokoko3k · 2025-07-14 17:37:37

I usually get those kind of funky effects when working with crt shaders which emulates phosphor triads, so repeating steep patterns.

Unfortunately it depends on the monitor itself, hoping it is not your case.

matteodev · 2025-07-14 17:37:57

seth wrote:

That's not a "dithering pattern", what you see stems from the XOR matrix of the window you're moving around in the VM.
Does it only extend to the left or also the right?
Do you get this w/ KDE/X11 as well? sway/hyprland/weston (pick one, just not kwin_wayland)?
What are the outputs of "kscreen-doctor" and "qdbus6 org.kde.KWin /KWin supportInformation"?
Do you get this when using only one (DP) monitor?
What happens if your flip the monitors and attach the HDMI one to the DP port and vv? Does the dither follow the monitor or stay w/ the connection?
What happens if you run the monitor at a lower resolution or refresh rate?
Ideally also post
for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done
You'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/

Happens on Hyprland as well.

Tried HDMI and it still had that issue. The other monitor only has HDMI.

kscreen: https://paste.centos.org/view/695d04c7
qdbus: https://paste.centos.org/view/9cd9848e
Command you provided: https://paste.centos.org/view/ebd0a79b

I set the Hz from 170 to 60 and the issue went away, tried other Hz settings like 120, 165 and it still had the issue. So the issue only appears on anyhing over 60 Hz

matteodev · 2025-07-14 17:43:33

2 other things I noticed. This issue also appears on other horizontal lines that have an alternating pattern, like the separators in the comment section of AUR packages.

And there is also a weird flash when opening the shutdown menu of the setup.

Both are recorded: https://drive.proton.me/urls/3VGT4HQGNW#RxuzIj212BOP

matteodev · 2025-07-14 20:32:14

I just noticed the kscreen command still has the ANSI escape codes in there, sorry

kscreen-doctor -o: http://0x0.st/8kmV.txt
qdbus6: http://0x0.st/8kmJ.txt
edid-decode: http://0x0.st/8kmt.txt

seth · 2025-07-14 20:36:53

The other monitor doesn't support higher refresh rates and is actually "just" 1080p@60Hz
The affected one defaults to 1440p@60Hz but also advertises 1440p@165Hz, 1440p@120Hz and 1080p@144Hz
Does the last on (1080p@144Hz) also cause this?
Also the output supports

Display supports continuous frequencies

https://wiki.archlinux.org/title/Variable_refresh_rate
Can you toggle that in the monitors OSD?

matteodev · 2025-07-14 20:46:58

VRR is turned on on both monitors, the second monitor, connected via HDMI, supports 1920x1080@75 Hz. The main monitor with the issue, connected via DP, supports 2560x1440@170 Hz with HDR. And that's what is set in the KDE settings.

One thing that confuses me though, the Arch Wiki mentions VRR is only supported on HDMI 2.1 or later, but the cable I am using is the HDMI cable that shipped with the Nintendo Wii U and that console only supported HDMI 1.4.

1080p@144 Hz doesn't have this issue.

Also this issue appeared yesterday evening. I have this monitor since December 2024 and never had that issue.

seth · 2025-07-14 20:57:01

The edid of the second display doesn't announce VRR and limited to 75Hz it will also not support that (it's basically a magic trick to run high refresh rate outputs at lower rates w/o giving up on the benefits of the high rate)

1080p@144 Hz doesn't have this issue.

The signal is probably too high for the cable(s)
2560x1440@120Hz is < 500MHz, it really still has that effect?

OpenGL renderer string: AMD Radeon RX 7800 XT (radeonsi, navi32, LLVM 20.1.7, DRM 3.63, 6.15.6-arch1-1)

Your system doesn't support HDMI 2.1 (AMD is legally barred from implementing it on linux, you may thank Hollywood for that) - that however doesn't extend to DisplayPort

Also this issue appeared yesterday evening. I have this monitor since December 2024 and never had that issue.

And what happened yesterday afternoon?
Updates? Did your cat pick a fight w/ the cable? Temperature or humidity shift? Lightning?

Last edited by seth (2025-07-14 20:57:09)

matteodev · 2025-07-14 21:08:14

> The edid of the second display doesn't announce VRR and limited to 75Hz it will also not support that (it's basically a magic trick to run high refresh rate outputs at lower rates w/o giving up on the benefits of the high rate)

I had a DisplayPort-to-HDMI cable before for that monitor, but it broke. So I used the next longest HDMI cable I had. but tbh that monitor is basically just for Discord and having open documentation, so 60 Hz won't kill me and I doubt I actually need VRR there. I also redid my cable management last week, the PSU power cable is now quite close to the display cables, but that should be that much of an issue.

> The signal is probably too high for the cable(s) 2560x1440@120Hz is < 500MHz, it really still has that effect?

It wasn't the most expensive cable, the monitor supports DisplayPort 1.2. 2560x1440@120Hz also has this effect. But this effect only occurs on small dithered surfaces, anything else looks just as good.

> And what happened yesterday afternoon? Updates? Did your cat pick a fight w/ the cable? Temperature or humidity shift? Lightning?
I was trying out Bazzite Linux but I ran into a couple of problems so I reinstalled Arch yesterday with my typical Arch KDE Setup.

seth · 2025-07-14 21:16:20

60Hz or 75H, the output will not do VRR, you can configure in the KDE GUI whatever you want.

But this effect only occurs shows on small dithered surfaces, anything else looks just as good.

ftfy

so I reinstalled Arch yesterday with my typical Arch KDE Setup.

Do you get the effect w/ the LTS kernel, the 6.14 kernel and/or KDE on X11?
(Might also be mesa, but xf86-video-amdgpu could augment that)

matteodev · 2025-07-14 21:22:55

I never used the LTS kernel but that would be one thing to try. I wasn't even able to get into X11 KDE earlier, when I logged in, there was simply a black screen, couldn't even switch tty. (sddm is also in Wayland Mode)

seth · 2025-07-14 21:24:56

https://archlinux.org/news/plasma-640-w … re-on-x11/

matteodev · 2025-07-14 21:34:25

I had kwin-x11 and plasma-x11-session installed

matteodev · 2025-07-14 21:42:00

Tried the linux-lts kernel, nothing changed

matteodev · 2025-07-14 21:48:20

The monitor also has a USB-C port for connecting a 2nd device. Could try my ThinkPad running Ultramarine Linux (based on Fedora) and see if it's related to the cable, monitor or the installation.

seth · 2025-07-14 22:06:17

simply a black screen, couldn't even switch tty. (sddm is also in Wayland Mode)

Do you have a system journal covering that attempt?
Also your xorg log and maybe generally configure SDDM for X11 (what compositor are you using fro SDDM/wayland, kwin_wayland?)
This loss of framebuffer control at least doesn't sound good…

see if it's related to the cable, monitor or the installation

If the TP also has a DP output you can check the cable.
For everything else there're too many variables (software, GPU, cable) - but you could try some live distro on the affected system to check whether it's the installation (if the live distro can operate the affected output on the affected cable at full refresh rate)

seth wrote:

Can you toggle [freesync] in the monitors OSD?

matteodev · 2025-07-14 22:43:46

Just did the same test on the TP over USB-C

And I can confidently say the Monitor is probably busted.

seth · 2025-07-15 06:52:47

I can confidently say that I'm probably not your father
"probably" does some heavy lifting here, doesn't?

probably not your father several times wrote:

Can you toggle [freesync] in the monitors OSD?

Do you have other config features (overdrive, smart response, etc. et pp) in the monitor?

matteodev · 2025-07-15 09:14:53

ok yeah it was midnight. But it's most likely an issue with the monitor.

yeah there is a toggle, it's on "FreeSync Premium"

> overdrive

yeah there are multple option, currently set to speed, I already tried setting it to other values but it didn't help

OFF
Smart OD
Picture Quality
Balance
Speed

seth · 2025-07-15 12:53:11

https://www.reddit.com/r/Monitors/comme … _ghosting/
https://extreme.pcgameshardware.de/thre … 690/page-2

The monitor seems to have that, yes…

Arch Linux

#1 2025-07-14 11:30:31

Dithering patterns stretch throughout the entire monitor

#2 2025-07-14 14:24:47

Re: Dithering patterns stretch throughout the entire monitor

#3 2025-07-14 17:37:37

Re: Dithering patterns stretch throughout the entire monitor

#4 2025-07-14 17:37:57

Re: Dithering patterns stretch throughout the entire monitor

#5 2025-07-14 17:43:33

Re: Dithering patterns stretch throughout the entire monitor

#6 2025-07-14 20:32:14

Re: Dithering patterns stretch throughout the entire monitor

#7 2025-07-14 20:36:53

Re: Dithering patterns stretch throughout the entire monitor

#8 2025-07-14 20:46:58

Re: Dithering patterns stretch throughout the entire monitor

#9 2025-07-14 20:57:01

Re: Dithering patterns stretch throughout the entire monitor

#10 2025-07-14 21:08:14

Re: Dithering patterns stretch throughout the entire monitor

#11 2025-07-14 21:16:20

Re: Dithering patterns stretch throughout the entire monitor

#12 2025-07-14 21:22:55

Re: Dithering patterns stretch throughout the entire monitor

#13 2025-07-14 21:24:56

Re: Dithering patterns stretch throughout the entire monitor

#14 2025-07-14 21:34:25

Re: Dithering patterns stretch throughout the entire monitor

#15 2025-07-14 21:42:00

Re: Dithering patterns stretch throughout the entire monitor

#16 2025-07-14 21:48:20

Re: Dithering patterns stretch throughout the entire monitor

#17 2025-07-14 22:06:17

Re: Dithering patterns stretch throughout the entire monitor

#18 2025-07-14 22:43:46

Re: Dithering patterns stretch throughout the entire monitor

#19 2025-07-15 06:52:47

Re: Dithering patterns stretch throughout the entire monitor

#20 2025-07-15 09:14:53

Re: Dithering patterns stretch throughout the entire monitor

#21 2025-07-15 12:53:11

Re: Dithering patterns stretch throughout the entire monitor

Board footer