Hi.

I am experiencing random monitor flickering / display hotplug issues on Arch Linux with an AMD RX6600.

System:

Kernel: 7.0.9-arch1-1
Desktop: Cinnamon (X11)
CPU: Intel i5-4440
GPU: AMD Radeon RX6600
RAM: 16 GB DDR3
Motherboard chipset: Intel H81

Monitor setup:

- Two identical monitors
- One connected directly through HDMI
- Second connected through DisplayPort -> HDMI adapter/cable
- Monitors only have HDMI and VGA inputs

Symptoms:

- Both monitors randomly flicker
- Cinnamon reorganizes windows
- Windows sometimes move between monitors
- Looks exactly like monitor disconnect/reconnect

The problem happens randomly during normal desktop usage.

Test on other systems
This does NOT happen on Windows 10.

I tested Windows 10 for more than 3 hours with no flickers, no monitor disconnects and no instability at all. So i think this seems Linux-specific.

What I found
Running:

udevadm monitor --kernel --property

shows DRM hotplug events exactly when the flickering occurs:

KERNEL[...] change ... /drm/card1 (drm)
ACTION=change
SUBSYSTEM=drm
HOTPLUG=1

I also ran:

and found this warning:

amdgpu 0000:03:00.0: [drm] Failed to setup vendor infoframe on connector HDMI-A-1: -22

Things already tested

- amdgpu.audio=0
- pcie_aspm=off
- removing quiet splash
- different BIOS PEG/PCIe settings
- monitoring:
    journalctl -f
    dmesg -w
    udevadm monitor

I also tried:

but my RX6600 kernel panicked during boot, so I reverted it.

Possible causes I am considering:

- problems in newer kernels?
- AMDGPU DP/HDMI issue?
- passive DP->HDMI adapter incompatibility under Linux?
- Cinnamon/X11 hotplug behavior?

Thanks in advance for any help or suggestions.

The output dis/appear, possibly DPMS triggered. Notably TVs have show to unregister on DPMS but it could also be the adapter.
https://wiki.archlinux.org/title/Displa … figuration
If this is X11 and you cannot override Cinnamons trigger, blocking the module might allow you to test this.

Thanks for the suggestion.

I checked the DPMS state with:

and got the following output:

Keyboard Control:
auto repeat:  on    key click percent:  0    LED mask:  00000002
XKB indicators:
00: Caps Lock:   off    01: Num Lock:    on     02: Scroll Lock: off
03: Compose:     off    04: Kana:        off    05: Sleep:       off
06: Suspend:     off    07: Mute:        off    08: Misc:        off
09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
12: Group 2:     off    13: Mouse Keys:  off
auto repeat delay:  500    repeat rate:  33
auto repeating keys:  00ffffffdffffbbf
fadfffefffedffff
9fffffffffffffff
fff7ffffffffffff
bell percent:  50    bell pitch:  400    bell duration:  100

Pointer Control:
acceleration:  2/1    threshold:  4

Screen Saver:
prefer blanking:  no    allow exposures:  yes
timeout:  0    cycle:  0

Colors:
default colormap:  0x20    BlackPixel:  0x0    WhitePixel:  0xffffff

Font Path:
/usr/share/fonts/misc,
/usr/share/fonts/TTF,
/usr/share/fonts/OTF,
/usr/share/fonts/100dpi,
/usr/share/fonts/75dpi,
/usr/share/fonts/built-ins

DPMS (Display Power Management Signaling):
Server does not have the DPMS Extension

So it seems the X server is not using the traditional X11 DPMS extension in this setup.

Does that rule out DPMS as the source of the hotplug events, or could Cinnamon / DRM / AMDGPU still be doing some kind of power management outside of X11 DPMS?

I am still consistently getting:

events from:

udevadm monitor --kernel --property

exactly when the monitors flicker.

Also, recently the behavior became worse: when the flickering happens, one monitor now sometimes completely turns off and Cinnamon crashes, showing a message that it is going to run in fallback mode.

I also uploaded the relevant journalctl output of:

journalctl -b | grep -Ei "muffin|cinnamon|amdgpu|drm"

right here:
https://paste.c-net.org/SentenceBride

Thanks again for the help and suggestions so far. I really appreciate the troubleshooting guidance. I will continue testing and report back if I find anything new or if one of these tests changes the behavior.

Sure this isn't cinnamon on wayland?

May 25 22:12:44 arch-mkVII systemd-coredump[4500]: Process 1690 (cinnamon) of user 1000 terminated abnormally with signal 11/SEGV, processing...
May 25 22:12:49 arch-mkVII systemd-coredump[4501]: Process 1690 (cinnamon) of user 1000 dumped core.
                                                   #9  0x00007f8406938c92 n/a (libmuffin-cogl-0.so.0 + 0x5dc92)
                                                   #10 0x00007f840692e8d7 cogl_onscreen_swap_buffers_with_damage (libmuffin-cogl-0.so.0 + 0x538d7)
                                                   #11 0x00007f84072e145b n/a (libmuffin-clutter-0.so.0 + 0xc245b)
                                                   #12 0x00007f84072e55aa n/a (libmuffin-clutter-0.so.0 + 0xc65aa)
                                                   #13 0x00007f84072e618a n/a (libmuffin-clutter-0.so.0 + 0xc718a)
                                                   #14 0x00007f84072a24b8 n/a (libmuffin-clutter-0.so.0 + 0x834b8)
                                                   #18 0x00007f8406fb284a meta_run (libmuffin.so.0 + 0xa484a)
                                                   #19 0x000055722499e4c9 n/a (/usr/bin/cinnamon + 0x24c9)
                                                   #22 0x000055722499e695 n/a (/usr/bin/cinnamon + 0x2695)
May 25 22:13:48 arch-mkVII NetworkManager[577]: <info>  [1779758028.3980] agent-manager: agent[d56bba18c0f87cad,:1.64/org.cinnamon.NetworkAgent/1000]: agent registered
May 25 22:13:48 arch-mkVII systemd[1011]: Started dbus-:1.2-org.cinnamon.CalendarServer@1.service.
May 25 22:13:48 arch-mkVII cinnamon-calendar-server[4866]: Traceback (most recent call last):
May 25 22:13:48 arch-mkVII cinnamon-calendar-server[4866]:   File "/usr/lib/cinnamon/cinnamon-calendar-server.py", line 16, in <module>
May 25 22:13:48 arch-mkVII cinnamon-calendar-server[4866]:     gi.require_version('ICal', '3.0')
May 25 22:13:48 arch-mkVII cinnamon-calendar-server[4866]:     ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
May 25 22:13:48 arch-mkVII cinnamon-calendar-server[4866]:   File "/usr/lib/python3.14/site-packages/gi/__init__.py", line 153, in require_version
May 25 22:13:48 arch-mkVII cinnamon-calendar-server[4866]:     raise ValueError(f"Namespace {namespace} not available for version {version}")
May 25 22:13:48 arch-mkVII cinnamon-calendar-server[4866]: ValueError: Namespace ICal not available for version 3.0
May 25 22:13:48 arch-mkVII systemd[1011]: dbus-:1.2-org.cinnamon.CalendarServer@1.service: Main process exited, code=exited, status=1/FAILURE
May 25 22:13:48 arch-mkVII systemd[1011]: dbus-:1.2-org.cinnamon.CalendarServer@1.service: Failed with result 'exit-code'.
May 25 22:14:04 arch-mkVII systemd-coredump[5021]: Process 4684 (cinnamon) of user 1000 terminated abnormally with signal 11/SEGV, processing...
May 25 22:14:09 arch-mkVII systemd-coredump[5022]: Process 4684 (cinnamon) of user 1000 dumped core.
                                                   #9  0x00007ff23649ac92 n/a (libmuffin-cogl-0.so.0 + 0x5dc92)
                                                   #10 0x00007ff2364908d7 cogl_onscreen_swap_buffers_with_damage (libmuffin-cogl-0.so.0 + 0x538d7)
                                                   #11 0x00007ff23691e45b n/a (libmuffin-clutter-0.so.0 + 0xc245b)
                                                   #12 0x00007ff2369225aa n/a (libmuffin-clutter-0.so.0 + 0xc65aa)
                                                   #13 0x00007ff23692318a n/a (libmuffin-clutter-0.so.0 + 0xc718a)
                                                   #14 0x00007ff2368df4b8 n/a (libmuffin-clutter-0.so.0 + 0x834b8)
                                                   #18 0x00007ff2365ef84a meta_run (libmuffin.so.0 + 0xa484a)
                                                   #19 0x000055da3a5114c9 n/a (/usr/bin/cinnamon + 0x24c9)
                                                   #22 0x000055da3a511695 n/a (/usr/bin/cinnamon + 0x2695)

cinnamon crashed twice in 90s, important parts of the backtrace are missing due to the random grep pattern.
Do those crashes coincide w/ the flicker?

No, I am not using Wayland. I am using Cinnamon on X11.

I checked with:

and the output is:

Here is the output of:

https://paste.c-net.org/AirstripPacey

And yes, the Cinnamon crashes do coincide with the monitor flickers.

In fact, the behavior recently became worse.

When the flicker happens now:

* the secondary monitor (the one connected through DP->HDMI) sometimes turns off completely
* Cinnamon crashes and enters fallback mode
* the whole desktop becomes practically unusable
  

At that point, I am forced to physically disconnect the DP->HDMI cable from the secondary monitor to recover the system.

If I leave the cable connected:

* the Cinnamon fallback warning remains on screen
* the primary monitor stays on
* but the desktop becomes frozen/unresponsive
* I cannot properly interact with the system anymore
  

So the crashes definitely seem correlated with the hotplug/flicker events.

Also, I will upload the complete:

https://paste.c-net.org/TargetsFluid

output without grep filtering, since the previous logs may have hidden important parts of the backtrace.

The only DPMS-related test I tried was with:

xset -dpms
xset s off
xset s noblank

However, as shown previously by:

the X server reports:

DPMS (Display Power Management Signaling):
Server does not have the DPMS Extension

So I did not explicitly disable or block any Cinnamon xrandr/DPMS module beyond that.

I also collected the requested logs/output.

Xorg.1 log:
https://paste.c-net.org/ClothesStakeout

Xorg.0 log:
https://paste.c-net.org/BracketMomma

Vulkan summary:
https://paste.c-net.org/StaplePurity

glxinfo -B:
https://paste.c-net.org/IncidentExtended

I included the complete glxinfo -B output as extra information because I thought it might help diagnose the issue.

[   994.152] (**) Extension "DPMS" is disabled

grep -ri dpms /{etc,usr/share}/X11/xorg.conf*

MESA: info: vulkan: No DRI3 support detected - required for presentation
Note: you can probably enable DRI3 in your Xorg config

[   994.174] (II) Applying OutputClass "AMDgpu" options to /dev/dri/card1
[   994.174] (II) Loading sub module "dri2"
[   994.174] (II) LoadModule: "dri2"
[   994.174] (II) Module "dri2" already built-in
[   994.346] (==) AMDGPU(0): DRI3 disabled
[   994.404] (WW) AMDGPU(0): Option "HotplugDriver" is not used
[   994.406] (II) Initializing extension DRI3
[   994.406] (II) AIGLX: Screen 0 is not DRI2 capable
[   994.412] (II) GLX: Initialized DRISWRAST GL provider for screen 0

[   994.218] (II) AMDGPU(0): glamor: Using OpenGL 4.5 context.
[   994.218] (II) AMDGPU(0): Refusing to try glamor on llvmpipe
[   994.219] (EE) AMDGPU(0): glamor detected, failed to initialize EGL.
[   994.219] (WW) AMDGPU(0): amdgpu_glamor_pre_init returned FALSE, using ShadowFB

pacman -Qikk xorg-server xf86-video-amdgpu mesa llvm-libs
grep -r . /{etc,usr/share}/X11/xorg.conf*

Andplease  post your complete system journal for the boot:

sudo journalctl -b | curl -s -H "Accept: application/json, */*" --upload-file - 'https://paste.c-net.org/'

I still have the original flickering/present issue, especially after enabling the second monitor.
I have also experienced several complete system freezes during all this troubleshooting, including freezes inside Cinnamon, i3wm, and even occasional freezes directly in the TTY.
In several of those cases the system became completely unresponsive, forcing me to hold the physical power button to shut the machine down and boot it again.
This whole issue made me very restless, so I kept investigating further after reading your hints. However, thanks to your hints about DRI3, llvmpipe and the Xorg logs helped me narrow things down until I eventually found the broken Mesa overrides.

I discovered that my system was incorrectly falling back to `llvmpipe` instead of properly using the RX 6600 under X11.

I found these leftover overrides from old troubleshooting attempts:

MESA_LOADER_DRIVER_OVERRIDE=crocus
MESA_GL_VERSION_OVERRIDE=4.5

The first one was in `/etc/environment`, and the OpenGL override was in my shell configuration.

After removing them and rebooting, `glxinfo -B` now correctly reports:
https://paste.c-net.org/PrevailNichols

OpenGL renderer string: AMD Radeon RX 6600 (radeonsi, navi23, ACO, DRM 3.64, 7.0.9-arch1-1)

instead of `llvmpipe`.

So while the original flickering issue is still happening, at least now the RX 6600 is properly being used by X11 instead of software rendering.

Here are the requested logs and command outputs:

grep -ri dpms /{etc,usr/share}/X11/xorg.conf*:

/etc/X11/xorg.conf.d/10-extensions.conf:    Option "DPMS" "false"

pacman -Qikk xorg-server xf86-video-amdgpu mesa llvm-libs: is on following link:
https://paste.c-net.org/BobbiMatty

grep -r . /{etc,usr/share}/X11/xorg.conf*: is on following link:
https://paste.c-net.org/EnjoyedObserver

Full system journal: is on following link:
https://paste.c-net.org/TrumpedFishes

Thanks again for all the guidance so far — your hints about DRI3, llvmpipe and the Xorg logs were what led me to discover the broken Mesa overrides in the first place.

Last edited by OnlyMinimum (2026-05-28 06:20:53)

So it's not just indicating the cinnamon crashes
Does it coincode w/

May 28 02:28:16 arch-mkVII cinnamon-calendar-server[3604]:     gi.require_version('ICal', '3.0')
May 28 02:28:32 arch-mkVII cinnamon-calendar-server[4210]:     gi.require_version('ICal', '3.0')
May 28 02:29:06 arch-mkVII cinnamon-calendar-server[5588]:     gi.require_version('ICal', '3.0')
May 28 02:46:41 arch-mkVII cinnamon-calendar-server[8660]:     gi.require_version('ICal', '3.0')
May 28 03:07:23 arch-mkVII cinnamon-calendar-server[10918]:     gi.require_version('ICal', '3.0')

that process failing (and oes it help to mask usr/share/dbus-1/services/org.cinnamon.CalendarServer.service, https://wiki.archlinux.org/title/D-Bus# … us_service )
Otherwise, what happens if you re-enable DPMS?
Do you remember why you introduced

/etc/X11/xorg.conf.d/10-extensions.conf:Section "Extensions"
/etc/X11/xorg.conf.d/10-extensions.conf:    Option "DPMS" "false"
/etc/X11/xorg.conf.d/10-extensions.conf:EndSection
/etc/X11/xorg.conf.d/10-serverflags.conf:Section "ServerFlags"
/etc/X11/xorg.conf.d/10-serverflags.conf:    Option "BlankTime" "0"
/etc/X11/xorg.conf.d/10-serverflags.conf:EndSection

The cinnamon-calendar-server failures sometimes appear to coincide temporally with some of the monitor flickers, although I still cannot say for sure whether they are actually related or just happening around the same time.

I also tried checking the service status directly, but it does not seem to exist as a regular systemd user unit:

$ systemctl --user status org.cinnamon.CalendarServer.service
Unit org.cinnamon.CalendarServer.service could not be found.

I also tried masking it following the ArchWiki approach:

sed -i 's|^Exec=.*|Exec=/bin/false|' .local/share/dbus-1/services/org.cinnamon.CalendarServer.service

but even after doing that, the cinnamon-calendar-server failures still continue to appear in journalctl.
https://paste.c-net.org/DefconWreaking

I also re-enabled DPMS by reverting the old Xorg configuration changes I had in:

/etc/X11/xorg.conf.d/10-extensions.conf
/etc/X11/xorg.conf.d/10-serverflags.conf

Those files were old tweaks from years ago, when I was still using only the i5-4440 iGPU with i3wm and had read recommendations on the ArchWiki/forums about disabling DPMS and screen blanking for X11/i3 setups.

After reverting those settings, `xset q` now reports:

However, re-enabling DPMS did not solve the flickering/presentation issue.

I also collected live monitoring logs while observing the flickers:

dmesg live log:

sudo dmesg -w | ts '[%Y-%m-%d %H:%M:%S]' | tee dmesg-live.log

https://paste.c-net.org/GearingUsually

----------------------------------------------------------------------------

RANDR live events:

xev -root -event randr | ts '[%Y-%m-%d %H:%M:%S]' | tee randr-live.log

https://paste.c-net.org/CleggAnswers

----------------------------------------------------------------------------

udev live events:

udevadm monitor --kernel --property | ts '[%Y-%m-%d %H:%M:%S]' | tee udev-live.log

https://paste.c-net.org/NecksChemical

Last edited by OnlyMinimum (2026-05-28 20:33:03)

There's no user service, the daemon is dbus triggered.

[2026-05-28 04:41:56]     output DP-3, crtc 62, mode 1920x1080 (1920x1080)
[2026-05-28 04:41:57]     output DP-3, crtc None, mode None
[2026-05-28 04:41:57]     output DP-3, crtc None, mode None
[2026-05-28 04:42:00]     output DP-3, crtc None, mode None
[2026-05-28 04:42:00]     output DP-3, crtc None, mode None
[2026-05-28 04:42:00]     output DP-3, crtc 62, mode 1920x1080 (1920x1080)
[2026-05-28 05:07:48]     output DP-3, crtc 62, mode 1920x1080 (1920x1080)
[2026-05-28 05:07:48]     output DP-3, crtc None, mode None
[2026-05-28 05:07:48]     output DP-3, crtc None, mode None
[2026-05-28 05:07:51]     output DP-3, crtc None, mode None
[2026-05-28 05:07:52]     output DP-3, crtc None, mode None
[2026-05-28 05:07:52]     output DP-3, crtc 62, mode 1920x1080 (1920x1080)
[2026-05-28 05:16:41]     output DP-3, crtc 62, mode 1920x1080 (1920x1080)
[2026-05-28 05:16:42]     output DP-3, crtc 62, mode 1920x1080 (1920x1080)
[2026-05-28 05:16:42]     output DP-3, crtc None, mode None
[2026-05-28 05:16:45]     output DP-3, crtc None, mode None
[2026-05-28 05:16:45]     output DP-3, crtc None, mode None
[2026-05-28 05:16:45]     output DP-3, crtc 62, mode 1920x1080 (1920x1080)

The connection on that monitor flickers, HDMI-1 seems stable - do you get this w/ only using the HDMI-1 output?
Do you have another DP jack on the GPU and DP cable? Can you try to flip the monitors around (ie. does the flicker follow the monitor or the output?)

Sorry about the confusion regarding the CalendarServer masking attempt — I realized afterwards that I had misunderstood how that daemon is started. I edited my previous post to improve the clarity and avoid spreading incorrect information.

Regarding the outputs: yes, if I use only the monitor connected to HDMI-1, I do not get any visible flickering/presentation problems.

However, while testing with only HDMI-1 connected, I still observed HOTPLUG events being reported. In that configuration I did not notice any monitor flicker despite the HOTPLUG activity.

With only the monitor connected through DP-3, I also observed HOTPLUG events, but in that case the monitor did visibly flicker.

My RX 6600 has 3 DP outputs and 1 HDMI output. Right now I am using:

* one monitor directly through HDMI -> HDMI
* the second monitor through a DP -> HDMI adapter cable

Both monitors are identical models and only support VGA and HDMI inputs. They are also relatively new monitors.

Unfortunately I only have:

* this single DP -> HDMI adapter cable (recently purchased)
* the HDMI -> HDMI cable that came with the first monitor
* and another spare HDMI -> HDMI cable that came with the second monitor

But since the GPU only has one HDMI output, the spare HDMI cable is currently unused.

I also tried swapping the monitors around. After reversing the monitor/cable assignment, both monitors still flickered, so at least from this test the problem does not appear to be tied to a specific monitor.

One additional detail: when both monitors are connected, both screens flicker simultaneously.

My money is on the adapter - are you running either output at 100Hz?
Are things stable if running the monitor behind the adapter at XGA (1024x768@60Hz)?

No, both monitors are running at 1920x1080 @ 60 Hz.

I tested your suggestion by setting both monitors to 1024x768 @ 60 Hz, but the flickering still occurred.

What I find particularly strange is that, as I mentioned earlier, I used this same hardware under Windows 10 for several hours with the dual-monitor setup and did not experience any flickering or display interruptions.

At the moment, the issue continues to occur under Linux regardless of whether the monitors are running at 1920x1080 @ 60 Hz or 1024x768 @ 60 Hz.

I also collected another set of logs while testing the system with both monitors connected and in use with 1024x768 @ 60 Hz. I'll attach them below:

udev monitor log:

udevadm monitor --kernel --property | ts '[%Y-%m-%d %H:%M:%S]' | tee udev-live_4p3.log

https://paste.c-net.org/NamelyRambling

---

randr events log:

xev -root -event randr | ts '[%Y-%m-%d %H:%M:%S]' | tee randr-live_4p3.log

https://paste.c-net.org/MeyersKrueger

Last edited by OnlyMinimum (2026-05-29 17:35:16)

Does it help to limit power saving?
"intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1"

How do the outputs behave on non-cinnamon? (Eg. icewm will do - it's to check whether some cinnamon-related daemon triggers some power saving or so)

First of all, sorry for my absence. I ran into some motherboard-related issues and had to RMA it and take it to a repair center, so I was without a working computer for a while.

Regarding the tests:

1. I tried the kernel parameters you suggested:

intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1

Unfortunately the monitors continued to flicker, so I reverted those changes.

2. I also tested with i3wm, which is the window manager I have installed.

While running i3wm, only the monitor connected through DisplayPort would flicker. Originally it was connected through DP-3, and only that monitor would flicker.

To rule out a faulty DP connector on the GPU, I moved the DisplayPort-to-HDMI adapter from DP-3 to DP-1.

After doing that, the behavior followed the connection: only the monitor connected through DP-1 flickered.

The logs show the same pattern as before: the output disappears, the EDID is removed, a HOTPLUG event is generated, and then the monitor reconnects.

This seems to suggest that the issue is not tied to a specific DisplayPort connector on the GPU, since the problem occurred on both DP-3 and DP-1.

I'll attach the corresponding logs below.

RANDR events (DP-1):
https://paste.c-net.org/SummonsBowie

udev events (DP-1):
https://paste.c-net.org/StrungCouture

It rather follows the monitor ?
Is the monitor stable when using it w/ the HDMI/HDMI cable?

Yes, the monitor appears stable when connected directly through an HDMI-to-HDMI cable.

Both monitors are identical models, and when a monitor is connected directly to the GPU's HDMI output I do not observe the disconnect/reconnect behavior seen on the DisplayPort-to-HDMI path.

What I have observed so far is:

Monitor connected through HDMI -> stable

Monitor connected through DisplayPort-to-HDMI adapter
-> flickers
-> EDID is removed
-> HOTPLUG events
-> DP disconnect/reconnect events

And I have performed the monitor swap test.

I swapped the monitors while keeping the connection types unchanged. After swapping them, the behavior did not follow a specific monitor.

The monitor connected through the DisplayPort-to-HDMI adapter continued to flicker, while the monitor connected directly through HDMI remained stable.

Since both monitors exhibit the same behavior depending on which connection they use, this seems to suggest that the issue follows the DisplayPort-to-HDMI connection path rather than a particular monitor.

Other additional tests I made:

Today I tested the same DisplayPort-to-HDMI adapter on a different machine at work for several hours.

System information:

OS: Red Hat Enterprise Linux 8.10
Kernel: 4.18.0-553.124.1.el8_10.x86_64
GPU: NVIDIA GeForce RTX 4060
DE: KDE Plasma 5.24.7 (KWin)

I started using it around 12:00 and have not observed any monitor flickering so far.

This does not completely rule out the adapter, since the hardware and software stack are very different from my home system, but it does suggest that the adapter is at least capable of operating stably in another Linux environment.

Given these results, do you know of any AMDGPU parameters or debugging options related to:

1. DisplayPort link training

2. DisplayPort hotplug detection

3. AMD Display Core (DC)

4. MST (Multi-Stream Transport)

5. DisplayPort-to-HDMI adapters

At this point I'm wondering whether this could be an AMDGPU-specific interaction with the DP-to-HDMI connection path rather than a purely hardware fault.

Does adding "amdgpu.dcdebugmask=0xa17" to the https://wiki.archlinux.org/title/Kernel_parameters help with this? (this disables multiple things, incl. dsc)
There's famously https://wiki.archlinux.org/title/AMDGPU … white/gray but I'm not sure how this would apply here.

Do you btw get this w/ the lts kernels (6.18 or some much older ones are available in the AUR) or some live distro like grml.org?

I also tested some AMDGPU kernel parameters suggested in the following troubleshooting guide:

https://gist.github.com/danielrosehill/ … dea50e1507

Specifically:

amdgpu.gpu_recovery=1
amdgpu.dcdebugmask=0xa17
amdgpu.gfx_off=0
amdgpu.runpm=0

I tested them individually and in combination, but the monitor disconnect/reconnect issue still occurred.

At this point I can reproduce the issue with:

linux 7.0.12
linux-lts 6.18.35
linux-lts61 6.1.175

as well as with multiple AMDGPU parameter combinations.

However, I performed another test using a GRML live environment on the same machine, with the same RX6600, the same monitors and the same DP->HDMI adapter. So far I have not observed any monitor flickering or DP disconnect/reconnect events under GRML.

I am currently comparing the software stack between Arch Linux and GRML to identify any relevant differences.