OS: Artix Linux x86_64 (OpenRC)
Host: X470 AORUS ULTRA GAMING
Kernel: Linux 6.12.7-artix1-1
Shell: bash 5.2.37
Display (E60-E3): 3840x2160 @ 60 Hz in 60" [External]
DE: KDE Plasma 6.2.4
WM: KWin (Wayland)
WM Theme: Breeze
Theme: Breeze (Dark) [Qt]
Icons: breeze-dark [Qt]
CPU: AMD Ryzen 9 5950X (32) @ 5.08 GHz
GPU: AMD Radeon RX 6700 [Discrete]
Issue:
Wallpaper, desktop icons, and task bar missing, any time my HDMI display is turned off and back on again. Any open applications still remain and are funcional.
I have scoured the web for weeks trying to find a real fix. I have found numerous posts across the wed, with similar issues from types of vid cards to laptop refume issues etc… The majority of the recommended suggestions are to restart plasmashell or plasmashell --replace. My system prefers to stop plasma and restart it. This is easy enough if I happened to have a terminal open, at the time of turning off my display.
Being that this is quite annoying, I made a simple script to monitor the connection state of the display. It then stops/starts plasma acordingly. I am sharing this with the hopes others find it usefull. This is a temporary work around, that works well enough for me, at least untill the dev are able to this gets fixed.
Hope This Helps
…YMMV…
Good Luck
#!/bin/bash
################################################
# Made this as a temporary fix for KDE plasma 6
# until KDE can get this sorted out
#
# Issue: after HDMI TV/monitor is turned off/on
# wallpaper, icons, and taskbar are gone
#
# add this script to user startup
# System Settings > Autostart
###############################################
## Edit this to match your specific display ##
THISDSPLAY='/sys/class/drm/card1-HDMI-A-1'
#_____________________________#
# Monitor the connection state of HDMI display then
# refresh plasmashell when display is turned back on
CRNT_STATE=''
PREV_STATE='connected'
while true; do
([ -e ${THISDSPLAY}/status ] && [ -s ${THISDSPLAY}/status ]) || sleep 5
CRNT_STATE="$(cat ${THISDSPLAY}/status)"
if [[ "${CRNT_STATE}" != "${PREV_STATE}" ]]; then
([[ "${CRNT_STATE}" == 'connected' ]] && plasmashell &> /dev/null &) || kquitapp6 plasmashell &> /dev/null
else
[[ "${CRNT_STATE}" == 'connected' ]] && sleep 5
fi
PREV_STATE="${CRNT_STATE}"
sleep 1 ;
done
Hi! I just wanted to ask, since you mentioned already having searched quite a bit - have you already found an existing issue filed in the KDE Bugtracking System for the situation you’re experiencing?
Though I have found others with this type issue, I do not find this exact issue on the bug tracker site. I had found this one which seemed more about issue with multiple monitors. There were many posts in there with similar issues. Even though they seemed to get dismissed by the admin, I assumed someone had at least raised an eyebrow about it… that thread is several years long. Combined with so many around the web with similar issues , I assumed the devs are aware of it. I always fear not finding the correct past bug reports, then after posting, turning out to just be
nagging them for things they are already working on… I will be happy to post a bug report if you think it will help.
Thanks! Based on your description, and on the bugs that have been merged in as duplicates of it, I suspect you’re running into this one: 477941 – Plasma asserts in qobject_cast<PanelView *>(panel) after ShellCorona::createWaitingPanels() after connecting the external display
The title itself is pretty technical and specific to one situation, but some of the related ones include:
- “plasmashell crashes in ShellCorona::createWaitingPanels() on wake up from sleep”
- “plasmashell crash when turning off connected displays and then powering them back up”
- “Plasmashell crashes when wake up my monitor”
And the effect you’re observing - the desktop and panels freezing/disappearing, but existing windows still functioning fine - sounds like plasmashell crashing but KWin (window manager / display server) still being OK.
So, I could be wrong, but I’d guess that’s what you’re running into - if you want to confirm, checking through the details in that bug report and its duplicate ones, and comparing to what shows up on your PC might help validate that.
If it ends up being not actually related, then I’d say reporting the bug is definitely worth it - having solid bug reports is a critical way for folks working on KDE code to identify how issues show up on users’ devices. With all the combinations of hardware out there, display problems can be especially tricky for a small group of testers to catch and research on their own 
(About issues seeming to be dismissed - that particular bug that you identified above, unfortunately, started off as one clearly-defined issue but ended up with several similar-sounding but different ones being brought up, and with the original bug reporter no longer able to reproduce it. It looks, to me at least, like there are clearer individual bugs tracking specific situations now)
1 Like
Excellent find . It does appear to be related . My guess the underlying issue is being looked into. I’ll periodically check in on the status of that report thread. Once marked resolved, and the fix applied to main stream, I’ll keep my fingers crossed that this issue is resolved. If my issue persists from there, I will file a new report with my findings. Till then, that work around script works well enough to make for a comfortable experience.
Thank You for looking into this…
Cheers
1 Like
You’re welcome! I definitely have some bugs that I periodically check in on as well, but you can have Bugzilla notify you directly of any changes by adding yourself to the “CC list” on a particular bug report:
Any change that happens to that report - like new comments or status changes - will get emailed to you with the content of that change, plus a link back to the full report, so you don’t need to worry about missing updates
