Random monitor flickering and DRM HOTPLUG events on Arch Linux

OnlyMinimum · 2026-05-24 22:51:18

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:

journalctl -b -p warning

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:

amdgpu.dc=0

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.

seth · 2026-05-25 06:49:28

- Cinnamon reorganizes windows
- Windows sometimes move between monitors
…
DRM hotplug events

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.

OnlyMinimum · 2026-05-26 01:29:49

Thanks for the suggestion.

I checked the DPMS state with:

xset q

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:

HOTPLUG=1

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.

seth · 2026-05-26 06:07:55

and got the following output:

Sure this isn't cinnamon on wayland?

xrandr --verbose

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?

OnlyMinimum · 2026-05-26 21:49:20

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

I checked with:

echo $XDG_SESSION_TYPE

and the output is:

x11

Here is the output of:

xrandr --verbose

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:

journalctl -b

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

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

seth · Yesterday 06:34:19

Did you previously block the DPMS module?
You're also crashing in gallium/llvmpipe on a Navi 23 chip
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General and

vulkaninfo --summary

Do you have https://archlinux.org/packages/extra/x8 … an-radeon/ ?

OnlyMinimum · Today 02:40:54

The only DPMS-related test I tried was with:

xset -dpms
xset s off
xset s noblank

However, as shown previously by:

xset q

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.

seth · Today 05:38:54

[   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/'

OnlyMinimum · Today 06:17:00

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 (Today 06:20:53)

seth · Today 06:32:11

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.

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

OnlyMinimum · Today 08:23:57

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:

DPMS is Enabled

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 (Today 20:33:03)

seth · Today 11:30:14

I also tried masking it following the ArchWiki approach:

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?)

Arch Linux

#1 2026-05-24 22:51:18

Random monitor flickering and DRM HOTPLUG events on Arch Linux

#2 2026-05-25 06:49:28

Re: Random monitor flickering and DRM HOTPLUG events on Arch Linux

#3 2026-05-26 01:29:49

Re: Random monitor flickering and DRM HOTPLUG events on Arch Linux

#4 2026-05-26 06:07:55

Re: Random monitor flickering and DRM HOTPLUG events on Arch Linux

#5 2026-05-26 21:49:20

Re: Random monitor flickering and DRM HOTPLUG events on Arch Linux

#6 Yesterday 06:34:19

Re: Random monitor flickering and DRM HOTPLUG events on Arch Linux

#7 Today 02:40:54

Re: Random monitor flickering and DRM HOTPLUG events on Arch Linux

#8 Today 05:38:54

Re: Random monitor flickering and DRM HOTPLUG events on Arch Linux

#9 Today 06:17:00

Re: Random monitor flickering and DRM HOTPLUG events on Arch Linux

#10 Today 06:32:11

Re: Random monitor flickering and DRM HOTPLUG events on Arch Linux

#11 Today 08:23:57

Re: Random monitor flickering and DRM HOTPLUG events on Arch Linux

#12 Today 11:30:14

Re: Random monitor flickering and DRM HOTPLUG events on Arch Linux

Board footer