Bug 514351 - startplasma-wayland takes a few seconds before the wallpaper shows
Summary: startplasma-wayland takes a few seconds before the wallpaper shows
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Startup process (other bugs)
Version First Reported In: 6.5.4
Platform: Gentoo Packages Linux
: NOR minor
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL: https://youtu.be/HRsYz4b0Tdo
Keywords: efficiency-and-performance
Depends on:
Blocks:
 
Reported: 2026-01-08 21:19 UTC by Jakub Ondrusek
Modified: 2026-01-14 00:01 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
output of the ecommand above (42.08 KB, text/plain)
2026-01-08 21:19 UTC, Jakub Ondrusek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Ondrusek 2026-01-08 21:19:39 UTC
Created attachment 188336 [details]
output of the ecommand above

SUMMARY

When I start Plasma with Wayland I experience a 2-4 second delay on starting and tearing down the session when the display looks as if it is off. This is more of an annoyance, with X there is no delay, so if I use the same wallpaper picture for SDDM background + Plasma Splash Screen + Plasma desktop, the switches are instant and seamless. With Wayland (SDDM on Wayland / on X regardless) my display turns off for 2-4 seconds.

I am more than happy to provide any information, update packages re-compile the kernel with different options or apply patches if it helps anyone.

I do not experience this when I run Plasma on X (everything is instant). I do not experience this with Weston on Wayland (everything is instant).

This happens consistently and doesn't seem to be affected by anything else.

The logs suggest that the internal eDP panel is briefly removed and re-added by the kernel during early modesetting: kwin_wayland_drm: Removing output … name="eDP-1" This forces the compositor to tear down and revalidate DRM state, causing a visible delay.

STEPS TO REPRODUCE
1. To isolate this issue from SDDM I stop any SDDM / greeter service
2. I start the kwin session manually from the console: KWIN_DRM_TIMINGS=1 KWIN_LOGGING=1 QT_LOGGING_RULES="kwin_*.debug=true" dbus-run-session kwin_wayland --exit-with-session konsole 2>&1 | ts '[%H:%M:%S]' | tee kwin_wayland.txt

OBSERVED RESULT

After I login and start the session from SDDM (Runs on Wayland) I experience a 2-4 second delay with black screen. This happens consistently at the beginning and at the end of my kwin_wayland session. It does not happen when I run kwin on X11. It is not affected by using or not using a splash screen.

EXPECTED RESULT

There is a seamless transition from SDDM to kwin without a black screen or flicker.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: 
KDE Plasma Version: 6.5.4
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.1

ADDITIONAL INFORMATION

CPU: AMD Ryzen AI 7 PRO 350 w/ Radeon 860M (microcode 0xb600037)
GPU: c4:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Krackan [Radeon 840M / 860M Graphics] (rev d2)
System Memory: 32GB SO-DIMM DDR5-5600
Display(s): OLED 2880x1800@120
Type of Display Connection: eDP
Distro name and Version: Gentoo
Kernel version: 6.18.3-gentoo-gentoo-dist #1 (closed) SMP PREEMPT_DYNAMIC
Kernel commandline: amdgpu.dc=1 amdgpu.modeset=1
Linux Firmware: 20251125
Comment 1 Jakub Ondrusek 2026-01-09 10:25:04 UTC
I recorded the behaviour and uploaded a video: https://youtu.be/HRsYz4b0Tdo
Comment 2 Zamundaaa 2026-01-09 14:01:49 UTC
> KWIN_DRM_TIMINGS=1 KWIN_LOGGING=1
Where did you find those environment variables? They don't do anything.

> amdgpu.dc=1 amdgpu.modeset=1
Same here with the kernel arguments, amdgpu.modeset doesn't exist afaik. amdgpu.dc=1 is the default (and only allowed configuration) for your hardware.

For the actual issue, the "removing output ..." line is probably just from KWin quitting, there's no "New output on GPU ..." afterwards for adding the output again.

Is your SDDM running in Xorg, or kwin_wayland? Switching from Xorg or another compositor to KWin (and vice versa) will change the bit depth and may require a modeset, which is the blanking you see. It shouldn't take that long on a laptop display, but that's all on the driver side and not something we can influence.

Also, please attach the output of
> kscreen-doctor -o
in the session.
Comment 3 Jakub Ondrusek 2026-01-09 17:35:21 UTC
Thanks for the response, much appreciated! I was helpless so I actually tried anything I could google and didn't really check (I won't make that mistake again so I do apologise for adding confusing (potencially made-up arguments to the conversation).

> Is your SDDM running in Xorg, or kwin_wayland? 
My SDDM is running on Wayland. I tried to take SDDM out of the equation by running the kwin_wayland command from the console directly and the screen turns of for those 2-4 seconds on kwin startup AND kwin teardown anyway.

When I run kwin_x11, it starts immediately without the black screen. When I run SDDM on X11 and start a kwin_x11 session from SDDM, it is also seamless (see attached video youtube link https://youtu.be/HRsYz4b0Tdo).

I do not believe this has anything in common with SDDM, I am including the video just to document what behaviour I was used to before Wayland.

> Also, please attach the output of
> kscreen-doctor -o

> Output: 1 eDP-1 c60511c1-6abd-4834-8ff5-17c2b940be33
>        enabled
>        connected
>        priority 1
>        Panel
>        replication source:0
>        Modes:  1:2880x1800@60.00!  2:2880x1800@120.00*  3:1920x1200@60.00  4:1920x1080@60.00  5:1600x1200@60.00 6:1680x1050@60.00  7:1280x1024@60.00  8:1440x900@60.00  9:1280x800@60.00  10:1280x720@60.00  11:1024x768@60.00  12:800x600@60.00  13:640x480@60.00  14:1600x1200@119.82  15:1280x1024@119.83  16:1024x768@119.80  17:2560x1600@59.99  18:2560x1600@119.93  19:1920x1200@119.90  20:1280x800@119.85  21:2880x1620@59.96  22:2880x1620@119.95  23:2560x1440@59.96  24:2560x1440@119.95  25:1920x1080@119.93  26:1600x900@59.95  27:1600x900@119.95  28:1368x768@59.88  29:1368x768@119.83  30:1280x720@119.86 
>        Geometry: 0,0 1800x1125
>        Scale: 1.6
>        Rotation: 1
>        Overscan: 0
>        Vrr: Never
>        RgbRange: unknown
>        HDR: disabled
>        Wide Color Gamut: disabled
>        ICC profile: none
>        Color profile source: sRGB
>        Color power preference: prefer efficiency and performance
>        Brightness control: supported, set to 65% and dimming to 100%
>        Color resolution: automatic (10), range: [8; 16] bits per color
>        Allow EDR: always
>        Sharpness control: unsupported
Comment 4 Zamundaaa 2026-01-13 21:49:40 UTC
I see nothing there that would necessarily require a modeset, and I personally don't see any speed differences between logging into X11 and Wayland sessions.
However, running
> kwin_wayland -- konsole
from a tty shows Konsole pretty much instantly for me, and
> systemctl start --user plasma-plasmashell
after stopping plasmashell in the session does the same with the wallpaper. Only
> startplasma-wayland
takes a few seconds until the wallpaper shows up, so there definitely seems to be some space for optimization.