Bug 314663

I have exactly the same issues on openSuse 12.2, mouse and keyboard input other than super X keys are ignored, but it doesn't happen every time the screen locks.  If I go to unlock the screen the underlying desktop is immediately displayed rather than the unlock screen and I can only recover vie ctrl-alt-dbackspace.  On Thiago's advice I switched to the virtual console and ran "xwininfo -display :0" which complained it couldn't grab the mouse.  This apparently means an app froze up while it held the X grab, but killing all running apps failed to release the lock, so my assumption is that the screen locker itself has frozen.

I have the exact same behaviour!

Any ideas if someone's working on  a fix? This kills the desktop for me. I need to be able to lock my desktop. Right now, not only I can't lock, but trying to do so means restarting kde, killing all apps running in it. This is a serious bug.

There is some generic (library level) mouse grabbing issue with KDE. If I enable "Mouse Navigation" using the numpad, just pressing shift-insert is enough to lock my mouse. Nothing works after that. Only option is to ctrl-alt-f1, login and issue the 'export DISPLAY=:0 ; qdbus org.kde.ksmserver /KSMServer logout 0 0 0' to logout and log back in.

This used to work at some point obviously!

Is anybody working on this very serious issue? How are people locking there workstations without the fix for this bug?

I give up and move to use xlock....:)

You can work around the bug by going into System Settings / Display and Monitor / Screen Locker and selecting the "Simple Locker" type.  After that it works fine.

John: are u even reading the bug report?....:-) Simple Locker is what is broken. At least for me.

"How are people locking there workstations without the fix for this bug?"

If simple locker worked, I wouldn't ask that...or move to xlock...:D

But here is a clue I got: running /usr/lib/kde4/libexec/kscreenlocker_g segfaults. So, ksmserver keeps on spawning it, input is frozen in the mean time because of locker process segfaulting.

Not much but see if it helps:

(gdb) bt
#0  0x080590a3 in ScreenLocker::UnlockApp::desktopResized() ()
#1  0x00000000 in ?? ()

disassemble:

   0x08059023 <+4403>:  je     0x8058b12 <_ZN12ScreenLocker9UnlockApp14desktopResizedEv+3106>
   0x08059029 <+4409>:  mov    0x94(%esp),%eax
   0x08059030 <+4416>:  mov    %eax,(%esp)
   0x08059033 <+4419>:  call   0x8051170
   0x08059038 <+4424>:  mov    0x180(%esp),%edx
   0x0805903f <+4431>:  movl   $0x0,0x10(%esp)
   0x08059047 <+4439>:  movl   $0x805f372,0xc(%esp)
   0x0805904f <+4447>:  movl   $0x805f383,0x4(%esp)
   0x08059057 <+4455>:  mov    %eax,(%esp)
   0x0805905a <+4458>:  mov    %edx,0x8(%esp)
   0x0805905e <+4462>:  call   0x80504d0
   0x08059063 <+4467>:  jmp    0x8058b12 <_ZN12ScreenLocker9UnlockApp14desktopResizedEv+3106>
   0x08059068 <+4472>:  nop
   0x08059069 <+4473>:  lea    0x0(%esi,%eiz,1),%esi
   0x08059070 <+4480>:  lea    0xc0(%esp),%eax
   0x08059077 <+4487>:  movl   $0x805f353,0x4(%esp)
   0x0805907f <+4495>:  mov    %eax,(%esp)
   0x08059082 <+4498>:  call   0x8051010
   0x08059087 <+4503>:  sub    $0x4,%esp
   0x0805908a <+4506>:  mov    0xc0(%esp),%eax
   0x08059091 <+4513>:  mov    0xc(%eax),%edi
   0x08059094 <+4516>:  mov    0x94(%esp),%eax
   0x0805909b <+4523>:  mov    %eax,(%esp)
   0x0805909e <+4526>:  call   0x8051170
=> 0x080590a3 <+4531>:  mov    (%eax),%edx
---Type <return> to continue, or q <return> to quit---
   0x080590a5 <+4533>:  mov    %eax,(%esp)
   0x080590a8 <+4536>:  call   *(%edx)
   0x080590aa <+4538>:  mov    %edi,0x4(%esp)
   0x080590ae <+4542>:  mov    %eax,(%esp)
   0x080590b1 <+4545>:  call   0x80502d0
   0x080590b6 <+4550>:  mov    0xc0(%esp),%edx
   0x080590bd <+4557>:  mov    %eax,%edi
   0x080590bf <+4559>:  lock decl (%edx)
   0x080590c2 <+4562>:  setne  %al
   0x080590c5 <+4565>:  test   %al,%al
   0x080590c7 <+4567>:  jne    0x80590d8 <_ZN12ScreenLocker9UnlockApp14desktopResizedEv+4584>
   0x080590c9 <+4569>:  mov    0xc0(%esp),%eax
   0x080590d0 <+4576>:  mov    %eax,(%esp)
   0x080590d3 <+4579>:  call   0x80510f0
   0x080590d8 <+4584>:  cmp    $0xffffffff,%edi
   0x080590db <+4587>:  je     0x8058a3b <_ZN12ScreenLocker9UnlockApp14desktopResizedEv+2891>

Can confirm here (Kubuntu 13.04, kde-workspace-bin Version: 4:4.10.1b-0ubuntu1)  - Simple Locker returns a black screen with no way to unlock.  Switching to Desktop Widgets allows me to unlock the screen.

Anybody doing anything for this bug? It locks the system hard and should be considered a blocker bug.

Is the simple locker the default setting for a fresh user account?

I can confirm this bug. Upgraded to 13.04 (from 12.10, which was updated from 12.04).

(In reply to comment #12)
> I can confirm this bug. Upgraded to 13.04 (from 12.10, which was updated
> from 12.04).

Vote for it then. I still am stunned at the lack of attention this bug gets. You lock your screen, you have to kill the whole desktop to use it again. How can a bug like this go unfixed in so many releases?

Created attachment 81590 [details]
Strace of kscreenlocker_greet

I had a similar problem then found this thread the other day. I uploaded my strace of the process.

https://bugs.kde.org/show_bug.cgi?id=322582

I found the culprit on my side.  I fixed the problem by disabling Bespin’s translucency for kscreenlocker and kscreenlocker_greet.

Could you elaborate? I'm not familiar with Bespin and/or how to disable this.

(In reply to comment #16)
> I found the culprit on my side.  I fixed the problem by disabling Bespin’s
> translucency for kscreenlocker and kscreenlocker_greet.

(In reply to comment #17)
> Could you elaborate? I'm not familiar with Bespin and/or how to disable this.
> 
> (In reply to comment #16)
> > I found the culprit on my side.  I fixed the problem by disabling Bespin’s
> > translucency for kscreenlocker and kscreenlocker_greet.

System Settings → Application Appearance → Configure → Windows → Translucent Windows (Experimental!) → Exclude.

Confirmed that adding kscreenlocker and kscreenlocker_greet to Bespin's translucency exclusion list resolves the problem.
We should also verify if other style engines that do window transparency (Oxygen Transparent, and QtCurve (and the gtk engine?)) also have this problem and if so is there (currently) a way to disable transparency for these specific applications, or if further changes need to be made to those engines.

I don't have the settings mentioned above. I am using plain Oxygen as my style. How do I get past the frozen input on locking screen?

I use Qtcurve for GTK apps.

QtCurve confirmed to have the problem when in QtCurve's config dialog, under Opacity the Windows opacity percent is less than 100%. 
    Fix: under Applications, ensure that kscreenlocker_greet (in addition to kscreenlocker) is included in the No background opacity list.

Oxygen Transparent confirmed to have the problem.
    Fix: in Oxygen Transparent's config -> General -> Exceptions... -> check kscreenlocker and add kscreenlocker_greet

(In reply to comment #20)
> I don't have the settings mentioned above. I am using plain Oxygen as my
> style. How do I get past the frozen input on locking screen?
> 
> I use Qtcurve for GTK apps.

I tried it just now with vanilla Oxygen (4.10) and did not run into the problem - the screensaver displayed as expected, on user input the screenlocker showed up and I was able to unluck as expected.

(btw, I found the following command to work in KDE 4.10 to disable the screenlocker if it can't be unlocked by normal means:
qdbus org.kde.kscreenlocker_greet-xxxx /MainApplication quit
replacing xxxx with the pid of the kscreenlocker_greet process)

Removing Qtcurve from GTK and disabling translucency altogether does not fix this issue for me. The input still freezes and kscreenlocker_g keeps on getting reforked.

> qdbus org.kde.kscreenlocker_greet-xxxx /MainApplication quit 
> replacing xxxx with the pid of the kscreenlocker_greet process)

That won't work if  kscreenlocker_greet PID is changing every 1 second, meaning kscreenlocker_greet is SEGV'ing repeatedly. Please read my responses above.

(In reply to comment #19)
> Confirmed that adding kscreenlocker and kscreenlocker_greet to Bespin's
> translucency exclusion list resolves the problem.

Interesting.
The Problem here will be that turning a window ARGB in fact creates a new (with new WId)

I'll blacklist them internally.

The window can for later Bespin (and Oxygen-Transparent, Hugo?) versions add 1<<4 to the dynamic Qt property "KStyleFeatureRequest" (not simply override it, but fetch the property value().toUInt() and set it back or'd by 1<<4

*** Bug 328021 has been marked as a duplicate of this bug. ***

I recently made a report, which could be about same bug, but in 4.11.3 too: https://bugs.kde.org/show_bug.cgi?id=327567

(In reply to comment #27)
> I recently made a report, which could be about same bug, but in 4.11.3 too:
> https://bugs.kde.org/show_bug.cgi?id=327567

Oops, wrong bug. I just picked kwin-related bug from My Bugs saved searches. I did one yesterday, but many of them are not in list.

I found one reason why this bug happens: kscreenlocker_greet has a dependency on kdm, at least on Sabayon Linux. It needs some plugins provided by the kdm package which is why it crashes repeatedly.

Just installing kdm made screenlocking work for me. There's a related KDE bug https://bugs.kde.org/show_bug.cgi?id=314901 and a related Sabayon bug https://bugs.sabayon.org/show_bug.cgi?id=4235

(In reply to comment #29)
> I found one reason why this bug happens: kscreenlocker_greet has a
> dependency on kdm, at least on Sabayon Linux. It needs some plugins provided
> by the kdm package which is why it crashes repeatedly.
> 
> Just installing kdm made screenlocking work for me. There's a related KDE
> bug https://bugs.kde.org/show_bug.cgi?id=314901 and a related Sabayon bug
> https://bugs.sabayon.org/show_bug.cgi?id=4235

I can confirm this on sabayon. Installed kdm and everything worked as expected.

(In reply to comment #21)
> QtCurve confirmed to have the problem when in QtCurve's config dialog, under
> Opacity the Windows opacity percent is less than 100%. 
>     Fix: under Applications, ensure that kscreenlocker_greet (in addition to
> kscreenlocker) is included in the No background opacity list.

Confirmed that the issue is present on KDE 4.12.2 with QtCurve:
Name        : qtcurve-kde4
Arch        : x86_64
Version     : 1.8.14
Release     : 3.fc20 

I had to add kscreenlocker_greet to both the opacity and gradient exceptions for QtCurve in order to get the normal greeter.

Is this an issue that can be fixed within KDE, or should it also be filed against QtCurve/Oxygen Transparent/Bespin?

The issue should already be fixed in QtCurve.

As in Bespin.
The locker could (and probably should) however be hardened against WId changes, since they can happen for other reasons as well (though most prominently altering the colortable, oc.)

(In reply to comment #32)
> The issue should already be fixed in QtCurve.

Ah, cheers for the heads up; didn't realize you are the current maintainer of QtCurve ;). Removed the packaged version, installed the latest git version and was able to safely remove kscreenlocker_greet from the exceptions. The screen locker is drawn properly.

Is there a more verbose explanation of how to get rid of this problem when you experience it on a machine. It seems that it depends on the graphics card or some other issue. I am using 3 machines running kubuntu 13.10 running KDE 11.4.5 and only one of these machines seems to have this problem. I do not have the time to install updated packages from some repositories I don't know about and would be glad if there was a fix distributed by the standard update mechanism.

Thanks for your support.

In summary it looks to me like this issue is fixed:
* bespin: fixed
* QtCurve: fixed
* oxygen-tranparent: fixed

As the problem doesn't occur with the default widget style as shipped by Plasma I'd say that there is nothing which we could do in addition.