Page MenuHomeSolus

KDE plasma hangs when locking screen with nvidia 450.57
Closed, WontfixPublic


When resuming from sleep, I log in and everything's fine but once I lock the screen again (super + l) it freezes at desktop instead of going to lock screen and it becomes unresponsive. The only way to solve this behavior is to try tty (ctrl + f2) and use either loginctl to terminate user or systemctl to reboot the machine. It didn't happen with 440.100 so I assume it has to do with the newer NVIDIA binaries.

Event Timeline

Framani created this task.Jul 15 2020, 2:19 PM

Hmm that is weird..i just updated to 450.57 version from today's sync..can't able to reproduce and works from my end !

I have a GTX 1660 super and it keeps happening! It works perfectly under windows 10. I now keep getting a black screen and cursor on screen when resuming from sleep. I do not know what might be happening. I guess I'll move to different binaries and try from there.

Jacek added a subscriber: Jacek.Jul 17 2020, 6:42 PM

You could uninstall the current drivers and try with nvidia beta current or nvidia developer current.

Hey, thanks for answering but I've tried with the three branches offered by the solus team (beta, developer and glx) and the result has been always the same. Something fishy must've happened with my installation and I don't really want to start from scratch. I run "sudo eopkg check" to verify no package was broken and no issues were found. I delete cache and remove orphan packages (dc and rmo) in hopes that some packages had corrupted and messed with something but nothing has changed. I really have no idea what might be happening. I have the plasma version BTW, could it be that plasma is still buggy?

Bread added a subscriber: Bread.EditedJul 19 2020, 8:11 PM

I'm not using this OS but I'm having the same issue so hopefully it's okay if I post.

I'm pretty sure this is an issue with Plasma & Nvidia drivers as you figured. I'm on Arch; I found a Reddit thread that details something similar, that person was on Ubuntu so it's likely a universal Plasma & Nvidia issue.

I did not have this issue before completely nuking my KDE install 2 days ago (I had some corrupted files), despite my system being fully up-to-date with latest drivers etc (editing to clarify that I did have the newest 450.57). I'm attempting to figure out what the difference was between my non-nuked KDE install and my current one in hopes that I can find a solution or workaround for this issue. If I learn anything, I'll update this post.

Framani added a comment.EditedJul 19 2020, 8:33 PM

A few days after I posted my previous reply, I decided to reinstall and the issue remains there. I've read that people with non-turing GPUs are not having issues and as I mentioned before previous glx version 440.100 didn't present the same problematic, so my 2 cents are on faulty NVIDIA drivers... but I know nothing, I'm no programmer but a curious linux user willing to learn something new everyday. Thanks for supporting my doubts.

I have updates to my issue. I think the culprit is KDE plasma's lock screen. I tried "loginctl unlock-sessions" and I was able to access my session. Is there any fix to this? It's not a big problem for me though I'd like for it to be fixed if possible.

DataDrake edited projects, added Plasma; removed Lacks Project.
Girtablulu closed this task as Wontfix.Nov 14 2020, 9:31 PM

We are on newer versions of nvidia and plasma, please reopen this if you still having the issue

I am on 455.38 and plasma 5.18.5, with the same issues, KDE plasma lock screen continues to freeze on lock.

@AlekEagle Well, we are on 460.32.03 and Plasma 5.20.4 (.5 in Unstable). I'm especially perplexed that your Plasma version is that old; 5.19 landed in July 2020.

I'm running 455.38 for steam support. I'm even more perplexed considering this was a fresh install of Kubuntu 20.04 that I grabbed on the 25th.

DataDrake added a subscriber: DataDrake.EditedJan 14 2021, 3:52 AM

@AlekEagle This is a Solus bug tracker, not Kubuntu's. There are many many differences in the versions, configurations, and integrations of the packages available to both distros. Unless someone can reproduce this on an up-to-date version of Solus, this Task will remain closed. Closing tasks which have not seen any activity in several months is a normal process on the bug tracker and helps us to ensure active support requests get more attention.