KWin Crashed Every Time I Fullscreened Edge on My Second Monitor: Direct Scanout Was the Culprit
I ran into a reproducible KWin Wayland crash that happened whenever I fullscreened Microsoft Edge on my secondary monitor.
The strange part was that the monitor itself wasn't disconnecting. The screen briefly went black, KWin crashed, and the desktop came back as if a new display had been connected.
After narrowing down the symptoms, I traced the crash to KWin's direct-scanout path.
The workaround was to disable direct scanout.
The Setup
This happened on a Linux desktop running:
- CachyOS
- KDE Plasma 6
- Wayland
- Hybrid AMD/NVIDIA graphics
- Microsoft Edge
- Two monitors
The secondary display was connected through HDMI and was running at 1920×1080 around 60 Hz.
The primary display was running at a much higher refresh rate.
The problem only appeared when I fullscreened Edge on the secondary monitor.
What Happened
The first thing I noticed was confusing.
I would fullscreen an Edge window on the second monitor and the display would suddenly go black for about a second.
Then KDE recovered and showed a notification that a new display had been detected.
At first, this looked like a display or GPU issue.
But the monitor itself hadn't actually disconnected.
KWin was crashing, restarting, and detecting the displays again.
That distinction turned out to be important.
Reproducing the Crash
The crash was surprisingly consistent.
The sequence was roughly:
- Open Microsoft Edge.
- Move the window to the secondary monitor.
- Enter fullscreen.
- The secondary display goes black.
- KWin crashes.
- The desktop recovers.
- KDE reports that a display was detected again.
I could repeat the same sequence and get the same result.
That made it look repeatable rather than like a one-off crash.
Looking at KWin
I checked the compositor logs after reproducing the problem.
The relevant crash was occurring inside KWin rather than in Edge itself.
The display was also being re-detected after the crash, which explained the misleading "new display detected" behavior.
That narrowed the problem down considerably.
The next question was what KWin was doing differently when a window entered fullscreen.
Direct Scanout
Wayland compositors can sometimes bypass parts of the normal compositing process when a fullscreen surface can be displayed directly on a monitor.
This is called direct scanout.
Normally, the compositor combines the visible surfaces into a final frame and sends that frame to the display.
With direct scanout, a fullscreen surface can potentially be presented directly instead of going through the normal compositing path.
This reduces compositor work and can lower latency.
The problem is that this path interacts with the display and GPU stack differently from normal compositing.
In my case, fullscreening Edge on the secondary monitor appeared to trigger a failure in that path.
The Important Clue
The important clue was the sequence of symptoms:
Fullscreen Edge → black screen → KWin crash → display re-detected
The monitor wasn't physically disappearing.
KWin was failing during the transition into the fullscreen presentation path.
That pointed to the direct-scanout path as the likely failure point.
Testing the Theory
The simplest test was to disable direct scanout and reproduce the same fullscreen action.
I disabled it using the relevant KWin environment/configuration workaround and then tested Edge again.
After that, fullscreening Edge on the secondary monitor stopped crashing the session.
I repeated the same fullscreen action, and the session stayed up.
That gave me a practical way to isolate the problem.
The Workaround
The workaround was to disable direct scanout.
This isn't a universal fix for KWin crashes. It was useful here because disabling the feature removed the specific presentation path that was triggering the crash.
The trade-off is that the compositor has to do more work.
That can slightly increase compositor and GPU usage.
For my setup, that was a reasonable trade-off compared with having KWin crash whenever Edge entered fullscreen on the second monitor.
What I Learned
The confusing part of this bug was that the visible symptom looked like a monitor problem.
The display went black and KDE reported that a display had been connected again.
But the actual failure was KWin.
The useful debugging lesson was to follow the complete sequence instead of assuming the first visible symptom was the cause.
In this case:
Fullscreen
↓
Direct-scanout transition
↓
KWin crash
↓
Display re-detection
Once the crash itself was identified, the display behavior made much more sense.
If You Hit Something Similar
If KWin crashes specifically when fullscreening an application on Wayland, check:
- KWin crash logs
- GPU driver information
- Whether the problem is limited to one display
- Whether it happens only with fullscreen windows
- Whether disabling direct scanout changes the behavior
- Whether the issue is reproducible with another application
Also check whether the problem changes when using different GPU/display combinations on hybrid graphics systems.
Don't immediately blame the monitor just because the screen goes black.
Check the compositor before blaming the monitor.
Environment
My relevant environment at the time of testing included:
OS: CachyOS
Desktop: KDE Plasma 6
Session: Wayland
GPU: Hybrid AMD/NVIDIA
Browser: Microsoft Edge
Primary display: 1920×1080 @ ~180 Hz
Secondary display: 1920×1080 @ ~60 Hz
Your exact behavior may differ depending on your GPU, driver version, display configuration, and KWin version.
Final Takeaway
The crash initially looked like a monitor disconnect.
It wasn't.
The reproducible trigger was fullscreening Edge on the secondary display, and disabling direct scanout prevented the KWin crash on my system.
For now, I'm keeping the environment/configuration change as a workaround rather than treating it as a permanent fix.
The proper long-term solution would be for the underlying KWin/graphics-stack issue to be identified and fixed upstream.
Sources
- KDE / KWin documentation
- Relevant KWin crash logs from the affected system
- Linux graphics/display documentation
- Relevant upstream issue and driver information
Top comments (0)