When the desktop logout effect is enabled, if I try to shutdown/restart/log out, the window with the countdown opens and show up correctly, but the background is corrupted with random stuff such as windows/menus that were opened before, or even currently opened windows but totally reversed and/or at different places. Unfortunately, it doesn't look like I can take a screenshot while that screen is open. This only happens with the nouveau driver with OpenGL compositing. It works fine with XRender, or if I use the proprietary nvidia driver with OpenGL. It has been reported in nouveau bug tracker as well: https://bugs.freedesktop.org/show_bug.cgi?id=74316 I was told by a nouveau developer that it would need help from KDE devs to debug the issue. Martin told me to report it here. Reproducible: Always
could be bug #330307 - do you have a camera/smartphone to take a "screenshot"?
Isn't https://bugs.kde.org/show_bug.cgi?id=330307 fixed by latest update? Yes, I can take a photo, I'll only be able to access that computer next Friday though.
Yes, missed the "4.11.6" in this report - sorry. You can also try kwriteconfig --file kwinrc --group Effect-Logout --key UseBlur false (then restart the compositor, "Shift+Alt+F12" twice)
Indeed, that does fix it :) Anything else I should do to help fix the issue?
run kwin from konsole and redirect all output into some file, resp. inspec the dmesg output for error messages from MESA regarding the shader. You can also export various MESA environments, notably MESA_DEBUG and MESA_GLSL, see http://www.mesa3d.org/envvars.html Nouveau will also require to compare with the SW rendering: export LIBGL_ALWAYS_SOFTWARE=1 kwin --replace & # this is gonna be rather slow In any case, please attach the output of "qdbus org.kde.kwin /KWin supportInformation" and/or "glxinfo" (for precise information about the renderer and render path)
Created attachment 85150 [details] glxinfo
kwin just crashes, it restarts and then desktop effects don't work if I use LIBGL_ALWAYS_SOFTWARE=1. Anyway when I reproduce the issue, this floods my terminal: kwin(1019) KWin::checkGLError: GL error ( Render blur texture ): "GL_INVALID_OPERATION" $ qdbus org.kde.kwin /KWin supportInformation qdbus: could not exec '/usr/lib/qt/bin/qdbus': No such file or directory (doesn't seem to work on my system for some reason)
try "qdbus-qt4"
Created attachment 85151 [details] kwin supportinformation It works with qdbus-qt4.
> glCoreProfile: true Same issue when choosing "OpenGL 2" in the third tab of "kcmshell4 kwincompositing"?
Indeed, the issue is the same. With OpenGL 1.2, it's worse, almost all of the background turns black when I try to logout, and it shows a different error: kwin(811) KWin::checkGLError: GL error ( PostPaint ): "GL_INVALID_OPERATION"
Here's the error from mesa with MESA_DEBUG=1 and LIBGL_DEBUG=1: Mesa: User error: GL_INVALID_OPERATION in glBlitFramebufferEXT(bad src/dst multisample pixel formats)
Looks like the same issue was previously reported here: https://bugs.kde.org/show_bug.cgi?id=309510
@Martin,Fredrik I don't see particular entries for GLX_SAMPLE_BUFFERS / GLX_SAMPLES in the attribs list for glXChooseFBConfig, nor search introduced by http://commits.kde.org/kde-workspace/6cf057777555a5d0c834de3a0165a62916cf3b40, fixing bug #308385 -> No longer required? Or are we evtl. selecting MSAA drawables again? In addition there seems no 32 depth GLXFBConfigs in the provided glxinfo @AnAkkk Are you using kwin on GLX? (or kwin_gles, resp. selected the EGL like export KWIN_OPENGL_INTERFACE=egl )? "kdebugdialog" - enable 1212 (kwin) and see whether there's an error message like "Could not find a framebuffer configuration for depth 32." resp. post the output part that starts with: "Drawable visual (depth "
I'm using GLX. I just tried with EGL, and I didn't have the issue. 1212 (kwin) was already enabled. I don't have the error you mentionned. kwin(16011) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing kwin(16011) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 24 ): 0x "153" kwin(16011) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 32 ): 0x "73" kwin(16011) KWin::GlxBackend::initBuffer: Buffer visual (depth 24 ): 0x "168"
(In reply to comment #15) > kwin(16011) KWin::GlxBackend::initBuffer: Buffer visual (depth 24 ): 0x > "168" 0x168 24 tc 0 24 0 r y . 8 8 8 0 . . 0 0 0 0 0 0 0 2 1 None ^^^^ Should be 0x157 (no sample buffers) Can you compile and try a patch?
Sure, I can try.
Created attachment 85153 [details] select minimum samples Patch attached, should cleanly apply on 4.11.6
Well that patch just cause kwin to freeze up, I can see the mouse moving but everything else is stuck. Launching kwin --replace & in a terminal just keep showing: KWin::checkGLError: GL error ( PostPaint ): "GL_INVALID_OPERATION"
MESA_DEBUG shows: GL_INVALID_OPERATION in glCopyTexSubImage2D(missing readbuffer, format=0x1908)
Created attachment 85154 [details] fixed "select minimum samples" F*** - cnp bug, the iterator is "j" in the second loop. Sorry.
Same issue as with the previous patch.
What's the corresponding debug output (as provided in comment #15)? No debug out like "Could not find a framebuffer configuration" or "Failed to find a usable framebuffer configuration"?
Well, when I launch kwin from a VT there seem to be a lot less debug output, there aren't any messages starting by KWin::Compositor or KWin::GlxBackend.
forgot to "export DISPLAY=:0"? In doubt you can kwin > kwin.dbg 2>&1 from konsole and check kwin.dbg afterwards.
Created attachment 85156 [details] kwin.dbg I can't really do that from konsole as the screen is totally stuck/unusable.
Created attachment 85157 [details] One more "select minimum samples" odd - glCopyTexSubImage2D seems to be only called in the lanczos filter and the blur effect, but the debug output does not suggest that the compositor was started at all. you could gdb into kwin and check whether it hangs in some function which initialising OpenGL. Attached one more variant of the patch (the second config query contained a break, ie. was actually not searching for the minimum samples)
Still the same. The first time I do a kwin --replace & from a VT, there are actually a few X errors: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 20 (X_GetProperty) Resource id: 0x180001d (shows up twice) gdb back trace: #0 0x00007f6934c58fd3 in select () from /usr/lib/libc.so.6 #1 0x00007f692efec49b in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval const*) () from /usr/lib/libQtCore.so.4 #2 0x00007f692eff1ac4 in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timeval*) () from /usr/lib/libQtCore.so.4 #3 0x00007f692eff1f12 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #4 0x00007f692e1e6b36 in ?? () from /usr/lib/libQtGui.so.4 #5 0x00007f692efc0b1f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #6 0x00007f692efc0e15 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #7 0x00007f692efc5f4b in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #8 0x00007f6934f9d7d6 in kdemain () from /usr/lib/libkdeinit4_kwin.so #9 0x00007f6934b9bb05 in __libc_start_main () from /usr/lib/libc.so.6 #10 0x00000000004006fe in _start ()
That was thread #1. Thread #2 waits on a select() call from libQtCore.so.4. Thread #3 called QProcess::execute which called QProcess::waitForFinished from libkdeinit4_kwin.so, so I guess it's still waiting for whatever process it executed.
Well now for some reason kwin works, I haven't changed anything...Desktop effects don't seem to work though, and I can't enable them with Shift+ALT+F12. This error shows up: kwin(1155): Compositing is not possible
kwin still get stuck from time to time, it seems pretty random. BTW, is the corruption not happening with GL ES because the blur effect isn't available? (I've read about that somewhere, it's pretty old though)
This time it got stuck again, but the messages you wanted showed up anyway: KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 24 ): 0x "137" KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 32 ): 0x "73" KWin::GlxBackend::initBuffer: Buffer visual (depth 24 ): 0x "73" And I keep getting PostPaint GL_INVALID_OPERATION errors when I try to do anything. (what I mean by stuck: the display works, I can move the mouse, but clicking on anything just has no effect at all, it looks like one same frame is displayed all the time, the first one after kwin's start)
(In reply to comment #31) > BTW, is the corruption not happening with GL ES because the blur effect > isn't available? The glsl 1.4 blur effect shader is invalid, yes - not sure at hand whether that also applies to the logout blur shader. (In reply to comment #32) > This time it got stuck again, but the messages you wanted showed up anyway: > > KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 24 ): 0x "137" > KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 32 ): 0x "73" > KWin::GlxBackend::initBuffer: Buffer visual (depth 24 ): 0x "73" Ok, that's certainly not good. The same (32bit) visual (0x073) is used for the drawable and fbo and 0x137 is 0x137 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 16 16 16 16 0 0 Slow What should not be the case since the alpha channel has 8 bits, the caveats is "slow" ... Can you try: - if (samples > minSamples) + if (samples >= minSamples) - if (sampleBuffers > minSampleBuffers) + if (sampleBuffers >= minSampleBuffers) in each occasion of the patch (do you need an updated patch or can you edit the present code in that regard?)
Now: kwin(711) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing kwin(711): Could not find a framebuffer configuration for depth 32. kwin(711) KWin::OpenGLBackend::setFailed: Creating the OpenGL rendering failed: "Could not initialize the drawable configs" QObject::connect: Cannot connect (null)::resetCompositing() to KWin::Compositor::restart() kwin(711): Failed to initialize compositing, compositing disabled kwin(711): Consult http://techbase.kde.org/Projects/KWin/4.0-release-notes#Setting_up
Created attachment 85166 [details] msaa patch GNAGNAGNAIMSTUPIDGNAGNAGNA. Try the latest patch and don't dare to look at it exposing my stupidity.
Now it works, and the corruption seem to be fixed :) kwin(770) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing kwin(770) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 24 ): 0x "153" kwin(770) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 32 ): 0x "73" kwin(770) KWin::GlxBackend::initBuffer: Buffer visual (depth 24 ): 0x "1ae"
Ok Many thanks for your patience =)
Thanks you for fixing it :)
Created attachment 85169 [details] msaa patch, printing visuals Fredrik says, the configs should arrive with min. samples first, so this would be a MESA/nouveau bug. Can you apply the new patch (the one that worked + some debug printout), run it and post the two number rows it prints?
kwin(667) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing ("153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153") kwin(667) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 24 ): 0x "153" kwin(667) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 32 ): 0x "73" ("168", "16b", "169", "16c", "16a", "16d", "1ae", "1b0", "1c1", "1c4", "1c2", "1c5", "1c3", "1c6", "15b", "15d", "171", "174", "172", "175", "173", "176", "1b4", "1b6", "1ca", "1cd", "1cb", "1ce", "1cc", "1cf", "161", "163", "17a", "17d", "17b", "17e", "17c", "17f", "1ba", "1bc", "1d3", "1d6", "1d4", "1d7", "1d5", "1d8", "12c", "182", "184", "194", "197", "195", "198", "196", "199", "130", "132", "188", "18a", "19d", "1a0", "19e", "1a1", "19f", "1a2", "21", "14d", "150", "14e", "14f", "152", "22", "18f", "1a6", "1a9", "1a7", "1aa", "1a8", "1ab", "151", "12a", "157", "13f", "155", "144", "146", "147", "13e", "148", "73", "140", "13b", "13c", "145", "149", "13d") kwin(667) KWin::GlxBackend::initBuffer: Buffer visual (depth 24 ): 0x "1ae"
D'hoo - the 153 collection is the good old copy & paste bug (i->j) again... It's luckily not relevant =) --- Ok, many thanks. It seems to prefer TrueColor over DirectColor (that's expected) over sample count sorting (may be intended), but even then 0x157 should apparently take precedence: 0x153 24 tc 0 24 0 r . . 8 8 8 0 . . 0 0 0 0 0 0 0 0 0 None 0x157 24 tc 0 24 0 r y . 8 8 8 0 . . 0 0 0 0 0 0 0 0 0 None 0x1ae 24 dc 0 24 0 r y . 8 8 8 0 . . 0 0 0 0 0 0 0 0 0 None So given the sample count sorting is still supposed, there's a bug in either nouveau or MESA, it appears the double buffer support is ignored when sorting the list (so that 0x153 and 0x157 are assumed equal, 0x153 moved to front and 0x157 ignored from sorting) - but that's sth. for the MESA devs to say =)
Might be interesting as well: https://git.reviewboard.kde.org/r/115762/
Oops, posted that at the wrong place, sorry.
I reopened my bug report on freedesktop: https://bugs.freedesktop.org/show_bug.cgi?id=74316