SUMMARY The lockscreen sometimes (often) become unresponsive/stuck after having been locked and the screen turned off. Sometimes it responds, but refuses to login despite hitting enter or the the little > icon. It can take upwards of a minute before it unlocks. When it refuses to accept the password, I have to switch to another TTY and use loginctl to login to the Plasma session. This happened on Plasma 5.27 as well. STEPS TO REPRODUCE 1. Lock the screen using Meta+L or the Lock button in the menu. 2. Start typing password to unlock. 3. Kscreenlocker is now unresponsive/stuck for upwards to a minute EXPECTED RESULT That the screen unlocks more or less instantaneously after hitting enter. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.9-zen1-1.1-zen (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-4770K CPU @ 3.50GHz Memory: 7.7 GiB of RAM Graphics Processor: AMD Radeon R9 Fury Series Manufacturer: MSI Product Name: MS-7818 System Version: 1.0 ADDITIONAL INFORMATION Output from /usr/lib/kscreenlocker_greet: /usr/lib/kscreenlocker_greet Locked at 1710066913 QMetaObject::invokeMethod: No such method ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) QMetaObject::invokeMethod: No such method ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/MediaControls.qml:31:13: QML QQuickImage: Blocked request. Unlocked
Okay, so.. I'm not sure if this is actually kscreenlocker, or if it's Kwin, or an entirely other component instead, or if this is an entirely unrelated bug. I went ahead and turned off automatic lockscreen, so I wouldn't have to deal with being stuck on the lockscreen, however, now after coming back and waking the screen up from automatically turning off, the Plasma is completely unresponsive. I see the cursor change and react to open apps, but Plasma itself is unresponsive for a period, before reacting again. Monitor is a ViewSonic XG2405 if that has any relevance.
All of this does sound quite related. A way to narrow it down is to manually lock the screen with meta+L without involving sleep/wake at all. When you manually lock and unlock, do you still see the issue? Also, I'm guessing this is a single-screen desktop system, right?
(In reply to Nate Graham from comment #2) > All of this does sound quite related. > > A way to narrow it down is to manually lock the screen with meta+L without > involving sleep/wake at all. When you manually lock and unlock, do you still > see the issue? > > Also, I'm guessing this is a single-screen desktop system, right? If I manually lock and unlock before the monitor turns off, I don't see an issue, no. Also, just to be clear, it's not the system going into sleep/hibernation, just the monitor turning off. Yep, it is a single screen desktop.
Thanks. Does it happen on Wayland too, or only X11?
i've the same issue && when i lock manually the screen with meta+L everything is OK. it happen on Wayland as i am using wayland. i was thinking that bug was related to my "resume kernel" setting or with my Graphics Processor unit but apparently it is not. Operating System: EndeavourOS KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.1-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz Memory: 15.4 Gio of RAM Graphics Processor: NVIDIA GeForce GTX 1650/PCIe/SSE2
For people affected, does the issue go away if you change your Plasma style to something other than "Breeze"? For example "Breeze Dark?" Not the global scheme or the color scheme; just the Plasma style.
> plasma style to something other than "Breeze"? For example "Breeze Dark?" Not the global scheme or the color > scheme; just the Plasma style. my plasma style it is "lightly" & it happens....
> plasma style to something other than "Breeze"? For example "Breeze Dark?" Not the global scheme or the color > scheme; just the Plasma style. my plasma style it is "lightly" & it happens.... The only way to overcome the problem is to " killall plasmashell && kstart plasmashell "
It happened on both Wayland and X11, yes. I can't, currently, check whether switching the Plasma style "fixes" it, as I'm not near that machine, but will get back as soon as I've tried. :)
Well, changing the Plasma style didn't change anything for me either. I'm honestly at a loss for how to really test this.
I think I'm starting to see the same issue: it happens when the screen saver kicks in *and* the screen(s) turns off. If I try to log back in, I'm greeted with a black screen and the writing "the screen locker is broken and unlocking is not possible anymore". Then there are instructions about switching to a console and "manually" unlock the screen with the "loginctl unlock-session" command. Which works, so that is an inconvenience but not a show stopper. Journalctl reports: ``` giu 26 08:26:49 betelgeuse kscreenlocker_greet[126137]: QMetaObject::invokeMethod: No such method ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) giu 26 08:26:49 betelgeuse kscreenlocker_greet[126137]: QMetaObject::invokeMethod: No such method ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) giu 26 08:26:49 betelgeuse kscreenlocker_greet[126303]: qt.qpa.wayland: Loading shell integration failed. giu 26 08:26:49 betelgeuse kscreenlocker_greet[126303]: qt.qpa.wayland: Attempted to load the following shells QList("layer-shell") giu 26 08:26:49 betelgeuse kscreenlocker_greet[126303]: qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found. giu 26 08:26:49 betelgeuse kscreenlocker_greet[126303]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: offscreen, vnc, linuxfb, eglfs, xcb, minimalegl, minimal, wayland, wayland-egl, vkkhrdisplay. giu 26 08:26:49 betelgeuse kscreenlocker_greet[126307]: qt.qpa.wayland: Loading shell integration failed. giu 26 08:26:49 betelgeuse kscreenlocker_greet[126307]: qt.qpa.wayland: Attempted to load the following shells QList("layer-shell") giu 26 08:26:49 betelgeuse kscreenlocker_greet[126307]: qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found. giu 26 08:26:49 betelgeuse kscreenlocker_greet[126307]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: offscreen, vnc, linuxfb, eglfs, xcb, minimalegl, minimal, wayland, wayland-egl, vkkhrdisplay. giu 26 08:26:49 betelgeuse kscreenlocker_greet[126314]: qt.qpa.wayland: Loading shell integration failed. giu 26 08:26:49 betelgeuse kscreenlocker_greet[126314]: qt.qpa.wayland: Attempted to load the following shells QList("layer-shell") giu 26 08:26:49 betelgeuse kscreenlocker_greet[126314]: qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found. giu 26 08:26:49 betelgeuse kscreenlocker_greet[126314]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: offscreen, vnc, linuxfb, eglfs, xcb, minimalegl, minimal, wayland, wayland-egl, vkkhrdisplay. ``` I'm using archlinux, kde 6.1.0, framework 6.3.0 on wayland. Note that this wasn't happening until I upgraded from the 6.0.X branch.
Likely a duplicate of https://bugs.kde.org/show_bug.cgi?id=485084
That looks like a different issue. This one looks more likely to be related to the odd network errors: giu 26 08:26:49 betelgeuse kscreenlocker_greet[126137]: QMetaObject::invokeMethod: No such method ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) For anyone affected who sees those errors, are you using a non-default login screen theme, or are you using a remote URL for your avatar image, or are you on a network home directory or something? Is there *anything* network-related that might be unusual with respect to your setup that you can comment on?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
(In reply to Nate Graham from comment #13) > That looks like a different issue. This one looks more likely to be related > to the odd network errors: > > giu 26 08:26:49 betelgeuse kscreenlocker_greet[126137]: > QMetaObject::invokeMethod: No such method > ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) > > For anyone affected who sees those errors, are you using a non-default login > screen theme, or are you using a remote URL for your avatar image, or are > you on a network home directory or something? Is there *anything* > network-related that might be unusual with respect to your setup that you > can comment on? Nothing remote, and just the default lock screen. To be precise, it happens on both default, and non-default login themes. I probably won't be much help in the future, as I've had to switch desktop. But I did a quick test on 6.1.2, and can confirm it still happens there.
From the output, it looks like it's the media controls on the lock screen that blocked the unlock request. It makes me wonder what was playing at the time, and through what application It makes me wonder if the network stack hadn't fully woken yet and was being polled by the media widget, which hung waiting for the still sleeping service? Setting to confirmed since the problem still happens for the OP
(In reply to TraceyC from comment #16) > From the output, it looks like it's the media controls on the lock screen > that blocked the unlock request. It makes me wonder what was playing at the > time, and through what application > It makes me wonder if the network stack hadn't fully woken yet and was being > polled by the media widget, which hung waiting for the still sleeping > service? > > Setting to confirmed since the problem still happens for the OP I usually have Spotify running at pretty much at all times, but as far as I remember, I actually did run a test with Spotify closed where it still happened. Also tried with the .deb(AUR) version and Flatpak version. However, I don't recall if I had say, Firefox open, with youtube, which would still work with the media play widget, yes?
I am also having issues with this, without any programs open. Issues started when updating to Plasma 6.1. Hardware Information - 12th Gen Intel(R) Core(TM) i7-12700H (12+8) @ 4.70 GHz - Intel Iris Xe Graphics @ 1.40 GHz [Integrated] - NVIDIA GeForce RTX 3060 Mobile / Max-Q [Discrete] - Software Information - Arch Linux x86_64 - 6.9.10-arch1-1 - sddm 0.21.0 (X11) - KDE Plasma 6.1.3
(In reply to Antonio from comment #18) > I am also having issues with this, without any programs open. Issues started > when updating to Plasma 6.1. > > Hardware Information > - 12th Gen Intel(R) Core(TM) i7-12700H (12+8) @ 4.70 GHz > - Intel Iris Xe Graphics @ 1.40 GHz [Integrated] > - NVIDIA GeForce RTX 3060 Mobile / Max-Q [Discrete] > - Software Information > - Arch Linux x86_64 > - 6.9.10-arch1-1 > - sddm 0.21.0 (X11) > - KDE Plasma 6.1.3 With this exact same log messaging? MetaObject::invokeMethod: No such method ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) QMetaObject::invokeMethod: No such method ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/MediaControls.qml:31:13: QML QQuickImage: Blocked request. Or no?
(In reply to Nate Graham from comment #19) > (In reply to Antonio from comment #18) > > I am also having issues with this, without any programs open. Issues started > > when updating to Plasma 6.1. > > > > Hardware Information > > - 12th Gen Intel(R) Core(TM) i7-12700H (12+8) @ 4.70 GHz > > - Intel Iris Xe Graphics @ 1.40 GHz [Integrated] > > - NVIDIA GeForce RTX 3060 Mobile / Max-Q [Discrete] > > - Software Information > > - Arch Linux x86_64 > > - 6.9.10-arch1-1 > > - sddm 0.21.0 (X11) > > - KDE Plasma 6.1.3 > > With this exact same log messaging? > > MetaObject::invokeMethod: No such method > ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) > QMetaObject::invokeMethod: No such method > ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) > file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/ > lockscreen/MediaControls.qml:31:13: QML QQuickImage: Blocked request. > > Or no? I tried running the same file as comment #0, but that locked the screen for the root user and didn't output that. Are the logs for the normal flow stored somewhere? I don't know where to locate it, sorry. If this adds any value, when putting the pc to sleep, with the option of locking after wakeup, this problem doesn't happen. It also doesn't happen when locking with "super L" + "L". It only happens after automatic lock with any specified time (I set it to 1 minute for easy reproduction). Also, ocasionally, the password input will never pop up and will have to reboot through tty3.
Important note (sorry I didn't include it earlier, I just noticed...). This only happens when I am using only nvidia. In hybrid or integrated mode, this does not happen. Is that the case for other people that had the problem?
Another Nvidia on X11 user here. Here's my observation: I get the described freeze/lag when the display is powered down but only when using the Nvidia proprietary driver on my work PC's GeForce GT 1030. Changing from proprietary driver to the nouveau driver solves the problem at the expense of everything else being generally laggy, nouveau being nouveau. No freezing issues seen on my 2 personal computers with AMD graphics on Wayland. Questions to ask others here are: * Does this (still) affect AMD and Intel graphics? I see the bug submitter was on AMD. * Does switching from nvidia proprietary to nouveau stop this from happening?
I can confirm this still happens in Plasma 6.1.4 on AMD, mesa 24.1.5
I can confirm that the bug still happens on Plasma version 6.1.4. I also found a simple temporary workaround. I commented out the entire Image object with id: albumArt, starting at line 31 in the file /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/MediaControls.qml This will remove the album art from the lock screen, but will also stop the bug from happening.
*** Bug 489846 has been marked as a duplicate of this bug. ***
*** Bug 483722 has been marked as a duplicate of this bug. ***
I experience the same issue. Latest Arch Linux on Xorg, single monitor, open source Radeon drivers. Linux 6.10.4 kscreenlocker 6.1.4 xorg-server 21.1.13 xf86-video-amdgpu 23.0.0 sddm 0.21.0
Happens for me as well. Super irritating...it happens 8 out of 10 cases. What helps for me is to switch to console and pkill -f -9 kscreenlocker_greet. As far I remember, it started happening around Plasma 6.1. Maybe it is related, or not but, often monitor blinks multiple times and displays information that frequency is out of range. Sometimes only one screen is detected (monitor has to be enabled via Nvidia settings app), sometimes monitors display the same screen. I have a two monitor setup. Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.4-200.fc40.x86_64 (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 62,7 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060/PCIe/SSE2 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C91 System Version: 2.0
I just encountered this today on git master.
Well, this is kind of funny, but I can't replicate this anymore. I installed F40 to test the "solution" in Comment 24, but that file doesn't exist on this install. X11 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Mesa version: 24.1.5
Nevermind, it is happening again. I've changed two things between then, and now, I moved the default panel to the top, switched it to "fit content", and then switched notification popups to the top right corner.
I am getting this error when using wallhaven wallpaper plugin, the network related action here is fetching a wallpaper from wallhaven, not even the initial wallpaper is fetched correctly, it fails everytime here is the link to the plugin https://github.com/Blacksuan19/plasma-wallpaper-wallhaven-reborn
(In reply to Ksenia Turek from comment #24) > I can confirm that the bug still happens on Plasma version 6.1.4. > I also found a simple temporary workaround. > > I commented out the entire Image object with id: albumArt, starting at line > 31 in the file > /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/ > MediaControls.qml > > This will remove the album art from the lock screen, but will also stop the > bug from happening. Nope. that didn't help. And this is happening regardles of the album art being displayed or not (for me it's never showing).
I am also having this issue, except that sometimes the system also locks up after logging in after booting.
I've also been having monitor troubles ever since Plasma 6.1. https://bugs.kde.org/show_bug.cgi?id=489457 There's definitely some kind of bug that has been introduced around that time, but I'm at a loss on what it could be. Annoying because I love Plasma, and I don't want to switch to a different DE just for this issue.
How do I go about getting the list of commits that happened between versions 6.0 and 6.1?
Same here Manjaro Linux KDE 6.1.5 amdgpu X11 After the system goes to hibernate, (hibernate works as it should, enough swap is there also) the system randomize freeze. Mean restore from hibernate there isn't a sddm-greeter. The system either starts only with a black screen or it shows a "snapshot" of the hibernate, you can see that because the clock isn't running. There is no keyboard or mouse. I can't use any key to switch to tty and restart the sddm session manually That issue is there since the update to plasma 6 with the 5th version everything works as it should
If anyone can reproduce this, can I have output of "journalctl --user -r" after this happens.
(In reply to David Edmundson from comment #38) > If anyone can reproduce this, can I have output of "journalctl --user -r" > after this happens. Here's mine: Oct 12 01:35:49 FredArch kscreenlocker_greet[790136]: Failed to create RHI (backend 2) Oct 12 01:35:49 FredArch kscreenlocker_greet[790136]: QRhiGles2: Context is lost. Oct 12 01:35:49 FredArch kscreenlocker_greet[790136]: Failed to create RHI (backend 2) Oct 12 01:35:49 FredArch kscreenlocker_greet[790136]: QRhiGles2: Context is lost. Oct 12 01:35:49 FredArch kscreenlocker_greet[790136]: Graphics device lost, cleaning up scenegraph and releasing RHI Oct 12 01:35:49 FredArch kscreenlocker_greet[790136]: QRhiGles2: Context is lost. Oct 12 01:35:49 FredArch kscreenlocker_greet[790136]: Graphics device lost, cleaning up scenegraph and releasing RHI Oct 12 01:35:49 FredArch kscreenlocker_greet[790136]: QRhiGles2: Context is lost. Oct 12 01:35:36 FredArch kded6[2061]: colord: EDID ICC Profile already exists "/home/frederick/.local/share/icc/edid-8d55884d804292953dcbc6158f7e970c.icc" Oct 12 01:35:36 FredArch kded6[2061]: colord: EDID ICC Profile already exists "/home/frederick/.local/share/icc/edid-46a82c48dfb431b7ef4ae8d0e4834d17.icc" Oct 12 01:35:36 FredArch kded6[2061]: colord: Setting X atom (id: 1 ) "_ICC_PROFILE_1" on output: "DP-3" Oct 12 01:35:36 FredArch kded6[2061]: colord: Failed to register device: "device id 'xrandr-U2790B-<serial no.>' already exists" Oct 12 01:35:36 FredArch kded6[2061]: colord: Setting X atom (id: 0 ) "_ICC_PROFILE" on output: "HDMI-0" Oct 12 01:35:31 FredArch kded6[2061]: colord: Failed to register device: "device id 'xrandr-LG Electronics-LG ULTRAFINE-<serial no.>' already exists" Operating System: Arch Linux KDE Plasma Version: 6.2.0 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.3 Kernel Version: 6.10.10-arch1-1 (64-bit) Graphics Platform: X11
I'm not able to reproduce with Wayland or X11 on git-master FWIW
(In reply to TraceyC from comment #40) > I'm not able to reproduce with Wayland or X11 on git-master FWIW I am seeing this too although its random and happens with Nvidia GPU and AMD Gpu.
I see this too on Alienware R14, ubuntu 24.04 and kde plasma 6.2. It has a dual 4k monitor setup, nvidia gfx and AMD cpu. I'm on Neon User, new install. Let me know if you need more details.
(In reply to Dennis from comment #42) > I see this too on Alienware R14, ubuntu 24.04 and kde plasma 6.2. It has a > dual 4k monitor setup, nvidia gfx and AMD cpu. I'm on Neon User, new > install. Let me know if you need more details. On wayland.
I think I might have opened a duplicate here : https://bugs.kde.org/show_bug.cgi?id=494927 The difference is that I (and other people, apparently) have a specific line repeated in logs, when trying (without success) to unlock : file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/LockScreenUi.qml:280: TypeError: Property 'respond' of object length is not a function
Bug 494927 doesn't look like a duplicate. The error messages are different. The symptoms are also subtly different.
*** Bug 494529 has been marked as a duplicate of this bug. ***
(In reply to TraceyC from comment #45) > Bug 494927 doesn't look like a duplicate. The error messages are different. > The symptoms are also subtly different. I checked my journalctl --user and I found this Oct 22 22:16:15 MyArchGamingPC kscreenlocker_greet[71014]: Graphics device lost, cleaning up scenegraph and releasing RHI Oct 22 22:16:15 MyArchGamingPC kscreenlocker_greet[71014]: QRhiGles2: Context is lost. Oct 22 22:16:04 MyArchGamingPC kscreenlocker_greet[71014]: Graphics device lost, cleaning up scenegraph and releasing RHI Oct 22 22:16:04 MyArchGamingPC kscreenlocker_greet[71014]: QRhiGles2: Context is lost. Oct 22 22:16:04 MyArchGamingPC kscreenlocker_greet[71014]: pam_systemd_home(kde:auth): New sd-bus connection (system-bus-pam-systemd-home-71014) opened. So no the bug report I created Bug 494927 was a duplicate. Just one thing I am not sure If I saw I only experience this on x11, works fine on wayland. Also all of the time it takes is max 20 seconds for the screen to go back to normal, not a minute. Also one big difference is it doesn't happen at all when I lock using meta+L only when the my pc locks at any time when the screen is off.
*** Bug 495388 has been marked as a duplicate of this bug. ***
I re-tested at Nate's request nVidia GPU Plasma 6.1.5 - cannot reproduce with Wayland or X11 AMD GPU Plasma git-master - cannot reproduce with Wayland or X11
This is still happening for me Output from journalctl right after: ``` okt 31 10:17:43 cachyos kscreenlocker_greet[17494]: pam_unix(kde:auth): authentication failure; logname=user uid=1000 euid=1000 tty= ruser= rhost= user=user okt 31 10:17:38 cachyos org_kde_powerdevil[1355]: dh=Display_Handle[i2c-4: fd=27], Keeping adjusted sleep multiplier 2,00 for SE_POST_WRITE or SE_POST_SAVE_SETTINGS okt 31 10:17:37 cachyos org_kde_powerdevil[1355]: Executed 1 registered callbacks. okt 31 10:17:37 cachyos org_kde_powerdevil[1355]: Emitting DDCA_Display_Status_Event( 10917.059: DDCA_EVENT_DPMS_AWAKE, card0-DP-1, dref: Display_Ref[bus /dev/i2c-4], io_path:/dev/i2c-4] okt 31 10:17:35 cachyos org_kde_powerdevil[1355]: stabilized_connector_names required 1 extra calls to get_sysfs_drm_connector_names() okt 31 10:17:29 cachyos kscreenlocker_greet[17494]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/MediaControls.qml:31:13: QML Image: Blocked request. okt 31 10:17:29 cachyos kscreenlocker_greet[17494]: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile okt 31 10:17:28 cachyos kscreen_backend_launcher[1442]: kscreen.xrandr: Emitting configChanged() okt 31 10:17:28 cachyos plasmashell[1273]: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile okt 31 10:17:28 cachyos plasmashell[1273]: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile okt 31 10:17:28 cachyos kscreen_backend_launcher[1442]: kscreen.xrandr: Output 87 : connected = false , enabled = false ``` CachyOS KDE Plasma Version: 6.2.2 KDE Frameworks Version: 6.7.0 Qt Version: 6.8.0 Kernel Version: 6.11.5 Graphics Platform: X11
*** Bug 490649 has been marked as a duplicate of this bug. ***
Dec 03 08:14:33 pc-i7 systemd[1416]: Started app-org.kde.konsole@e92436b91af0460b9af47ee0f5e5d959.service - Konsole - Terminal. Dec 03 08:15:04 pc-i7 kded6[1750]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1b.0.analog-stereo.monitor" Dec 03 08:15:05 pc-i7 plasmashell[1761]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1b.0.analog-stereo.monitor" Dec 03 08:16:22 pc-i7 kded6[1750]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1b.0.analog-stereo.monitor" Dec 03 08:16:22 pc-i7 plasmashell[1761]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1b.0.analog-stereo.monitor" Dec 03 08:16:35 pc-i7 kscreenlocker_greet[3520]: QRhiGles2: Context is lost. Dec 03 08:16:35 pc-i7 kscreenlocker_greet[3520]: Graphics device lost, cleaning up scenegraph and releasing RHI Dec 03 08:16:35 pc-i7 kscreenlocker_greet[3520]: QRhiGles2: Context is lost. Dec 03 08:16:35 pc-i7 kscreenlocker_greet[3520]: Failed to create RHI (backend 2) It is still reproduced on: Fedora 41; kscreenlocker-6.2.4-1.fc41.x86_64
As has been mentioned above, I've been experiencing this issue for many months now. I wanted to provide my journalctl logs to add to the troubleshooting effort. First time commenter on this site, so I'll keep the logs below limited to when I attempted to unlock my screen after the monitors went to sleep. Most of the errors seem to relate to kscreenlocker_greet and wireplumber. Happy to provide more information if it will help. ----------------------- Operating System: Fedora Linux 41 KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.11.10-300.fc41.x86_64 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 31.2 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2060 SUPER/PCIe/SSE2 ----------------------- Dec 03 09:37:09 openrazer-daemon[23830]: 2024-12-03 09:37:09 | razer.device0 | INFO | Suspending RazerDeathAdderV2 Dec 03 09:37:10 kscreenlocker_greet[27303]: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile Dec 03 09:37:10 wireplumber[24301]: wplua: [string "alsa.lua"]:182: attempt to concatenate a nil value (local 'node_name') stack traceback: [string "alsa.lua"]:182: in function <[string "alsa.lua"]:175> Dec 03 09:37:10 wireplumber[24301]: wplua: [string "alsa.lua"]:182: attempt to concatenate a nil value (local 'node_name') stack traceback: [string "alsa.lua"]:182: in function <[string "alsa.lua"]:175> Dec 03 09:37:10 wireplumber[24301]: wplua: [string "alsa.lua"]:182: attempt to concatenate a nil value (local 'node_name') stack traceback: [string "alsa.lua"]:182: in function <[string "alsa.lua"]:175> Dec 03 09:37:10 wireplumber[24301]: wplua: [string "alsa.lua"]:182: attempt to concatenate a nil value (local 'node_name') stack traceback: [string "alsa.lua"]:182: in function <[string "alsa.lua"]:175> Dec 03 09:37:10 wireplumber[24301]: wplua: [string "alsa.lua"]:182: attempt to concatenate a nil value (local 'node_name') stack traceback: [string "alsa.lua"]:182: in function <[string "alsa.lua"]:175> Dec 03 09:38:29 wireplumber[24301]: wplua: [string "alsa.lua"]:182: attempt to concatenate a nil value (local 'node_name') stack traceback: [string "alsa.lua"]:182: in function <[string "alsa.lua"]:175> Dec 03 09:38:52 kscreenlocker_greet[27303]: QRhiGles2: Context is lost. Dec 03 09:38:52 kscreenlocker_greet[27303]: Graphics device lost, cleaning up scenegraph and releasing RHI Dec 03 09:38:52 audit: BPF prog-id=215 op=LOAD Dec 03 09:38:52 systemd[1]: Starting fprintd.service - Fingerprint Authentication Daemon... Dec 03 09:38:52 systemd[1]: Started fprintd.service - Fingerprint Authentication Daemon. Dec 03 09:38:52 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 03 09:38:52 kscreenlocker_greet[27303]: pam_unix(kde:auth): authentication failure; logname=MyUsername uid=1000 euid=1000 tty= ruser= rhost= user=MyUsername Dec 03 09:39:05 kscreenlocker_greet[27303]: QRhiGles2: Context is lost. Dec 03 09:39:05 kscreenlocker_greet[27303]: Failed to create RHI (backend 2) Dec 03 09:39:13 kscreenlocker_greet[27303]: QRhiGles2: Context is lost. Dec 03 09:39:13 kscreenlocker_greet[27303]: Graphics device lost, cleaning up scenegraph and releasing RHI Dec 03 09:39:13 kscreenlocker_greet[27303]: QRhiGles2: Context is lost. Dec 03 09:39:13 kscreenlocker_greet[27303]: Graphics device lost, cleaning up scenegraph and releasing RHI Dec 03 09:39:14 kscreenlocker_greet[27303]: QRhiGles2: Context is lost. Dec 03 09:39:14 kscreenlocker_greet[27303]: Failed to create RHI (backend 2) Dec 03 09:39:14 kscreenlocker_greet[27303]: QRhiGles2: Context is lost. Dec 03 09:39:14 kscreenlocker_greet[27303]: Failed to create RHI (backend 2) Dec 03 09:39:19 audit[27377]: USER_AUTH pid=27377 uid=1000 auid=1000 ses=13 subj=unconfined_u:unconfined_r:chkpwd_t:s0-s0:c0.c1023 msg='op=PAM:unix_chkpwd acct="MyUsername" exe="/usr/sbin/unix_chkpwd" hostname=? addr=? terminal=? res=success' Dec 03 09:39:19 openrazer-daemon[23830]: 2024-12-03 09:39:19 | razer.device0 | INFO | Resuming RazerDeathAdderV2 Dec 03 09:39:21 systemd[23814]: Started app-org.kde.konsole@0f6e448201434d268422a25efd6054de.service - Konsole - Terminal. Dec 03 09:39:22 systemd[1]: fprintd.service: Deactivated successfully. Dec 03 09:39:22 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 03 09:39:22 audit: BPF prog-id=215 op=UNLOAD Dec 03 09:39:25 audit[27434]: USER_ACCT pid=27434 uid=1000 auid=1000 ses=13 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix acct="MyUsername" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
Changing OS and version back. Please don't change these values.
(In reply to TraceyC from comment #54) > Changing OS and version back. Please don't change these values. Sorry about that, new to this site. I thought it was prompting me to add my OS information before commenting.
*** Bug 486889 has been marked as a duplicate of this bug. ***
The worst thing about unlocking your device "blindly" is that sometimes the fingerprint authentication goes south (it just stops working or even prompting — even when the lock screen isn't pitch-black) and other times my input language keyboard layout has been switched away from English (US) so my first password attempt is bound to fail and I have to guesstimate 3 seconds timeout before Meta+Space and blindly typing again. The issue has nothing to do with "monitor wake-up", as it perfectly happens when simply locking the screen with Meta+L without putting the device to sleep. I have had this issue for over a year now, both on old crappy NVIDIA laptop and on a new shiny (but no less crappy when it comes to video drivers) full-AMD one. But Steam Deck doesn't have a lock screen, so apparently this issue comes a long way down on the priority list for those KDE developers who could potentially fix this.
(In reply to ratijas from comment #57) > The worst thing about unlocking your device "blindly" is that sometimes the > fingerprint authentication goes south (it just stops working or even > prompting — even when the lock screen isn't pitch-black) and other times my > input language keyboard layout has been switched away from English (US) so > my first password attempt is bound to fail and I have to guesstimate 3 > seconds timeout before Meta+Space and blindly typing again. > > The issue has nothing to do with "monitor wake-up", as it perfectly happens > when simply locking the screen with Meta+L without putting the device to > sleep. I can confirm locking with Win/Super + L, the problem does not occur, whether or not the monitor goes to sleep or not.
> (In reply to Hammad R from comment #58) > I can confirm locking with Win/Super + L, the problem does not occur, > whether or not the monitor goes to sleep or not. To add, I noticed it only happens when Monitor goes to sleep after auto-lock. If I set auto-lock to 1 minute and screen-turn-off to "1 minute: when locked", then after a minute it locks and turns off itself automatically (since 1 minute had elapsed and it's also locked). At this point, the freeze occurs. It doesn't occur if I change screen-turn-off to higher than "1 minute: when locked" and then move the mouse/press a key between auto locking and the screen turning off.
I made a correlation recently, but not sure if it helps get to the root cause. I've found the login freeze happens rarely (if ever) when I keep my Plantronics USB wireless headset receiver unplugged from my desktop. When it is plugged in when the computer goes to sleep and is woken back up, the ~1 minute freeze before the password prompt appears occurs consistently. USB Receiver Info: ID 047f:02ee Plantronics, Inc. BT600 dmesg logs when connecting dongle, see logs posted earlier during the reproduction of the login screen freeze: Before connecting USB: [ 38.133925] [drm] [nvidia-drm] [GPU ID 0x00000900] Loading driver [ 39.300525] RPC: Registered named UNIX socket transport module. [ 39.300528] RPC: Registered udp transport module. [ 39.300530] RPC: Registered tcp transport module. [ 39.300531] RPC: Registered tcp-with-tls transport module. [ 39.300532] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 39.440921] [drm] Initialized nvidia-drm 0.0.0 for 0000:09:00.0 on minor 1 [ 39.468124] nvidia 0000:09:00.0: vgaarb: deactivate vga console [ 39.491858] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 39.491864] Bluetooth: BNEP filters: protocol multicast [ 39.491869] Bluetooth: BNEP socket layer initialized [ 39.493104] Bluetooth: MGMT ver 1.23 [ 39.592576] fbcon: nvidia-drmdrmfb (fb0) is primary device [ 39.592581] fbcon: Deferring console take-over [ 39.592585] nvidia 0000:09:00.0: [drm] fb0: nvidia-drmdrmfb frame buffer device [ 39.611629] NET: Registered PF_QIPCRTR protocol family [ 39.617052] block nvme0n1: No UUID available providing old NGUID [ 40.228306] Generic FE-GE Realtek PHY r8169-0-800:00: attached PHY driver (mii_bus:phy_addr=r8169-0-800:00, irq=MAC) [ 40.387664] r8169 0000:08:00.0 enp8s0: Link is Down [ 43.606373] r8169 0000:08:00.0 enp8s0: Link is Up - 1Gbps/Full - flow control off [ 43.608294] r8169 0000:08:00.0 enp8s0: Link is Up - 1Gbps/Full - flow control off [ 97.359719] Bluetooth: RFCOMM TTY layer initialized [ 97.359731] Bluetooth: RFCOMM socket layer initialized [ 97.359736] Bluetooth: RFCOMM ver 1.11 After connecting USB: [31711.535161] usb 1-4: new full-speed USB device number 5 using xhci_hcd [31711.910839] usb 1-4: New USB device found, idVendor=047f, idProduct=02ee, bcdDevice=17.23 [31711.910844] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [31711.910846] usb 1-4: Product: Poly BT600 [31711.910849] usb 1-4: Manufacturer: Plantronics [31711.910851] usb 1-4: SerialNumber: <REDACTED> [31711.975575] mc: Linux media interface: v0.10 [31711.978474] input: Plantronics Poly BT600 as /devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-4/1-4:1.3/0003:047F:02EE.0007/input/input24 [31712.029394] plantronics 0003:047F:02EE.0007: input,hiddev98,hidraw6: USB HID v1.11 Device [Plantronics Poly BT600] on usb-0000:02:00.0-4/input3 [31712.645454] usbcore: registered new interface driver snd-usb-audio
I do not experience this anymore. But I did a reinstall with KDE Neon, so perhaps it's a leftover from an earlier installation? I have experience many bugs that were related to previous upgrades and were gone after a reinstall. The details of my current system: Operating System: KDE neon 6.2 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Kernel Version: 6.8.0-51-generic (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900 12-Core Processor Memory: 31,3 GiB of RAM Graphics Processor: NV174 Manufacturer: Alienware Product Name: Alienware Aurora Ryzen Edition R14 System Version: 2.18.0
I still experience this. Something I've noticed is that the screenlocker also is slow to recognize keyboard inputs. E.g. if the screen is sleeping, it seems like it needs a second or two before capturing those inputs, usually meaning the first 1 or 2 letters are missing from the input. I'm not sure if that's related to this bug, or a separate thing? Operating System: CachyOS Linux KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Kernel Version: 6.12.10-2-cachyos (64-bit) Graphics Platform: X11
Per Comment 62 this may be an issue with some incorrect configs. I see the same kscreenlocker_greet issue reported in Comment 39. Is there a way to backup existing config files and install default ones? My system is: Operating System: KDE neon 6.2 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Kernel Version: 6.8.0-52-generic (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060/PCIe/SSE2 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7D13 System Version: 1.0
Not sure if anyone else has had luck with this, but I found on my machine that I was initially unable to set "NVreg_PreserveVideoMemoryAllocations" to "0" by way of a config file in /etc/modprobe.d as a test (it stayed set to "1"). I wasn't aware, but there's another modprobe config file that gets installed with the driver at /usr/lib/modprobe.d/nvidia-power-management.conf that has this option set to 1. I renamed my config file in /etc/modprobe.d so it came after the included file (e.g., znvidia.conf), and I no longer have a black screen after waking from sleep. I do get a warning in the KDE notifications about a graphics reset, but I can live with that for now.
Re: nvidia conf files mentioned in Comment 64 -- I only have the following files: $ find / -name 'nvidia*.conf' -print 2>/dev/null /etc/modprobe.d/nvidia-graphics-drivers-kms.conf /usr/lib/modprobe.d/nvidia-graphics-drivers.conf /usr/share/doc/nvidia-driver-560/nvidia-dbus.conf $ cat /usr/lib/modprobe.d/nvidia-graphics-drivers.conf blacklist nouveau blacklist lbm-nouveau alias nouveau off alias lbm-nouveau off $ cat /etc/modprobe.d/nvidia-graphics-drivers-kms.conf # This file was generated by nvidia-driver-560 # Set value to 0 to disable modesetting options nvidia-drm modeset=1 fbdev=1 I think the last file did not include `fbdev=1` to begin with. I had to add it so that I could log into a Wayland session. Is there something I should do?
Created attachment 177997 [details] Journalctl output pertaining to KDE bug 483094 Attaching journalctl output from an impacted machine, because it is too long to just put inline.
Apologies for the double post, I just wanted to attach some journalctl output that was too long to inline. Doing so dumped the text or my original comment into /dev/null apparently. Here's my second draft: Posting to confirm that I'm having this issue too. Generally I lock the machine with meta+L, then turn off 2 monitors manually. If I leave the machine like this overnight, the next morning I usually have this problem. When I turn the monitors back on, the lock screen appears, and shows the current time. However, there is no username displayed, nor a password entry box. After showing the inital time of day, the clock is never updated again. This morning it read 8:42 until well after 9:00 when I rebooted. Journalctl doesn't show a lot, but the most suspicious lines are these: Feb 05 08:42:39 defiant kscreenlocker_greet[111312]: Device loss detected in vkQueueSubmit() Feb 05 08:42:39 defiant kscreenlocker_greet[111312]: Graphics device lost, cleaning up scenegraph and releasing RHI Of note, since another commenter mentioned that USB devices might play some role, is that my mouse and keyboard are connected through the USB hub in one of these monitors, and so they reconnect when I turn on that monitor. System details: Operating System: Arch Linux x86_64 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Kernel Version: 6.12.10-arch1-1 (64-bit) Graphics Platform: X11 Processor: AMD Ryzen 9 3950X (32) @ 4.762GHz Memory: 32010MiB Graphics Processor: NVIDIA GeForce GTX 980 Manufacturer: Gigabyte motherboard
The issue is still reproduced in plasma 6.3. the login screen is delayed for 20 seconds after wakeup from screenlock. kernel: 6.12.11 kscreenlocker-6.3.0 log: Feb 13 10:15:56 pc-i7 plasmashell[1768]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:79: TypeError: Cannot read property 'status' of null Feb 13 10:39:17 pc-i7 kscreenlocker_greet[15103]: QRhiGles2: Context is lost. Feb 13 10:39:17 pc-i7 kscreenlocker_greet[15103]: Graphics device lost, cleaning up scenegraph and releasing RHI Feb 13 10:39:17 pc-i7 kscreenlocker_greet[15103]: QRhiGles2: Context is lost. Feb 13 10:39:17 pc-i7 kscreenlocker_greet[15103]: Failed to create RHI (backend 2)
I started to experience this on one of my computers (Ubuntu 24.04.2). Curiously another machine with the same system is fine. Nvidias and plasma_x11 on both: - problematic: NVIDIA GP108 [GeForce GT 1030] - working OK: NVIDIA GK208B [GeForce GT 710] I have to kill -9 kscreenlocker_greet and loginctl unlock-session from terminal to unlock the screen. While the problem is there, kscreenlocker_greet thread named QSGRenderThread is occupying 100% CPU
Created attachment 178340 [details] htop during the problem (see QSGRenderThread)
Same here: arch linux kscreenlocker 6.2.5-1 running X11 (1.21.1.15), on wayland it is instant. NVIDIA GeForce RTX 3080 @ nvidia driver 570.86.16 > lut 15 18:27:06 xxxxxxxxx kscreenlocker_greet[43726]: QRhiGles2: Context is lost. > lut 15 18:27:06 xxxxxxxxx kscreenlocker_greet[43726]: Graphics device lost, cleaning up scenegraph and releasing RHI
Adding more information. I've been getting this problem for ages on my arch workstation. It has an nvidia TITAN X GPU with 2 monitors (hdmi and displayport) when using drivers 565.xx (and more recently 570.86.16), kscreenlocker_greet hangs when the monitor were sleeping. When it hangs I see this in journalctl: ``` Feb 17 06:32:09 rom kscreenlocker_greet[133962]: Graphics device lost, cleaning up scenegraph and releasing RHI Feb 17 06:32:09 rom kscreenlocker_greet[133962]: QRhiGles2: Context is lost. Feb 17 06:32:09 rom kscreenlocker_greet[133962]: Graphics device lost, cleaning up scenegraph and releasing RHI Feb 17 06:32:09 rom kscreenlocker_greet[133962]: QRhiGles2: Context is lost. ``` This morning I also noticed this in the kernel logs: ``` Feb 17 06:32:09 rom kernel: Code: 89 e5 41 54 53 48 83 ec 30 4c 8b 67 08 64 48 8b 1c 25 28 00 00 00 48 89 5d e8 48 89 fb 49 8b bc 24 80 00 00 00 48 85 ff 74 5f <48> 8b 07 ff 50 58 84 c0 74 55 e8 e1 e7 ff ff 48 39 d8 74 7c 49 8b Feb 17 06:32:09 rom kernel: QSGRenderThread[133993]: segfault at 100000000 ip 0000721dba4faff0 sp 0000721d6f7fd9f0 error 4 in libQt6Gui.so.6.8.2[4faff0,721dba0dd000+69c000] likely on CPU 2 (core 2, socket 0) ``` If i set `QT_QUICK_BACKEND=software` in ~/.config/environment.d/qt-quick.conf (and reboot), I can't reproduce the issue anymore. Also, when running nvidia drivers version aur/nvidia-550xx-dkms 550.144.03-1, the problem doesn't occur. this is all on: arch linux x11 (xorg-server 21.1.15-1) libplasma 6.3.0-1 kscreenlocker 6.3.0-1 linux 6.13.2.arch1-1 To reproduce, I lock the screen with my shortcut, the screens go to sleep. when moving the mouse, the login screen appear with the clock, but there's no password box. if I type my password blindly it will go back to my session eventually, probably after 20-30s.
Adding the x11-only keyword
I can confirm the issue with Kubuntu 24.10 and Plasma 6.1.5 and Nvidia. Unsure if it happens under Wayland on this machine... Wayland is still a bit too wonky for me with KDE+Nvidia. My laptop does use Wayland with an Intel iGPU (same OS/Plasma version) and it doesn't have this problem. The laptop does have a Nvidia discrete GPU, but that probably doesn't matter (except when playing games).
Adding to this thread: Brand new Arch Linux install, recently tested out some games in Steam with no issues/steady frame rates. Arch Linux Kernel 6.13.5 Plasma Version 6.3.2 AMD Ryzen 7 5700X NVIDIA Geforce RTX 4060 Ti Nvidia driver 570.124.04-1 When locking the screen manually with Win+L, there is no issue signing back in or hanging. However, when manually sending to sleep or when my PC naturally goes to sleep, on wake will go to a black screen with only mouse cursor visible and hangs. Have to hit ESC to get out, 15-20 second pause and then the login screen appears. Once logged in, the DE is laggy for a short period of time. I'm using breeze dark theme, not sure if that matters.
I had this happen on git-master yesterday. All I had done was to log out and log back in a few times (while testing another bug)
(In reply to jean from comment #72) > If i set `QT_QUICK_BACKEND=software` in > ~/.config/environment.d/qt-quick.conf (and reboot), I can't reproduce the > issue anymore. > Also, when running nvidia drivers version aur/nvidia-550xx-dkms > 550.144.03-1, the problem doesn't occur. I just upgraded an OpenSUSE Tumbleweed desktop from the 550 to 570.124 and I'm now experiencing this issue. I've managed to workaround the issue by using Jean's suggestion. I replaced kscreenlocker_greet with a script: mv /usr/libexec/kscreenlocker_greet /usr/libexec/kscreenlocker_greet.dist cat > /usr/libexec/kscreenlocker_greet <<EOF #!/bin/bash QT_QUICK_BACKEND=software /usr/libexec/kscreenlocker_greet.dist "$@" EOF chmod +x /usr/libexec/kscreenlocker_greet Having done the above, I haven't seen a reoccurrence. Looking at coredumpctl I cannot see any coredumps from kscreenlocker_greet (I do see a couple from sddm-greeter-qt6, presumably unrelated).
I've tried taking a look into the power management .conf files, changing the system sleep mode in systemd to deep, but to no avail. For whatever reason, logging into a Wayland session vs X11 fixes this issue for me. No more delay/black screen after wake from sleep, no more desktop crash/lag after logging in. Worth a try for those looking for a quick fix. Not sure if this is from the proprietary NVIDIA driver I'm using not playing well with X11, as I'm using the most recent driver.
(In reply to BradKessler from comment #78) > I've tried taking a look into the power management .conf files, changing the > system sleep mode in systemd to deep, but to no avail. > > For whatever reason, logging into a Wayland session vs X11 fixes this issue > for me. No more delay/black screen after wake from sleep, no more desktop > crash/lag after logging in. Worth a try for those looking for a quick fix. > Not sure if this is from the proprietary NVIDIA driver I'm using not playing > well with X11, as I'm using the most recent driver. Since switching 570.124, I tried to work around the issue, but also noted other problems. I restored my system from backup which took me back to Nvidia driver 550.144. I then reapplied all updates except for the nvidia driver. The desktop has reverted to behaving well. So the 570 driver, or the way it is being used seems to be the cause of the problems I was seeing. The repair system is configured as follows: Operating System: openSUSE Tumbleweed 20250305 KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.5-1-default (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 5600 6-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1650 SUPER Graphics Driver: nvidia-video-G06-550.144.03-30.1.x86_64 Manufacturer: ASUS
I can confirm: on my problematic machine I have nvidia-driver-570.
With 82% of telemetry-using Plasma users on Wayland, and KWin now split between Wayland and X11, X11 is going into formal maintenance-only mode now, so I'm downgrading the priority of this X11-only bug.
As discussed at: https://forums.opensuse.org/t/nvidia-570-sleep-and-lock-screen-issues/183639/16 https://forums.opensuse.org/t/nvidia-570-sleep-and-lock-screen-issues/183639/17 Disabling one or all of AllowGSYNCCompatible, ForceCompositionPipeline, and ForceFullCompositionPipeline may help with this issue. It seems to have helped on my desktop over the past few hours, but on my desktop the symptoms of fault can be a bit varied, so I'm waiting to see if everything is OK over the next day or two.
Just a note: the trick from comment 77 works for me. My Ubuntu version (comparing to comment 77: I use 'EOF' to preserve "$@", the directory is different, and I suggest creating script under new name to preserve it during upgrades): sudo -i cd /usr/lib/x86_64-linux-gnu/libexec cat > kscreenlocker_greet.sh <<'EOF' #!/bin/bash QT_QUICK_BACKEND=software /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet.dist "$@" EOF chmod a+x kscreenlocker_greet.sh # Reapply those two lines if upgrade overwrites kscreenlock_greet mv kscreenlocker_greet kscreenlocker_greet.dist cp kscreenlocker_greet.sh kscreenlocker_greet
Comment 83 does the trick for me too on kubuntu 24.04 LTS with Nvidia 570 and NVIDIA GeForce GTX 1050 Ti GPU
This issue is not reproduced after recent updates of Fedora 41. kernel: 6.14.9-200.fc41.x86_64 xorg-x11-drv-nvidia-575.57.08-1.fc41.x86_64 plasma-desktop-6.3.5-1.fc41.x86_64 No other tricks. Perhaps nvidia-driver 575.57.08?
(In reply to Aaron.Ma from comment #85) > This issue is not reproduced after recent updates of Fedora 41. > > kernel: 6.14.9-200.fc41.x86_64 > xorg-x11-drv-nvidia-575.57.08-1.fc41.x86_64 > plasma-desktop-6.3.5-1.fc41.x86_64 > > No other tricks. > > Perhaps nvidia-driver 575.57.08? I just updated my Arch/Manjaro system. After a quick test, it seems the issue is resolved, but I’ll continue testing during normal usage to confirm that the bug no longer occurs. It appears the updated NVIDIA driver fixed the problem. To summarize (according with all the comments in this thread): * Version 550 was bug-free * The issue appeared around version 560 * It seems to be resolved in version 575 ---- some of the packages updated by my system: linux-api-headers (6.14-1 -> 6.15-1) nvidia-utils (570.144-3 -> 575.64-1) lib32-nvidia-utils (570.144-1 -> 575.64-1) libnvidia-container (1.17.6-1 -> 1.17.8-1) linux612 (6.12.28-1 -> 6.12.34-1) linux612-headers (6.12.28-1 -> 6.12.34-1) linux612-nvidia (570.144-8 -> 575.64-2) nvidia-driver-assistant (0.21.51.03-1 -> 0.21.57.08-1) mhwd-nvidia (570.144-3 -> 575.64-1) inxi -G Graphics: Device-1: NVIDIA TU104 [GeForce RTX 2060] driver: nvidia v: 575.64 Display: x11 server: X.Org v: 21.1.18 with: Xwayland v: 24.1.8 driver: X: loaded: nvidia gpu: nvidia,nvidia-nvswitch resolution: 1: 2560x1440~60Hz 2: 3840x2160~60Hz API: EGL v: 1.5 drivers: nvidia,swrast platforms: gbm,x11,surfaceless,device API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 575.64 renderer: NVIDIA GeForce RTX 2060/PCIe/SSE2 API: Vulkan v: 1.4.313 drivers: nvidia surfaces: N/A Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console,kscreen-doctor gpu: nvidia-smi wl: wayland-info x11: xdpyinfo, xprop, xrandr
(In reply to Arthur Helsftein Fragoso from comment #86) > I just updated my Arch/Manjaro system. After a quick test, it seems the > issue is resolved, but I’ll continue testing during normal usage to confirm > that the bug no longer occurs. After many normal use tests, I can now confirm the bug no longer occurs to me after the update to nvidia driver 575.64
(In reply to Nate Graham from comment #81) > With 82% of telemetry-using Plasma users on Wayland, and KWin now split > between Wayland and X11, X11 is going into formal maintenance-only mode now, > so I'm downgrading the priority of this X11-only bug. I'm confused. This bug still happens, for me, on Wayland. Nothing has changed since I reported this back in 2024. I can't test on 6.4, but I can confirm it still happened on 6.3.5. Interestingly, when I woke the screen on Wayland, the sound for "unplugging" and "plugging in" something played (like, if you connect a USB flash drive).
(In reply to Once Solemn from comment #88) > (In reply to Nate Graham from comment #81) > > With 82% of telemetry-using Plasma users on Wayland, and KWin now split > > between Wayland and X11, X11 is going into formal maintenance-only mode now, > > so I'm downgrading the priority of this X11-only bug. > > I'm confused. This bug still happens, for me, on Wayland. Nothing has > changed since I reported this back in 2024. > I can't test on 6.4, but I can confirm it still happened on 6.3.5. > Interestingly, when I woke the screen on Wayland, the sound for "unplugging" > and "plugging in" something played (like, if you connect a USB flash drive). The error you were getting from "journalctl --user -r" is different than the error people with NVIDIA were having. I was getting: > kscreenlocker_greet[133962]: Graphics device lost, cleaning up scenegraph and releasing RHI > kscreenlocker_greet[133962]: QRhiGles2: Context is lost. And your output were: (In reply to Once Solemn from comment #50) > kscreenlocker_greet[17494]: pam_unix(kde:auth): authentication failure; logname=user uid=1000 euid=1000 tty= ruser= rhost= user=user > org_kde_powerdevil[1355]: dh=Display_Handle[i2c-4: fd=27], Keeping adjusted sleep multiplier 2,00 for SE_POST_WRITE or SE_POST_SAVE_SETTINGS > org_kde_powerdevil[1355]: Executed 1 registered callbacks. > org_kde_powerdevil[1355]: Emitting DDCA_Display_Status_Event( 10917.059: DDCA_EVENT_DPMS_AWAKE, card0-DP-1, dref: Display_Ref[bus /dev/i2c-4], io_path:/dev/i2c-4] > org_kde_powerdevil[1355]: stabilized_connector_names required 1 extra calls to get_sysfs_drm_connector_names() > kscreenlocker_greet[17494]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/MediaControls.qml:31:13: QML Image: Blocked request. > kscreenlocker_greet[17494]: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile > kscreen_backend_launcher[1442]: kscreen.xrandr: Emitting configChanged() > plasmashell[1273]: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile > plasmashell[1273]: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile > kscreen_backend_launcher[1442]: kscreen.xrandr: Output 87 : connected = false , enabled = false It seems to me it is complaining about a PNG having the incorrect color profile and being blocked. > MediaControls.qml:31:13: QML Image: Blocked request. > Image { > id: albumArt > Layout.preferredWidth: height > Layout.fillHeight: true > visible: status === Image.Loading || status === Image.Ready > asynchronous: true > fillMode: Image.PreserveAspectFit > source: model.artUrl > sourceSize.height: height * Screen.devicePixelRatio > } This seems to be the albumArt of the music player. Ksenia Turek from comment #24: > I can confirm that the bug still happens on Plasma version 6.1.4. > I also found a simple temporary workaround. > > I commented out the entire Image object with id: albumArt, starting at line 31 in the file you tried at comment #30: > I installed F40 to test the "solution" in Comment 24, but that file doesn't exist on this install. I would say, check what you are currently getting with "journalctl --user -r", if it shows the same MediaControls.qml message, try to locate that file and comment out the Image object.
Since it seems like it's not actually X11-specific (sorry!) and the NVIDIA manifestation is fixed now, I'm re-titling to reflect the fact that it's apparently not an issue specific to one GPU or session type. FWIW I have a Radeon 780M iGPU, and I can't reproduce it.
#89 I'll give that a shot next time I have to time to install Plasma again on that machine. #90 No harm done. I also didn't mean to come off as rude, or anything. Sorry if I did. Just wanted to clarify this actually also happened on Wayland. :p
I was recently on Tumbleweed with plasma 6.4.0 and Nvidia 570.169, and the problem seemed to happen a bit. Fortunately, once I applied the shell script workaround mentioned in comment #83, it seem to fully prevent any occurrences of the issue. I'm now on Tumbleweed with Plasma 6.4.1 and Nvidia 570.169. I've reverted the workaround to see if the situation has improved. The problem seems to happen less often (once in two days). On the only occurrence so far, after a delay of 30+ seconds, the greeter recovered. The following was in the journal: Jun 29 19:19:10 ... kscreenlocker_greet[16211]: QRhiGles2: Context is lost. Jun 29 19:19:10 ... kscreenlocker_greet[16211]: Graphics device lost, cleaning up scenegraph and releasing RHI Jun 29 19:19:10 ... kscreenlocker_greet[16211]: QRhiGles2: Context is lost. Jun 29 19:19:10 ... kscreenlocker_greet[16211]: Graphics device lost, cleaning up scenegraph and releasing RHI
(In reply to Michael Hamilton from comment #92) > I'm now on Tumbleweed with Plasma 6.4.1 and Nvidia 570.169. I've reverted > the workaround to see if the situation has improved. The problem seems to > happen less often (once in two days). On the only occurrence so far, after > a delay of 30+ seconds, the greeter recovered. The following was in the > journal: > > Jun 29 19:19:10 ... kscreenlocker_greet[16211]: QRhiGles2: Context is lost. > Jun 29 19:19:10 ... kscreenlocker_greet[16211]: Graphics device lost, > cleaning up scenegraph and releasing RHI > Jun 29 19:19:10 ... kscreenlocker_greet[16211]: QRhiGles2: Context is lost. > Jun 29 19:19:10 ... kscreenlocker_greet[16211]: Graphics device lost, > cleaning up scenegraph and releasing RHI That's the exact same problem I had. Idk the update schedule of openSUSE packages, but that will probably be fixed once you get the nvidia drivers version 575 or higher.
Ok, so this seems to have stopped being an issue for me on both X11 and Wayland. However, there still seems to be an issue when waking up. On Wayland, the sound for unplugging plays, and then the sound for plugging in. The lockscreen doesn't seem to accept any keystrokes before the plug-in sound. On X11 this also seems to happen, it doesn't play any of those sounds, though. I'm unsure if this is a separate issue that needs a new report, or if it's related? Current versions: Operating System: CachyOS Linux KDE Plasma Version: 6.4.3 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 Kernel Version: 6.16.0-5-cachyos (64-bit) (and kernel 6.15) Mesa 25.1.5
Just to clarify, hitting a key on the keyboard still wakes the monitor. It just seems to not pickup the keypresses in the password field for a few seconds.
Is any of this reproducible in a new clean user account on the same machine?
> Is any of this reproducible in a new clean user account on the same machine? Previously I saw the issue on the same machine, but with a GTX 1650 Super and the G06-570.169 driver. The GPU and driver have changed to an RTX 3060 and the G06-575. I can no longer test the previous configuration. The new configuration is functioning correctly with no repeat of this issue. I have moved my GTX 1650 Super to a different machine which uses the G06-570.172 driver. This machine is also behaving correctly. But this second machine has only one FHD monitor and a slower CPU, so I'm not sure if it's comparable.
Cool, it sounds like the originally-reported issue here is fixed for people now. If there are any new issues, please open new bug reports for them. Thanks!