https://bugs.kde.org/show_bug.cgi?id=517570
Bug ID: 517570
Summary: First Plasma Wayland session starts before Thunderbolt
eGPU/NVIDIA is ready, causing choppy rendering until
re-login
Classification: Plasma
Product: kwin
Version First unspecified
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: wayland-generic
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
On Fedora 44 with Plasma Wayland, booting with a Thunderbolt eGPU already
attached can leave the first graphical session in a broken/choppy state if
Plasma starts before the eGPU finishes enumerating and nvidia-drm is
initialized.
This started immediately after a `dnf update --refresh` on 2026-03-14. In that
transaction, the NVIDIA stack was updated from `590.48.01` to `595.45.04`, the
kernel was updated from `6.19.6-300.fc44` to `6.19.7-300.fc44`, and many KDE
Frameworks packages were updated from `6.23.x` to `6.24.0`. So the regression
window is clear, but I cannot attribute it to the NVIDIA driver alone from
local testing.
Hardware:
- Intel NUC12WSKi5
- Razer Core X (Thunderbolt 3)
- NVIDIA GeForce RTX 3090
Software:
- Fedora 44
- kernel 6.19.7-300.fc44.x86_64
- plasma-workspace 6.6.2-1.fc44
- kwin 6.6.2-2.fc44
- NVIDIA 595.45.04
Observed behavior:
- First Plasma Wayland session after boot is visibly choppy on the
eGPU-connected displays
- KWin logs repeated:
- GL_INVALID_ENUM error generated. Invalid <face>.
- Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
- Logging out and back in fixes the problem immediately
Expected behavior:
- Plasma/KWin should either wait until the eGPU stack is ready before bringing
up the session, or recover cleanly if the Thunderbolt eGPU becomes available a
few seconds after session startup
Relevant timing from a bad boot:
- 17:56:53 plasmalogin starts
- 17:56:55 plasma-kwin_wayland starts
- 17:56:59 Razer Core X finally appears
- 17:57:00 NVIDIA module starts loading
- 17:57:02 nvidia-drm initializes
- 17:57:08 KWin starts spamming the GL/framebuffer errors
A local workaround that delays Plasma startup until the eGPU is stable fixes
the issue consistently, and after that glxinfo -B resolves to NVIDIA
immediately on first login. That suggests a KWin/Plasma startup ordering or
recovery issue rather than a general NVIDIA failure.
--
You are receiving this mail because:
You are watching all bug changes.
