Waking from suspend freezes my KDE session each time. This is a regression since i did not have this issue before. (Though not sure what update) 1, Trying to invoke suspend from terminal with: sudo pm-suspend, Result: Works and wakeup goes without any issues. 1, Trying to invoke suspend from application launcher OR hotkey (FN + Sleep) on the keyboard. Result: Freeze, only mouse movements works. KDE does not respond to any keyboard or mouse triggers. One way to get a working session again is by switching tty [CTRL+ALT+F1] and restarting KDE session. (sudo systemctl restart kdm) I installed Gnome3 and noticed that suspend works without any issues from ALL of the above methods. Laptop in question is UX32VD (latest BIOS) Reproducible: Always Steps to Reproduce: 1. Enter KDE 2. Try suspend Actual Results: Wakeup gives a frozen KDE session Expected Results: Working KDE session UX32VD latest BIOS Linux : 3.10.9 Up to date Arch install.
Created attachment 82026 [details] lspci -k lspci -k output
This issue is still happening for me but I want to clarify something here. For me KDE does NOT freeze only no inputs are registered. By that i mean, kwin will not respond to keyboard or mouse press. But mouse will freely move around KDE and KDE will also continue to work like nothing happen. dmesg, or pm logs wont show any errors.....
Moved to kwin since its about input not working, seems more specific to me but not sure if this is right or not since I have no idea how to even start looking. Tried dmesg, pm-suspend, xorg.0.log and journalctl but cannot find anything specific about this.
Could you please specify the behavior in more detail. Are no input events delivered to any application or just not to KWin?
Since it depends on the invocation to STR i wonder whether the screenlocker is invoked and keeps the input grabbed (it does in gereal sounds as if the input is grabbed by some client) To rule out kwin: does restarting only kwin from VT1 export DISPLAY=:0 kwin --replace & get you the input back?
PS, you know about "Ctrl+Alt+Keypad-Multiply Not treated specially by default. If the AllowClosedownGrabs xorg.conf(5x) file option is specified, this key sequence kills clients with an active keyboard or mouse grab as well as killing any application that may have locked the server, normally using the XGrabServer(3x) Xlib function. Ctrl+Alt+Keypad-Divide Not treated specially by default. If the AllowDeactivateGrabs xorg.conf(5x) file option is specified, this key sequence deactivates any active keyboard and mouse grabs." Be "warned": if the screenlocker holds the grab, killing it will kill ksmserver, what quits the running session.
(In reply to comment #4) > Could you please specify the behavior in more detail. Are no input events > delivered to any application or just not to KWin? After invoking sleep I open the laptop lid to resume the computer It goes to the desktop (got no lock screen enabled for sleep). The plasma-desktop and rest are loaded and nm-manager reconnects to my wifi and everything starts working as usual, i can move my mouse around etc. _However_ when i hover over items, or try to click on them nothing will react to it. There is no mouse-over reaction anymore and nm-manager (applet) for example wont react to my left or right clicks with the mouse. It's like Thomas Lübking said that i can only move my mouse around but clicks are ether grabbed somewhere else or does not register for some reason. Same goes for keyboard, pressing the hotkey Alt + F2 to get krunner nothing happens. Trying to switch virtual desktops does not invoke also. All in all, i can see my desktop running as usual but cannot interact with it. And can only switch VT (TTY's) and in my example run "systemctl restart kdm" to re-login and continue my work. Running pm-suspend from terminal does not have this issue. Tried just for the sake of it Gnome desktop since its easy to install in Arch. And well after resume i'm only presented with their login-screen but input works and noting unusual happens no matter how I invoke sleep. Hope this clarifies my issue Martin. If not i can try to record this and put it up on youtube or something. (In reply to comment #5) > Since it depends on the invocation to STR i wonder whether the screenlocker > is invoked and keeps the input grabbed (it does in gereal sounds as if the > input is grabbed by some client) > > To rule out kwin: does restarting only kwin from VT1 > export DISPLAY=:0 > kwin --replace & > get you the input back? I did resume and then opened VT1 (TTY1) and then typed the export and replace. Then i got some output and switched back to VT7 (TTY7) and nothing changed. Output of the replace: http://i.imgur.com/e0Rs3Uy.jpeg (In reply to comment #6) > PS, you know about > > "Ctrl+Alt+Keypad-Multiply > Not treated specially by default. If the AllowClosedownGrabs xorg.conf(5x) > file option is specified, this key sequence kills clients with an active > keyboard or mouse grab as well as killing any application that may have > locked the server, normally using the XGrabServer(3x) Xlib function. > Ctrl+Alt+Keypad-Divide > Not treated specially by default. If the AllowDeactivateGrabs xorg.conf(5x) > file option is specified, this key sequence deactivates any active keyboard > and mouse grabs." > > Be "warned": if the screenlocker holds the grab, killing it will kill > ksmserver, what quits the running session. So about this im not sure. I did a 20-serveflags.conf in /etc/X11/xorg.conf.d with Section "ServerFlags" Option "AllowDeactivateGrabs" "true" Option "AllowClosedownGrabs" "true" EndSection Taken from : http://www.x.org/archive/X11R6.8.0/doc/xorg.conf.5.html and https://wiki.gentoo.org/wiki/Xorg.conf#ServerFlags I'm on a laptop so no keypad and with Swedish keyboard layout so * and / are exposed with shift. But when running resume and I land on the KDE desktop and then trying both nothing happens. Ctrl+Alt+Shift+/ or * Again, thanks to you both for taking your time with this issue. Best Regards Artur O.
from vt1, export DISPLAY=:0 and then "xprop", if the mouse is grabbed, the last command will tell you so (error message like "could not grab the mouse") unfortunately there's no direct way to know which client holds a grab, but it's apparently not kwin. can you try attaching external input devs (real kbd and mouse)? - after the issue occurs, i mean. may also allow you to release/kill the grab.
(In reply to comment #8) > from vt1, export DISPLAY=:0 and then "xprop", if the mouse is grabbed, the > last command will tell you so (error message like "could not grab the mouse") > > unfortunately there's no direct way to know which client holds a grab, but > it's apparently not kwin. > > can you try attaching external input devs (real kbd and mouse)? - after the > issue occurs, i mean. > may also allow you to release/kill the grab. Yeah when entering xprop after the export i get "Can't grab the mouse" I connected a external keyboard (Logitech G15) and mouse to my USB ports, they react the same way as the internal ones. Trying the / * combo did nothing. Success! After poking around i went to (System Settings -> Power mgm -> Advanced) and then toggled on/off the "Lock screen on resume". After that it did not grab the mouse. So its the screen locker that grabs the mouse but does not work correctly. So I went to the (System Settings -> Display and Monitor -> Screen Locker) and I have the "Desktop Widgets" enabled if my computer goes idle for 5 minutes. I pressed Configure and well it works there, but after invoking it manually from menu it does not present itself and behaves as before and grabs mouse. Then I switched to "Simple locker" and it works correctly both when invoking it from the menu and when entering sleep. So the question is why is the "Desktop Widgets" bugging out. But again it's not a Kwin issue but Screen Locker issue?. Again thanks for the fast response Best Regards Artur O.
It's likely bug #316797 Can you check whether a "plasma-overlay" process is running when the problem occurs?
(In reply to comment #10) > It's likely bug #316797 > Can you check whether a "plasma-overlay" process is running when the problem > occurs? It does, killing it just spawns a new one.
Okey. Similar to bug #316797, but is apparently not the same.
(In reply to comment #12) > Okey. Similar to bug #316797, but is apparently not the same. Should I do anything more considering this? More information etc or just leave this bug for now?
I'm seeing exactly the same symptoms with kdelibs 4.14.8 and kscreensaver 4.11.19 (which are the latest stable versions in Gentoo). My kernel version is 4.0.5. I've gone through all the tests outlined above (except the ones with the numpad keys because I don't have a keyboard with a numpad available) and the behavior is as described; in particular, there is a plasma-overlay process running, so it seems that #316797 isn't applicable to me. Any troubleshooting steps I can try to collect more useful info?
I get a blank screen randomly during wakeups, no plasma-overlay running. I can move the mouse around and running xprops from a VT (and then clicking on something on X), gives me the information about X windows that are currently running, but not visible. The above solution to run on a VT worked for me to make my windows visible again: DISPLAY=:0 kwin_x11 --replace & System info: Linux manjaro 3.18.35-1-MANJARO SMP PREEMPT x86_64 My KDE is kdebase-16.04.2-1 Thinkpad T440p
Sorry for second post, but I should add that I think this only happens when the computer goes to sleep when the lid is OPEN. I encountered it twice, but it's no proof.
Hello. I seem to have similar issues. opensuse leap42.1 kde plasma 5 & kde4 its the launcher panel that becomes unresponsive the mouse / keyboard + running apps still work and react. hovering over the launcher or clicking on it has zero response. It usually happens when coming out of suspend ( suspended by having closed the lid or just suspended after the time configured (5 min in my case)) I do not have a screen lock, but do use the manual screen lock when at work (ctrl+alt+L ) I tried kdm instead of ssdm, but made no difference. I tried kde instead of kdeplasma to start with, made no difference. I tried different kernels, made no difference. hardware : core i7, 5xxx generation, 8 GB RAM, 256 GB ssd asus ux301L zenbook 13" let me know if I can do/test something. I havent seen this behaviour before updating to kde5 (plasma etc)
Today launcher froze up again. I had manually locked the screen with ctrl+alt+L Suspend did not activate, since the laptop was on power. hovering over, clicking on it had no result. I opened a console with ctrl+alt+F1 I started kwin_x11 --replace went back to desktop with ctrl+alt+F8 I noticed that one window had lost it's window manager frame: as if there was no kwin_x11 running and managing it. From an open konsole, I started xkill and killed the unmanaged window. This resulted in a restart of the launcher, and everything is working as normal again. btw, the app in the window was Dolphin. apparently: - suspend apparently has nothing to do with it. - I am not sure if I could have done this without the kwin_x11 --replace. I will check next time :-) - kwin_x11 gets stuck on a window that grabs the mouse/keyboard for unknown reasons. I didnt plug or unplug any devices or whatever (Dolphin is sensitive to that, e.g. with failing nfs mounts after resuming from suspend etc )
I want to add to rens's report that I also realized that this happens when there is a problem with NSF mounts. I will always get a black screen if I forgot to unmount my network mounts before a suspend - especially when I move the laptop to an external network segment where the NSF mount is no longer available. So it sounds like we're waiting for the network devices to come back or timeout. At this point, just being patient for a few minutes and randomly pressing buttons on the keyboard eventually brings back the lock screen as if nothing happened. So I usually can survive without restarting kwin.
Hello, It seems to be plasmashell, which is hanging / blocked / looses track of input from pointing device and keyboard Workaround: the way to restart is (for me) alt - spacebar, so I can do killall plasmashell and then plasmashell after which everything is working again. which at least saves me from loosing work, concept emails and the works. hope this helps. Rens
actually, I start a Konsole, and then do killall plasmashell plasmashell
in addition : I changed the settings for powersaving: I disallow turning the display off. (it dims, but is not turned off, kde powermgmt for both on AC, battery, low battery ) since then ( 4 days) , I havent had the issue it used to happens once or twice a day minimum. apparently restoring focus to the proper window gets lost ( and it is fatal when the screenlocker does not get the focus back from X because then you cannot orderly shutdown your open apps...... ) hope this helps
Hello! This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug has already been resolved in Plasma 5. Accordingly, we hope you understand why we must close this bug report. If the issue described here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham