LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 07-09-2019, 11:10 AM   #1
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 221

Rep: Reputation: 65
Win+L to lock screen causes unresponsive desktop (kwin 100% CPU)


Beginning yesterday the Win+L key combination, which is mapped to "Lock Session" in the KDE System Settings -> Shortcuts and Gestures -> Global Keyboard Shortcuts -> The KDE Session Manager, causes my desktop to become unresponsive (switching to VT-2 I can see that kwin is at 100% CPU).

Switching to VT-1 I see the message:
kwin(29781) KWin::checkGLError: GL error ( PostPaint ): "GL_INVALID_OPERATION"

I'm running Slackware 14.2 + alien's multilib, kernel 4.19.57 (using essentially the same kernel config as -current). I use xscreensaver and followed the directions here (https://www.jwz.org/xscreensaver/man1.html#9) to force KDE to use xscreensaver. I have NVIDIA's 430.26 driver installed using their *.run script. I use run level 3 and run "startx" to start my KDE session.

I made the following upgrades yesterday that could potentially have introduced the problem, but have not tried reverting any changes yet:
xscreensaver: 5.42 -> 5.43 (-14.2 patches)
kernel: 4.19.56 -> 4.19.57 (compiled myself)

Trying to find the source of the problem I have determined that:
The "xscreensaver -lock" command still works correctly. It starts the screensaver.
Running (my modified) /usr/lib64/kde4/libexec/kscreenlocker_greet still works correctly.
Waiting for the screen saver to launch from inactivity still works correctly.
Changing the "Lock Session" keyboard shortcut back to the default Ctrl+Alt+L and using it causes an unresponsive desktop.
Issuing the command "qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock" causes an unresponsive desktop. (found that from here: https://forum.kde.org/viewtopic.php?t=111003) I assume the global keyboard shortcut issues this command?

Is there anything else I can do to find the source of the problem? I can try downgrading the kernel from 4.19.57 to 4.19.56 to see if that restores normal functionality. I noticed that just today NVIDIA released a new driver (430.34), so I can try upgrading to that as well.


Edit:
Downgrading to kernel 4.19.56 didn't help.
Upgrading to nvidia driver 430.34 didn't help.

Edit:
Solution found in comment #8:
https://www.linuxquestions.org/quest...0/#post6014122

Last edited by drumz; 07-11-2019 at 12:42 PM.
 
Old 07-09-2019, 12:48 PM   #2
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 221

Original Poster
Rep: Reputation: 65
Surprisingly, it is xscreensaver. Downgrading to 5.42 allows Win+L to work again.

The "qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock" command also locks the screen as expected.

Now the question is what changed in xscreensaver 5.43 to cause the problem?
 
Old 07-09-2019, 01:32 PM   #3
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 221

Original Poster
Rep: Reputation: 65
So I extracted and compared the sources. Lots of changes. Since jwz doesn't provide individual patches, I can't bisect. For now I'm sticking with xscreensaver-5.42-x86_64-1_slack14.2.
 
Old 07-09-2019, 07:14 PM   #4
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 221

Original Poster
Rep: Reputation: 65
I was able to reproduce in VirtualBox:

Installed Guest Additions to make "startx" work.
Forced KDE to exclusively use xscreensaver (https://www.jwz.org/xscreensaver/man1.html#9).

Issuing "qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock" using xscreensaver 5.43 causes the desktop to freeze (though kwin does not show 100% CPU).

Comparing the 5.42 and 5.43 sources, maybe I'll selectively revert changes to try to find the cause.
 
Old 07-10-2019, 06:33 AM   #5
linuxtinker
Member
 
Registered: Dec 2013
Location: NJ / USA
Distribution: Slackware 64 -Current
Posts: 212

Rep: Reputation: 93
When updating your system did you also update your "multilib" files?
 
Old 07-10-2019, 09:35 AM   #6
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 221

Original Poster
Rep: Reputation: 65
Quote:
Originally Posted by linuxtinker View Post
When updating your system did you also update your "multilib" files?
There were no relevant multilib packages to update.
 
Old 07-10-2019, 02:05 PM   #7
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 221

Original Poster
Rep: Reputation: 65
Discovered some more things while trying out xscreensaver 5.43 in a virtual machine, using the "qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock" to try to launch the screen saver.

Switching to a virtual terminal and monitoring processes using "top", I noticed that the PID of xscreensaver-command was changing every few seconds. By examining the /proc directory, I was able to determine that the parent process of "xscreensaver-command -lock" was "/bin/sh /usr/lib64/kde4/libexec/kscreenlocker_greet --immediateLock" (because remember I've modified kscreenlocker_greet per https://www.jwz.org/xscreensaver/man1.html#9), and the parent process of that was "kdeinit4: ksmserver [kdeinit]".

So what I think is going on is that KDE's ksmserver launches kscreenlocker_greet, which is a shell script that launches xscreensaver-command. xscreensaver-command fails to do what it is supposed to do for whatever reason, and either dies or is killed by ksmserver. ksmserver then tries launching kscreenlocker_greet again, resulting in an endless loop.

With xscreensaver 5.42, "xscreensaver-command -lock" successfully launches the screen saver and then the process exits, leaving only the "xscreensaver" daemon process running, which manages running all the hacks.

Something about the interaction between ksmserver and xscreensaver-command is causing the problem, as manually issuing "xscreensaver-command -lock" successfully launches the screen saver.
 
Old 07-11-2019, 10:20 AM   #8
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 221

Original Poster
Rep: Reputation: 65
Ok, I've figured out how to make 5.43 work without creating an unresponsive desktop:

1. Make the KDE "Lock Session" action do nothing.
System Settings -> Shortcuts and Gestures -> Global Keyboard Shortcuts -> KDE component: The KDE Session Manager
Set "Lock Session" to Custom: None

2. Add a custom global shortcut that calls "xscreensaver-command -lock"
System Settings -> Shortcuts and Gestures -> Custom Shortcuts
Click Edit -> New -> Global Shortcut -> Command/URL
Name it xscreensaver, set the trigger to Meta+L, and set the Action to "xscreensaver-command -lock"

3. For good measure, edit kscreenlocker_greet to do nothing so that if the KDE "Lock Screen" command is issued nothing happens, which is better than having an unresponsive desktop.

Of course, the command:
qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock
will still lead to an unresponsive desktop, so don't do that!


After editing kscreenlocker_greet to do nothing, the "qdbus" command to lock the screen will do nothing as well. So no more need to worry about unresponsive desktop!

Last edited by drumz; 07-11-2019 at 12:48 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
opengl causes kwin to crash rbees Linux - Desktop 5 02-22-2012 05:04 PM
deian yum lock [ ERR] Reading state information E: Could not get lock /var/lock/aptit jayakumar01 Linux - Server 1 12-05-2011 11:26 AM
Shutting down OpenIndiana doesn't work, causes CPU 100% instead spoovy Solaris / OpenSolaris 5 08-30-2011 03:05 AM
ACPI causes 100% CPU When Lid Closed carstenson Linux - Laptop and Netbook 5 05-07-2009 08:55 AM
Dragging and dropping causes 100% cpu spike? DragonM15 Linux - Software 4 01-22-2009 12:37 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 12:24 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration