Bug 505379

Summary: In certain settings the screen contents remain visible when screen locker should've already activated in a VM
Product: [Plasma] plasmashell Reporter: SDon <darkinosunino>
Component: Screen lockingAssignee: Plasma Bugs List <plasma-bugs-null>
Status: REPORTED ---    
Severity: minor CC: john.kizer, kdedev, nate
Priority: NOR    
Version First Reported In: 6.3.91   
Target Milestone: 1.0   
Platform: Kubuntu   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=485932
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Showcasing the bug in a VM recorded from the host

Description SDon 2025-06-09 14:12:43 UTC
Created attachment 182120 [details]
Showcasing the bug in a VM recorded from the host

SUMMARY
When the lockscreen auto activation time is longer than the turn off monitor time, the contents of the screen stay visible in a VM (KVM with virt-manager). My guess is that plasma turns off the screen, which is not fully implemented in a VM (dimming part works).  Even though I can't reproduce in on real hardware,  I think it's worth fixing/make a work around just for VMs and for the possibility that it could maybe happen with buggy screens.
Best fix would be to make the whole screen black before turning it off.

STEPS TO REPRODUCE
1. Have a VM with e. g. Kubuntu testing
2. Set the lockscreen timer to e. g. 2 mins
3. Set turn off screen to e. g. 1 min
4. Wait the time,  and notice that you can still see the content (albeit, very much dimmed)

OBSERVED RESULT
You can see the screen contents.

EXPECTED RESULT
You shouldn't be able to see the screen contents.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kubuntu 25.10 (beta testing version)
KDE Plasma Version: 6.3.91
KDE Frameworks Version:  6.14.0
Qt Version:  6.8.3
Graphich Platform: Wayland
Graphich Processor: llvmpipe

ADDITIONAL INFORMATION
AFAIK, the the contents don't update, so it could be that the screen locker is there, it's just not drawn yet.
Comment 1 John Kizer 2025-06-21 15:53:35 UTC
Hi - with the same settings in the VM, I can't reproduce this behavior using Virtual Machine Manager (virt-manager) on top of QEMU/KVM. What VM software are you using on your host device?

Thanks!
Comment 2 SDon 2025-06-24 12:29:18 UTC
Hi!

I'm using virt-manager with KVM.

I did a bit more testing, I can reproduce the issue with virtio GPU, when I have 3D acceleration and opengl turned on. If I turn these 2 off, virt manager tells me on a black screen, Display output is not active. I can also reproduce the issue with BOCHS video, on VGA video I can't reproduce it. On QXL plasma seems to die (when it should lock the screen I hear a notification sound, after that I move the mouse and I get a whole black screen. I can't even switch TTY after that).

With my original setup (virtio with acceleration), I get the following log when I leave the VM alone for some time:

jún 24 14:17:43 test-standardpc kwin_wayland_wrapper[2775]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/LockOsd.qml:10:1: "../osd": no such directory

Maybe my installation is somehow in a bad state (I have updated the VM to 6.4 since the report). Later I'll try it with a fresh install. Also let me know what logs should I check. For the QXL video, I have the following, maybe related, maybe it's actually a bug with KVM or my host has some problems, but I'll leave it here, just in case:
jún 24 12:52:12 test-standardpc kdeconnectd[1749]: 2025-06-24T12:52:12 kdeconnect.core: No local bluetooth adapter found
jún 24 12:52:41 test-standardpc org.kde.KSplash[2563]: org.kde.plasma.waitforname: WaitForName: Service was not registered within timeout
jún 24 12:52:41 test-standardpc dbus-daemon[1330]: [session uid=1000 pid=1330 pidfd=5] Activated service 'org.kde.KSplash' failed: Process org.kde.KSplash exited with status 1
jún 24 12:56:03 test-standardpc polkit-kde-authentication-agent-1[1642]: qt.qpa.wayland: There are no outputs - creating placeholder screen
jún 24 12:56:03 test-standardpc kded6[1570]: qt.qpa.wayland: There are no outputs - creating placeholder screen
jún 24 12:56:03 test-standardpc org.kde.elisa[1948]: qt.qpa.wayland: There are no outputs - creating placeholder screen
jún 24 12:56:03 test-standardpc xdg-desktop-portal-kde[2208]: qt.qpa.wayland: There are no outputs - creating placeholder screen
jún 24 12:56:03 test-standardpc plasmashell[1608]: kde.plasmashell: requesting unexisting screen available rect -1
jún 24 12:56:03 test-standardpc kdeconnectd[1749]: 2025-06-24T12:56:03 qt.qpa.wayland: There are no outputs - creating placeholder screen
jún 24 12:56:03 test-standardpc plasmashell[1608]: kde.plasmashell: requesting unexisting screen available rect -1
jún 24 12:56:03 test-standardpc org_kde_powerdevil[1643]: qt.qpa.wayland: There are no outputs - creating placeholder screen
jún 24 12:56:03 test-standardpc plasmashell[1608]: file:///usr/share/plasma/plasmoids/org.kde.plasma.kicker/contents/ui/SideBarSection.qml:18: TypeError: Cannot read property 'horizontalCenter' of null
jún 24 12:56:03 test-standardpc plasmashell[1608]: file:///usr/share/plasma/plasmoids/org.kde.plasma.kicker/contents/ui/SideBarSection.qml:18: TypeError: Cannot read property 'horizontalCenter' of null

(I have seen the org.kde.KSplash failed message with virtio as well somtimes)
Comment 3 John Kizer 2025-06-25 02:14:41 UTC
Thanks - I'll have to defer to folks with more knowledge of display systems on how that would work / where in the stack this fits.
Comment 4 TraceyC 2025-10-02 19:45:07 UTC
Linking to bug 485932
"kde.plasmashell: requesting unexisting screen available rect -1" is a common factor
Comment 5 TraceyC 2025-10-24 16:31:07 UTC
Bug 507018 which had similar errors in logs, has been fixed in 6.5.0. Can I ask you to please re-test this when your system is updated to that version and let us know if this is still happening? Thanks!
Comment 6 SDon 2025-10-30 15:02:23 UTC
I have updated to version 6.5.1 (by adding the backports PPA).
Problem still persists (as a reminder, this is in virt-manager (KVM) virtual machine, with virtui GPU, 3D acceleration enabled). But there is a bit more nuance I think:
While updating the original system (which took quite a long time) I was checking on it, and sometimes it actually worked (screen went fully black), but it was kinda rare. Now with the newest version, it does the same, sometimes it works, most of the times it doesn't.
The level of dimming seems different, sometimes nearly all the way, sometimes not that much. So I think it could be a timing issue.
Under X11 session it works the same as in the Wayland session.

Under an old (2022) version of Ubuntu with X11 Gnome, it works fine, even though the transition is slower. However, turning off the screen instantly from the command line with this command:
xset -display :0.0 dpms force off
The screen contents stay on the screen without updating. So turning off the screen must not work properly in virt-manager (or maybe this is how it's supposed to, I'm not sure). (This command does the same thing under X11 Plasma as well.)

Under Plasma wayland I found this comamnd to turn off the screen:
qdbus6 org.kde.kglobalaccel /component/org_kde_powerdevil invokeShortcut "Turn Off Screen"
Alternatively, this does the same:
kscreen-doctor --dpms off
But this just triggers the same turning off dimming animation, it's not instant. It's easier to test with at least.

Is there a setting that makes the dimming faster (or instant)?