Bug 357007

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

Just tried using KWin with compton as compositor and the same problem.

is this also happening without any compositor? E.g. using KWin, but have compositing disabled?

This does mit happen without compositor.

I mean, it does not happen.

what about using XRender?

With XRender the lockscreen seems to be responsive every time.

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?

Created attachment 96602 [details]
glxinfo

It does not freeze always, but sometimes, using the OpenGL compositor.

Looks like quite good hardware/driver combo. I'm starting more and more to become clueless on what's the problem here. Sorry :-(

If you don't know what the problem is, then I am out of luck, hehe!

Anyway thank you for your time.

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.

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.

I can confirm that kscreenlocker_greet works without problems using Caledonia as Plasma theme. The problem occurs using Breeze.

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.

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.

What is
> react strange to keyboard or mouse input
?

PS, please attach the output of "qdbus org.kde.KWin /KWin supportInformation"

Created attachment 97728 [details]
"qdbus org.kde.KWin /KWin supportInformation"

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.

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.

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.

- 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.

> - 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 #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 #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.

It seems that there are no "OpenGL interface" options (the combobox is empty), when kwin is not running. Bug or feature?

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.

Created attachment 97761 [details]
jmux KWin support info

(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?

(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)

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.

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.

(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]

Created attachment 97888 [details]
jmux full es2_info output

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).

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.

Is checking "Suspend compositor for full screen windows" supposed to disable compositing for kscreenlock? I expect the answer to be "yes". Thanks.

(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.

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?

(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.

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

(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".

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.

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.

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.