GNOME Activities Overview workspace thumbnails begin flickering after about 10 minutes of uptime on Ubuntu 26.04 LTS with GNOME Shell 50.1 running on Wayland and Intel Alder Lake-N integrated graphics (i915 driver).
System:
- Ubuntu 26.04 (upgraded from 24.04)
- GNOME Shell 50.1 / Mutter 50.1
- Wayland session (no Xorg session available)
- Intel Alder Lake-N UHD Graphics (i915 driver)
- Three displays (all 1920×1080 @ 60Hz)
Symptoms:
- After about 10 minutes of uptime, GNOME Activities Overview becomes visually corrupted.
- Specifically, workspace thumbnails flicker immediately upon entering Overview (Super key or hot corner).
- The flickering is limited to Overview workspace thumbnails and GNOME top bar. Normal desktop, application windows remain stable and unaffected.
- Exiting Overview immediately returns the desktop to normal. Logging out and back in resolves the issue temporarily, but it returns in a few minutes, rebooting it returns after 10 or 15 minutes. No GPU resets, hangs, or DRM errors appear in journalctl.
I’ve tried:
- Kernel parameter: intel_idle.max_cstate=1 Appears to delay or partially change the symptoms, but the issue still occurs.
- Kernel parameter: i915.enable_dc=0 Initially seemed to reduce symptoms, but the issue still returned.
- Tested different kernels (including older kernel) No change in long-term behavior.
- Disabled a couple of third-party GNOME extensions (still using default Ubuntu extensions).
Observations:
- The issue does not affect application rendering or the desktop outside of Activities Overview.
- It appears only after extended uptime (hours), not immediately after login. - Update - this occurs sporadically, sometimes 10 minutes and some boots it would take a few hours.
- The issue is reproducible across reboots and kernel versions.
- No relevant errors in journalctl related to i915, DRM, or GPU resets.
Question:
Has anyone seen GNOME Activities Overview workspace thumbnail flickering or corruption on GNOME Shell 50 / Mutter 50 under Wayland, particularly on Intel integrated graphics? Are there known issues, workarounds, or logs that I should investigate further?
Update:
I performed additional testing and found a significant correlation with monitor configuration.
With my original multi-monitor setup (2 ASUS monitors + 1 TCL TV), GNOME Shell produced thousands of repeated errors:
gbm_surface_lock_front_buffer failed Failed to query buffer age, got error 3003
These sessions also exhibited Activities Overview flickering, top-panel flickering, and occasional window-edge artifacts.
I have now tested the system with a single display only (different display: Sony TV over HDMI) and the issue has not reproduced. There is no visible flickering, no rendering corruption, and:
journalctl -b | grep -c "gbm_surface_lock_front_buffer failed" 0
journalctl -b | grep -c "Failed to query buffer age" 0
The issue also reproduced across multiple kernels, including a newer mainline kernel Linux 7.0.12-070012-generic, which makes a pure kernel/i915 explanation seem less likely. Using this mainline kernel the symptoms also started appearing after roughly 10 minutes rather than a few hours.
At this point, the strongest lead appears to be a GNOME Shell/Mutter multi-monitor rendering issue, or an interaction involving multiple outputs.
Update (June 22nd):
The issue now consistently appears ~10 minutes after boot (earlier testing likely just didn’t run under full load).
The “unplug/replug” suggestion didn’t help, but it led to a reliable workaround: boot with only the DP 4K display connected, wait a few minutes, then connect the first HDMI display, wait again, then connect the second HDMI display. This results in a stable session and has provided ~20 hours of uptime without flickering or GBM errors.
I’ve reverted all system tweaks and returned displays to:
DP-1: 3840×2160 @ 60Hz, 200% scaling HDMI-1: 3840×2160 @ 60Hz, 200% scaling HDMI-2: 1920×1080 @ 60Hz, 100% scaling
(Previous all at 1080p configuration was part of testing.)
Driver and desktop tests:
Tried Intel Xe driver → same issue Tried KDE Plasma and Budgie → no flickering/GBM errors, but DP 4K display stayed black until forcing 30Hz via CLI (GUI wouldn’t allow it), so I reverted back to GNOME
Current conclusion: GNOME + Intel display stack on this hardware appears unstable only in full 3-display configurations. Any 1–2 display combination is stable for long periods, but stability on 3 displays only occurs with the staged hotplug sequence (DP first, then HDMIs). Adding DP last reliably triggers the issue.
At this point, this is a workaround rather than a fix.
Update (Aug 1st):
After recent kernel and system updates the workaround in my last update quit being viable for me as the issue started returning after about 15 minutes. I read somewhere that changing from fixed to VRR on one or all of your displays might help, only one of my displays supports VRR so I tried that and noticed it immediately stopped the 3003/gbm error flood and flickering and lasted about 17 hours before recurring. When it did, I simply toggled it back off and got another 10 hours or so of error/flicker free uptime. So I then worked with ChatGPT and Google AI to create a script to automate the toggling of VRR for my one monitor that supports it. After several trials and failures I finally got a script that automates this for me and provides a workaround I don't have to manage, I simply let it run in a terminal and check the output to see how many times it has had to execute, I'm currently at 2 days of uptime and the script has executed 6 times sporadically, keeping the canvas stable and flicker free.
To bypass modern GNOME 50 D-Bus sandbox restrictions and resolve the MetaDrmBufferGbm leak without dropping the desktop session, you can force a full hardware graphics pipeline modeset by simultaneously re-asserting your entire multi-monitor coordinate matrix.Below is an automated Bash script that monitors journalctl for the gbm_surface_lock_front_buffer failed flood strings. Once triggered, it uses gdctl to instantly toggle between an equivalent VRR and Fixed refresh rate canvas matrix layout. This forces a clean hardware flush and releases the stale color buffers seamlessly without any visual panel blinks or interface stutter. Adjust the gdctl screen strings to match your unique hardware topology.
#!/bin/bash
START_TIME=$(date +"%b %d %H:%M:%S")
echo "$START_TIME 🚀 Auto-Purge Service started. Monitoring for pesky Mutter 50 buffer floods..."
TOGGLE_STATE=0
COUNT=0
THRESHOLD=3
# We stream live into a reading descriptor
exec 3< <(journalctl -b -f -n 0 | grep --line-buffered "gbm_surface_lock_front_buffer failed")
while read -r line <&3
do
((COUNT++))
if [ $COUNT -ge $THRESHOLD ]; then
LOG_TIME=$(date +"%b %d %H:%M:%S")
echo "$LOG_TIME 🚨 Buffer leak flood detected ($COUNT errors)! Curses!!! Triggering REAL hardware pipeline reset..."
if [ $TOGGLE_STATE -eq 0 ]; then
gdctl set --logical-monitor --monitor HDMI-2 --mode "[email protected]" --scale 1.0 --x 1920 --y 1080 --logical-monitor --monitor HDMI-1 --mode "[email protected]" --scale 2.0 --x 916 --y 0 --logical-monitor --monitor DP-1 --mode "[email protected]" --scale 2.0 --x 0 --y 1080 --primary > /dev/null 2>&1
TOGGLE_STATE=1
echo "$LOG_TIME 🔄 gdctl: Entire layout flipped to FIXED mode -> Buffers Purged!"
else
gdctl set --logical-monitor --monitor HDMI-2 --mode "[email protected]" --scale 1.0 --x 1920 --y 1080 --logical-monitor --monitor HDMI-1 --mode "[email protected]" --scale 2.0 --x 916 --y 0 --logical-monitor --monitor DP-1 --mode "[email protected]+vrr" --scale 2.0 --x 0 --y 1080 --primary > /dev/null 2>&1
TOGGLE_STATE=0
echo "$LOG_TIME 🔄 gdctl: Entire layout flipped to VRR mode -> Buffers Purged!"
fi
echo "$LOG_TIME ⏳ Entering a 30 second Cool Breeze Mode..."
sleep 30
# GHOST PURGE: Read and immediately throw away any backlog lines left over from the flood
while read -t 0.1 -r ghost_line <&3; do
: # Doing nothing dumps the line directly into the trash bin
done
COUNT=0
RESUME_TIME=$(date +"%b %d %H:%M:%S")
echo "$RESUME_TIME 🟢 Cool Breeze Mode finished. Resuming fresh active monitoring..."
fi
done
Use code with caution.
If one of the displays does not support VRR the same result might be achieved by simply changing one display between 60.000 Hz and 59.940 Hz but I haven't tried that as the script above is working great for my situation.
If this quits working for me after additional kernel/system updates or if this is no longer needed I will update this thread, but for now this works great for me.