This happens after I unlock my screen, either after the screen was locked manually or automatically, or after resuming from a suspended state ('sleep') of my laptop. The unlock dialog shows up and works normally, but after giving the correct password to unlock, the screen goes black. Usually, this lasts 5-10 seconds, and all is well. Every now and then the screen remains black after several minutes, in which case I haven't found a good solution yet. Changing to a text console and back doesn't help. While the screen is black, I can see and move the mouse pointer, which will change from arrow to cursor or 'hand' when moved over text or something clickabe in the invisible window below. Also, when I move my mouse to the "active" corner of my screen, the action of presenting my four desktops side-by-side is indeed triggered. However, this happens nearly invisibly: the active corner starts to glow and I see the four *titles* of my desktop appearing side-by-side. The desktops themselves are invisible. Restarting KDE (and X) from a text console provides me with a fresh instance of KDE without problems, but oviously also without whatever which windows were open. A 'rescue' solution is to kill kwin (# kill -1 kwin) from a text console. This solves the black screen so that I can see my open windows when switching back to X, but also removes my task bar, clutters most or all windows onto one desktop and makes actual work impossible. It does however give me the possibility to close all windows myself, save data where necessary, etc., before I restart KDE/X. I have just found that the command "DISPLAY=:0 kwin --replace" from the text console, followed by the command "kwin --replace" from within X may provide a better solution here, but I haven't been able to try that yet. Recently (just now) I have noticed that the kwin process starts using 100% cpu when locking the screen manually, or when switching to a text console (using e.g. Ctrl-Alt-F1). Reproducible: Sometimes Steps to Reproduce: 1. Lock screen, wait for screen saver to kick in or suspend system to RAM and unsuspend it again 2. Type password in unlock dialog (which shows up normally, with (default?) blueish background) Actual Results: The screen goes black, only the mouse pointer is visible. In most cases, the desktop/windows reappear after 5-10 seconds. Every now and then, they do not, and I need to restart kwin/KDE/X manually Expected Results: Desktop and windows are shown within a second of unlocking the screen. Graphics card: NVIDIA GT218M [NVS 3100M] (rev a2) Graphics driver: NVIDIA X11 driver and GLX libraries v319.76 OS: Gentoo Linux X: xorg-server v1.14.3 Kwin version: 4.11.2 (not 4.11.3; that was the closest version available in the list) Composing type: OpenGL 1.2 QT graphics system: Native Tearing prevention (QSync): Automatic Desktop effects: enabled Screen saver: black screen
Created attachment 84814 [details] Xorg system log
Created attachment 84815 [details] Output of glxinfo
a) press "Alt+Shift+F12" to toggle the compositor off/on when this happens b) try whether you can reproduce this with "full repaint" or "none" tearing prevention c) you're not using a framebuffer console, are you? ("dmesg | grep NVRM" - should print a warning in case)
Thanks for picking this up. a) This does nothing for the ~10s black screens. I also noticed that the 'active corners' don't do anything during the 10s events. I haven't been able to try this for the 'indefinite' black screens. b) I get the same result for: Desktop effects: enabled, disabled; Composing type: 1.2, 3.1 or XRender; QT graphics system: Native, Raster; Tearing prevention: Auto, Full scene repaints, none c) AFAIK not; I'm not using graphics on the console. # dmesg | grep NVRM gives: [ 7.116759] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 319.76 <date> When I woke up my laptop today, the screen consisted of triangles made up of bits of window and background like a jigsaw (after the 10s darkness). $ kwin --replace fixed this. I'm not sure it's related.
The "short" black screen delay is not related to kwin/compositing but may be the cause to the casual permanent black/distorted screen. In the latter case, toggling compositing twice should "fix" it. Only the permanent error is relevant regarding the other tests (and try tearing prevention at preference) The common reason is likely corrupted VRAM, check whether your BIOS/UEFI allows to repost vieo memory after STR, though a common reason would be the framebuffer console... Last resort might be to pass NVreg_EnableMSI=0 as parameter to the nvidia kernel module, eg. add /etc/modprobe.d/nvidia.conf options nvidia NVreg_EnableMSI=0 If that doesn't help, remove that entry again (see /usr/share/doc/nvidia/README on the topic)
I have the same problem. Whenver my PC goes to suspend mode, Kwin hangs with 100% CPU usage (and black scren) after I resume. The workarround is killing kwin and restarting it again.
Don't know, whether this helps: glehnhoff@HP8540:/media/Daten/daten/glehnhoff/data_strong$ kwin QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro FX 880M/PCIe/SSE2 OpenGL version string: 3.3.0 NVIDIA 304.88 OpenGL shading language version string: 3.30 NVIDIA via Cg compiler Driver: NVIDIA Driver version: 304.88 GPU class: Unknown OpenGL version: 3.3 GLSL version: 3.30 X server version: 1.14.5 Linux kernel version: 3.11 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no kwin(17876) KWin::GlxBackend::present: It seems you are using the nvidia driver without triple buffering You must export __GL_YIELD="USLEEP" to prevent large CPU overhead on synced swaps Preferably, enable the TripleBuffer Option in the xorg.conf Device For this reason, the tearing prevention has been disabled. See https://bugs.kde.org/show_bug.cgi?id=322060
Pattern is "Nvidia Quadro" - weird thing is the claim that this even happens with suspended compositing (Shift+Alt+F12 before suspending) Could be due to some screen reconfiguration. You could "kdebugdialog --fullmode" and redirect all "kwin (1212)" output into some file (/tmp/kwin.dbg) Then check whether the wakeup from STR adds some "screens: <#> desktops: <#>" line
Hi Thomas, this is fine with me, but as I am not a Linux guru, please show exactly the commands I have to enter, if you want me to do that. Weird is, that this morning KDE awoke without any problem. I have no idea, why. When the problem happens, Kwin consumption is 100% of the CPU. Beside that I have the same effects as written somewhere else in this bug report. Cheers, gl
kdebugdialog is a guitool. just run "kdebugdialog --fullmode" from konsole or krunner (alt+f2), filter for "kwin", select the "1212" entry, and on the right side "file" for every level and pass /tmp/kwin.dbg into the input field below. apply/ok next, cause the problem and then upload /tmp/kwin.dbg here (if you intend to delay the upload a bit, please first copy the file somewhere else, so that its end matches the problem situation.) you can then disable logging in "kdebugdialog" again.
Thomas, the error/crash did not come up the last couple of days. The only idea I have why is, that it has been solved with one of my Kubuntu updates. Cheers, gl
Created attachment 85132 [details] kwin.dbg OK, here we are. It happened again. Attached is the debug file. Unfortunately I do not know whether kdebugdialog still was running :-(
"kdebugdialog" does not have to be running, but the debug output needs to be still redirected. The log ends near showing/activating kdebugdialog, so I assume you've stopped logging at some point? (It would be still active otherwise) Fwiwi: there's no unusual clientArea update logged.
Hi Thomas, I do my best but seem to fail. I start kdebugdialog --fullmode, do in the GUI all what you have written, press "Anwenden" (apply) and "OK". The GUI closes. Then I look for a process kdebugdialog and kind find one, nor there is a file created. glehnhoff@HP8540:~$ kdebugdialog --fullmode QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. glehnhoff@HP8540:~$ ps -C kdebugdialog PID TTY TIME CMD glehnhoff@HP8540:~$ Question: - You see, there are some warnings. Do I have a problem with kdebugdialog? - Or do I have to start it with "sudo"? - Or is the file created only, if the problem occurs? As KDE crashed this morning again after "resume" - funny, that I have the feeling it crashes only via overnight - I have to kill kwin in screen 1 and I have to restart it with "DISPLAY=:0 kwin --replace". I looked for a debug-file, there is no. I started kdebugdialog again, as written above, there is still no file, and no process. Cheers, gl
Created attachment 85198 [details] kwin.dbg I got it. After the crash I found the file. See attached. This time, the system has not been in suspend mode. I only switched to screen 2, the kwin process started consuming 100% of CPU, I switched back to screen 7 and got the funny screen. I killed kwin and started it again, which works.
Thanks for your efforts and sorry for the delay, but "unfortunately" that's not the reason. It though may worth trying to export __GL_YIELD="USLEEP" kwin --replace & (The nvidia blob performs a busy wait for the retrace on swapping, what could be funny if it waits for a swap while you move to VT1) Beyond that, only callgrind (valgrind tool) could tell us more - eventually gdb'ing into kwin from VT1 might give a hint. @AstroFloyd Since Gerhard is "not a Linux guru", could you try either? Do you happen to export __GL_YIELD="USLEEP" anyway?
By now we no longer maintain the 4.x branch of KWin. The architecture overall changed a lot - especially in the are of the lock screen. It is to a certain degree unlikely that this bug is still valid for our 5.x series. If you still experience this or a similar bug in 5.x I kindly ask you to report a new bug about this to have all information about the current software version around. Thank you for reporting this bug and help making KDE software better.