Bug 357007 - kscreenlocker_greet unresponsive when using compositor
Summary: kscreenlocker_greet unresponsive when using compositor
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.5.5
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-21 17:22 UTC by G360
Modified: 2016-08-29 18:13 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
glxinfo (98.08 KB, text/plain)
2016-01-12 14:20 UTC, G360
Details
"qdbus org.kde.KWin /KWin supportInformation" (5.81 KB, text/plain)
2016-03-06 22:16 UTC, G360
Details
After killing kwin_x11 (385.68 KB, image/jpeg)
2016-03-06 22:20 UTC, G360
Details
then, screenshot after killing kscreenlocker (96.52 KB, image/png)
2016-03-06 22:25 UTC, G360
Details
jmux KWin support info (5.55 KB, text/plain)
2016-03-08 10:43 UTC, Jan-Marek Glogowski
Details
jmux full es2_info output (2.29 KB, text/plain)
2016-03-14 10:30 UTC, Jan-Marek Glogowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description G360 2015-12-21 17:22:52 UTC
When using the kwin_x11 compositor, sometimes the screenlocker is unresponsive, like it is freezed. Switching to a TTY and back to the locker "unfreezes" everything and it is possible to enter the password.

When disabling the compositor Sift+ALT+F12, the locker doesn't freeze, it works as expected.

Reproducible: Sometimes




When it is "freezed", it is possible to enter the password and press Enter, but the screen doesn't change. A switch to a virtual console and back shows the unlocked desktop.

I have observed this behavior not only in version 5.5.x, but also with version 5.4
Comment 1 G360 2015-12-21 17:25:37 UTC
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R3 Graphics]

linux 4.2.5 (x86_64)
xf86-video-ati 7.6.1
xorg-server 1.18.0
mesa 11.0.7
qt5-base 5.5.1
KF 5.17
Comment 2 G360 2015-12-21 18:16:03 UTC
Just tried using KWin with compton as compositor and the same problem.
Comment 3 Martin Flöser 2016-01-03 09:08:22 UTC
is this also happening without any compositor? E.g. using KWin, but have compositing disabled?
Comment 4 G360 2016-01-03 14:23:26 UTC
This does mit happen without compositor.
Comment 5 G360 2016-01-03 15:38:45 UTC
I mean, it does not happen.
Comment 6 Martin Flöser 2016-01-04 09:53:40 UTC
what about using XRender?
Comment 7 G360 2016-01-07 01:47:57 UTC
With XRender the lockscreen seems to be responsive every time.
Comment 8 Martin Flöser 2016-01-11 09:25:25 UTC
So in summary: the greeter freezes whenever an OpenGL compositor is used. This sounds a lot like a GPU/driver issue. Could you provide me the output of glxinfo?
Comment 9 G360 2016-01-12 14:20:17 UTC
Created attachment 96602 [details]
glxinfo

It does not freeze always, but sometimes, using the OpenGL compositor.
Comment 10 Martin Flöser 2016-01-13 07:27:45 UTC
Looks like quite good hardware/driver combo. I'm starting more and more to become clueless on what's the problem here. Sorry :-(
Comment 11 G360 2016-01-15 03:43:04 UTC
If you don't know what the problem is, then I am out of luck, hehe!

Anyway thank you for your time.
Comment 12 mrl586 2016-01-20 12:11:58 UTC
I think that this problem is possibly related to breeze desktop theme. Because if using any other desktop theme than breeze (but not breeze based theme), kscreenlocker works normally.
Comment 13 G360 2016-02-13 17:34:41 UTC
Now (after some updates), when running with the compositor, kscreenlocker_greet doesn't respond even after switching to a TTY and back. After killing the process, and it being self-restarted plasmashell becomes unresponsive.

I'll test using another theme as suggested by mrl586.
Comment 14 G360 2016-02-13 19:04:43 UTC
I can confirm that kscreenlocker_greet works without problems using Caledonia as Plasma theme. The problem occurs using Breeze.
Comment 15 G360 2016-02-24 01:08:14 UTC
Now it seems that with Caledonia the same issue continues, and it just happen using Oxygen as Plasma theme. All this with compositor enabled.

A note about the freeze, now the locker freezes and there is no workaround I'm aware of, to unfreeze it. I have to kill it sending signal 9. With signal 15 it doesn't respond.
Comment 16 G360 2016-03-05 01:52:31 UTC
This issue is going worse, but now I think it is caused by KWin. 

When using Openbox and with compton as compositor the problem is gone, kscreenlocker_greet works all the time. kwin_x11 --replace and locking the screen makes everything unusable (windows don't react or react strange to keyboard or mouse input) , openbox --replace makes the desktop usable again.
Comment 17 Thomas Lübking 2016-03-06 10:52:41 UTC
What is
> react strange to keyboard or mouse input
?
Comment 18 Thomas Lübking 2016-03-06 20:04:32 UTC
PS, please attach the output of "qdbus org.kde.KWin /KWin supportInformation"
Comment 19 G360 2016-03-06 22:16:25 UTC
Created attachment 97728 [details]
"qdbus org.kde.KWin /KWin supportInformation"
Comment 20 G360 2016-03-06 22:16:48 UTC
I can not reproduce that, but other odd things happen. It was, Alt+Tab not working, Alt+F4 neither, mouse clicks don't works.

Sometimes kscreenlocker works but after unlocking, screen parts which update, flicker. 

I'll also attach some pictures and screenshots.
Comment 21 G360 2016-03-06 22:20:09 UTC
Created attachment 97729 [details]
After killing kwin_x11

kscreenlocker is active/shown, but without reacting to keyboard input, password is entered, without screen being updated. Then after killing kwin_x11, some Firefox tabs are shown.
Comment 22 G360 2016-03-06 22:25:31 UTC
Created attachment 97730 [details]
then, screenshot after killing kscreenlocker

the left Plasma panel is not shown, only an empty transparent section, showing the kscreenlocker background (not my plasma wallpaper). The button panel is shown but without widgets.
After invoking kwin_x11, the screen flickers when updating content. Killing and restarting kwin_x11 makes everything work again. Locking the screen and unlocking works too. But usually, after n times it won't work. 

All this with kwin compositor OpenGL 2 or 3.
Comment 23 Thomas Lübking 2016-03-06 23:06:20 UTC
- Have you tried EGL compositing?
- Was/is the konsole window in the second shot interactable?

The entire thing looks pretty much like the driver fails to keep the compositor and the QtQuick GL contexts apart, but the "kwin + compton == bad, openbox + compton == good" part is pretty odd.


About the input behavior:
Global shortcuts are certainly not supposed to work (in general) while the screen is locked - if you had been able to close the locker by pressing Alt+F4 or Alt+tab out of it, that would certainly have been a bug.
Comment 24 G360 2016-03-06 23:52:40 UTC
> - Have you tried EGL compositing? 
I haven't tried EGL. And I don't known how to do it. Is that the 'OpenGL interface' in System Settings? That combobox is disabled in my system.
And I haven't tried KWin + compton (will do it now), only the KWin build-in compositor, and openbox+compton.

> - Was/is the konsole window in the second shot interactable?
Yes it was interactable.

> About the input behavior
What I meant with "kwin_x11 --replace and locking the screen makes everything unusable (windows don't react or react strange to keyboard or mouse input)", was that Ctrl+Alt+L didn't show the kscreenlocker greeter, I don't know if it started maybe yes, as it brought problems for input.
Comment 25 Thomas Lübking 2016-03-07 09:58:02 UTC
Comment #2 said "Just tried using KWin with compton as compositor and the same problem."

> Is that the 'OpenGL interface' in System Settings?
Yes, but while hidden when you select XRender, it's never supposed to be disabled (there's simply no code that does such) - and in your case should list GLX & EGL

> Yes it was interactable.
So either the screenlocker are artifacts in the framebuffer or the konsole window managed to raise above the screenlocker.
=> What exactly did you kill?
The actual locker is ksmserver and the greeter should be restarted immedately (and no client should be exposed interim because ksmserver also holds a black barrier window.

> was that Ctrl+Alt+L didn't show the kscreenlocker greeter
Ie. the screen gets locked, but the greeter doesn't show up - it will likely crash.

=> try to invoke the greeter directly instead of locking the screen:
    /usr/lib/kscreenlocker_greet --testing
maybe
   /usr/lib/libexec/kscreenlocker_greet --testing
Comment 26 G360 2016-03-08 02:33:14 UTC
> Comment #2 said "Just tried using KWin with compton as compositor and the same problem."

I don't remember that :)
There are to many variables I forgot that one.

> Yes, but while hidden when you select XRender, it's never supposed to be disabled (there's simply no code that does such) - and in your case should list GLX & EGL

This is also strange. The combobox was empty while OpenGL 2.0 or 3 where selected. Now I see the options (now sure what changed) and I have selected EGL.

But now, after using kwin_x11 with compton, then selecting EGL and applying, kwin seems to be frozen. Killing it makes the GUI intractable again. I can reproduce this and open a new bug report if you like.

> What exactly did you kill?

I will try to be more descriptive:
A timeout has passed and the screen locked. The locker was frozen or it was kwin, but the screen did not react to keyboard input or mouse clicks, only the cursor could be moved around. Then I entered the password and Enter; nothing changes on screen. Then I switched to TTY 2 to kill kwin_x11, back to TTY 1 and I see those Firefox tabs (first screenshot). So I kill kscreenlocker_greet, which changes the screen content to my desktop, showing a window and the kscreenlocker background in the vertical-left Plasma panel area (second screenshot). Then I started kwin_x11, parts of the screen flickered. Killing and restarting kwin makes everything work again. 

> So either the screenlocker are artifacts in the framebuffer or the konsole window managed to raise above the screenlocker.

I think it where the artifacts, and that the locker was working but kwin did not work correctly. So the screen unlocked after entering the password, but kwin didn't update the screen content.

But there is something else, today after starting the computer from suspend, the first thing I was was my desktop wallpaper, the it changed rapidly to the locker screen with its own wallpaper image.
I can observe such behavior very often.

> try to invoke the greeter directly instead of locking the screen:

It does work, but I will continue doing this and Ctrl+Alt+L and letting the screen lock automatically to see what happens.
Comment 27 G360 2016-03-08 02:41:22 UTC
It seems that there are no "OpenGL interface" options (the combobox is empty), when kwin is not running. Bug or feature?
Comment 28 Jan-Marek Glogowski 2016-03-08 10:41:57 UTC
I've just updated from Kubuntu 14.04 to 16.04.

Just wanted to add a "me too". There is a slight difference for my case: I can still switch to the tty, kill the greeter (SIGKILL) and the restarted instance is responsible for input and I can unlock my session. Still an annoyance.
Comment 29 Jan-Marek Glogowski 2016-03-08 10:43:20 UTC
Created attachment 97761 [details]
jmux KWin support info
Comment 30 Thomas Lübking 2016-03-08 10:52:45 UTC
(In reply to Jan-Marek Glogowski from comment #28)
> kill the greeter (SIGKILL) and the restarted
> instance is responsible for input and I can unlock my session. Still an

You may safely assume that this is a bug in the greeter or its foundation (greeter dysfunctional -> killing. restarted greeter works)
Common pattern is Gallium/AMD, can you try EGL compositing?
Comment 31 Thomas Lübking 2016-03-08 11:01:48 UTC
(In reply to Götz from comment #26)

> This is also strange. The combobox was empty while OpenGL 2.0 or 3 where
> selected. Now I see the options (now sure what changed) and I have selected
> EGL.

It queries KWin for some basic information (notably the compiled in backends) - feature, not bug.
 
> But now, after using kwin_x11 with compton, then selecting EGL and applying
That should have zero or bad impact - you cannot use two compositors at once and I've no idea how compton reacts if you try to claim the compositor selection (resp. whether it claims it)
Just don't do that.

> I will try to be more descriptive:
> A timeout has passed and the screen locked. The locker was frozen or it was

Can you try to kill just kscreenlocker_greet instead? (see jmux's input)
FYI, the cursor is drawn directly into the scanout buffer by the HW, it's different from everything else by nature.

> I think it where the artifacts, and that the locker was working but kwin did
> not work correctly. So the screen unlocked after entering the password, but
> kwin didn't update the screen content.

In such case, suspending the compositor (SHIFT+Alt+F12) *after* the assumed unlock should present you the uncomposited, but correct desktop.
 
> But there is something else, today after starting the computer from suspend,
Is this btw. part of the broken process? At least the nvidia blob is known to cause trouble when transferring VBOs between GPU and system RAM (between ugly artifacts and segfaults) - and this would likely affect both, kwin *and* the screenlocker (the brief wallpaper might point towards this - you should still only see a black window when the greeter crash-restarts, but the driver might expose an older frame instead)
Comment 32 G360 2016-03-12 17:26:17 UTC
Using EGL, there same issue(s) continue.

> Can you try to kill just kscreenlocker_greet instead? (see jmux's input)

Yes, the newly restarted kscreenlocker_greet works fine, and after unlocking it, plasmashell is unresponsive. Is it also unresponsive for you Jan-Marek? 
After killing plasmashell, the panel is still shown (there is no longer a plasma process). Restarting kwin_x11 solves this.
 
For me, at the beginning (December), switching to a TTY and back was sufficient to make kscreenlocker_greet work, but since February (see comment #13) it was not sufficient and had to kill kscreenlocker_greet.

> In such case, suspending the compositor (SHIFT+Alt+F12) *after* the assumed unlock should present you the uncomposited, but correct desktop.

I 'll try this on the next opportunity.

> Is this btw. part of the broken process?
I have not seen a correlation between the greeter not responding and the artifacts.
Comment 33 G360 2016-03-13 00:09:27 UTC
I forgot to add, that before restarting the greeter, I used a shortcut to change the Keyboard Layout, and after the greeter restarted, the layout was changed.
Comment 34 Jan-Marek Glogowski 2016-03-14 10:28:27 UTC
(In reply to Götz from comment #32)
> Using EGL, there same issue(s) continue.
> 
> > Can you try to kill just kscreenlocker_greet instead? (see jmux's input)
> 
> Yes, the newly restarted kscreenlocker_greet works fine, and after unlocking
> it, plasmashell is unresponsive. Is it also unresponsive for you Jan-Marek? 
> After killing plasmashell, the panel is still shown (there is no longer a
> plasma process). Restarting kwin_x11 solves this.

For me everything is responsive again, after killing the greeter and unlocking it. Otherwise I would run an other kind of session.

I'm still don't know the origin of the deadlock. I thought it was related to DPMS, but locking the screen and running "sleep 10 && xset dpms force off" in the background doesn't trigger the greeter lockup.
I just know it doesn't always lockup the greeter, but ever after longer inactivity.

(In reply to Thomas Lübking from comment #30)
> You may safely assume that this is a bug in the greeter or its foundation
> (greeter dysfunctional -> killing. restarted greeter works)
> Common pattern is Gallium/AMD, can you try EGL compositing?

If I switch to EGL, compositing is disabled (according to to the qdbus output). Doesn't matter if I select OpenGL 2.0 or 3.1. The stripped output from es2_info (minus stripped extensions) says: 1.5 - not sure if this EGL version is related to the selected OpenGL version:

EGL_VERSION: 1.5 (DRI2)
EGL_VENDOR: Mesa Project
EGL_CLIENT_APIS: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3
GL_VERSION: OpenGL ES 3.0 Mesa 11.1.2
GL_RENDERER: Gallium 0.4 on AMD RV710 (DRM 2.43.0, LLVM 3.8.0)

BTW: my HW is old - a [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]
Comment 35 Jan-Marek Glogowski 2016-03-14 10:30:39 UTC
Created attachment 97888 [details]
jmux full es2_info output
Comment 36 PhillB 2016-03-15 21:43:23 UTC
I think this is the same as my issue (360396) which I thought was resolved.

However it "came back" intermittently as noted here.

For me usually killing the kscreenlocker_greeter fixes things and I can flick back and type in the password.

Once, however, I did that and it unlocked but both screens stayed black. I could see the mouse pointer whizzing around on the screens though.

My hardware is totally different (onboard graphics dual screen VGA+HDMI).
Comment 37 G360 2016-03-27 19:12:10 UTC
This is strange, since a week or two, using KWin with OpenGL 2.0 and XGL composition, when the locker becomes unresponsive, just switching to a TTY and back (without killing any process) makes the locker become responsive again.
Comment 38 Diego 2016-04-01 12:42:50 UTC
Is checking "Suspend compositor for full screen windows" supposed to disable compositing for kscreenlock? I expect the answer to be "yes". Thanks.
Comment 39 Martin Flöser 2016-04-01 13:47:53 UTC
(In reply to Diego from comment #38)
> Is checking "Suspend compositor for full screen windows" supposed to disable
> compositing for kscreenlock? I expect the answer to be "yes". Thanks.

maybe. The feature only works on non-intel and for unmanaged windows it's difficult to say whether it will trigger unredirection.
Comment 40 Thomas Lübking 2016-04-01 15:00:44 UTC
Moreover fullscreen unredirection is no way the same as suspending the compositor (the former still bears an active GL context), so the interesting question is whether that setting makes any difference for you?
Comment 41 Diego 2016-04-01 16:14:43 UTC
(In reply to Thomas Lübking from comment #40)
> Moreover fullscreen unredirection is no way the same as suspending the
> compositor (the former still bears an active GL context), so the interesting
> question is whether that setting makes any difference for you?

I would have gladly tested that, but I'm on Intel hw, so if Martin's comment applies nothing should change. I'll test that anyhow.
Comment 42 PhillB 2016-04-02 22:49:16 UTC
Just a quick note: I noticed a couple of weeks ago (and meant to add it here) that when the screenlocker becomes unresponsive to KB/Mouse the shift key still works. That is to say the bold notice, indicating the shift key is active, appears when you press the shift key and goes away when you release it.

However, that probably doesn't help I suspect.

P
Comment 43 Thomas Lübking 2016-04-03 10:52:56 UTC
(In reply to PhillB from comment #42)
> That is to say the bold notice, indicating the shift key is
> active, appears when you press the shift key and goes away when you release

Means this bug is (likely) not your problem. At least it's not a problem with the compositor for sure (nothing would update by such freeze)
Also bug #360396 wasn't resolved "fixed", but only tagged "downstream".
Comment 44 G360 2016-05-07 03:41:18 UTC
Today I found something interesting. First the screenlocker was frozen, then I changed the brightness with the corresponding hotkey and the screenlocker unfroze, the cursor was blinking and I could write the password and unlock the screen.

Another thing, sometimes, when waking from suspend, shows a black screen, as if the display backlight was very dimmed. Changing brightness makes the display functional.
Comment 45 Martin Flöser 2016-08-29 09:52:57 UTC
I would like to see a backtrace of a hung kscreenlocker. Best would be through ssh as it might be that switching to the tty already does the unfreeze.
Comment 46 G360 2016-08-29 18:13:29 UTC
It seems to be a kernel driver bug or such, as linux 4.6 has resolved this. Testing with linux 4.4 brings the issue back. I'll mark this as resolved.