https://bugs.kde.org/show_bug.cgi?id=525781
Bug ID: 525781
Summary: ksplashqml renders nothing during real Wayland login,
but works fine via --test --window
Classification: Plasma
Product: kwin
Version First 6.7.5
Reported In:
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: wayland-generic
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 196189
--> https://bugs.kde.org/attachment.cgi?id=196189&action=edit
journalctl excerpt from a clean production plasma-ksplash.service run with
qt.qpa.wayland debug logging enabled
SUMMARY
On Gentoo (plasma-workspace 6.7.5, kwin 6.7.5, layer-shell-qt 6.7.5, KDE
Frameworks 6.30.0), the Plasma boot splash (ksplashqml, launched by
plasma-ksplash.service at real Wayland login) never actually appears on screen.
The service runs cleanly for ~1.3s and exits, but nothing is visibly shown,
with every theme tested including stock org.kde.breeze.desktop. Not
theme-specific.
Present since the very first Gentoo install on these machines (not a recent
regression from a specific point release). Reportedly works fine on non-Gentoo
distros with comparable Plasma/KWin versions using the same theme.
ENVIRONMENT
Two independent machines, same symptom:
- Machine A: AMD Ryzen (Granite Ridge APU) + NVIDIA RTX 5070 Ti hybrid, NVIDIA
is DRM master
- Machine B: Intel Xeon E5-2696 v3 + single AMD Radeon PRO W6400 (amdgpu, no
hybrid)
Plasma Wayland session (KWin), not X11.
STEPS TO REPRODUCE
1. Log in to a fresh Plasma Wayland session.
2. Splash is invisible for the ~1-1.5s the session takes to start, regardless
of ksplashrc's configured theme.
3. Compare: "ksplashqml --test --window <theme-path>" run manually from a
terminal inside an already-running session renders the same theme correctly
every time.
WHAT I RULED OUT
- Not theme-specific (custom theme, two versions, plus stock breeze all fail
the same way)
- Not a crash: plasma-ksplash.service exits cleanly every time, no coredump
- Not GPU/driver-specific: identical symptom on AMD-only and AMD+NVIDIA hybrid
- Client does render internally even when invisible:
QT_LOGGING_RULES=qt.qpa.wayland*=true shows normal backingstore
requestUpdate/handleUpdate/deliverUpdateRequest cycles during the run
- Not KWin's per-app Wayland-interface authorization allowlist:
zwlr_layer_shell_v1 is not one of the gated interfaces it denies
- Not missing layer-shell support: layer-shell-qt is installed, ksplashqml
links libLayerShellQtInterface.so.6; libkwin.so.6.7.5 (not the stripped
kwin_wayland binary) contains a full
KWin::LayerShellV1Interface/LayerShellV1Window/LayerShellV1Integration
implementation
- Not the known 6.6.1 "explicit layer surface screen" fix — I'm on 6.7.5, and
confirmed via upstream source that setScreen()/setGeometry()/setVisible(true)
are all called correctly
- No relevant debug output from
kwin_wayland*.debug/kwin_core*.debug/kwin_scene*.debug/qt.qpa.wayland*/qt.qpa.screen*
across a full reboot + fresh login capturing both client and compositor logs
together
KEY FINDING: STARTUP-TIMING RACE
Adding ExecStartPre=/bin/sleep 0.3 to plasma-ksplash.service made no
difference. Adding ExecStartPre=/bin/sleep 2 made the splash render and display
correctly for the first time — confirming this is a startup-timing race, not a
permanently broken code path. But it traded the problem for a worse one: with
the delay, the splash then stayed on screen 10+ seconds before the desktop
appeared (vs. the normal ~1.3s), presumably because delaying ksplashqml's start
makes it miss startplasma-wayland's normal setStage() D-Bus calls (sent on
startplasma-wayland's own independent timeline), so it only ever closes via
ksplashqml's own hardcoded 30s fallback timer or a much later stage signal.
This points to two independently-timed subsystems that aren't synchronized in
this build: (1) KWin's readiness to actually composite a freshly-created
layer-shell surface, and (2) startplasma-wayland's stage-broadcast schedule. No
fixed sleep value can satisfy both — ksplashqml's visibility shouldn't depend
on wall-clock timing relative to startplasma-wayland at all. The sleep
workaround was reverted (worse UX than the original bug), this is offered
purely as diagnostic evidence.
--
You are receiving this mail because:
You are watching all bug changes.
