This is kind of weird but when I launch kwin --replace, kwin does not immediately start, it hangs until I click a window or something similar. Only output at that point: Could not find drkonqi at /usr/lib/libexec/drkonqi (I don't have that installed) Reproducible: Always
yep, that seems to be a regression in Qt. Very annoying, started a few weeks ago.
Just ssh'ed in from other system to get a backtrace: #0 0x00007f3a3a11ddf3 in select () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f3a3b6271cb in qt_safe_select (nfds=12, fdread=0x1a2d808, fdwrite=0x1a2da98, fdexcept=0x1a2dd28, orig_timeout=0x0) at kernel/qcore_unix.cpp:83 #2 0x00007f3a3b6287f4 in QEventDispatcherUNIX::select (this=0x1a26450, nfds=12, readfds=0x1a2d808, writefds=0x1a2da98, exceptfds=0x1a2dd28, timeout=0x0) at kernel/qeventdispatcher_unix.cpp:328 #3 0x00007f3a3b628066 in QEventDispatcherUNIXPrivate::doSelect (this=0x1a2d670, flags=..., timeout=0x0) at kernel/qeventdispatcher_unix.cpp:204 #4 0x00007f3a3b629ab1 in QEventDispatcherUNIX::processEvents (this=0x1a26450, flags=...) at kernel/qeventdispatcher_unix.cpp:615 #5 0x00007f3a2d107200 in QUnixEventDispatcherQPA::processEvents (this=0x1a26450, flags=...) at eventdispatchers/qunixeventdispatcher.cpp:70 #6 0x00007f3a3b5b389a in QEventLoop::processEvents (this=0x7fff8be05920, flags=...) at kernel/qeventloop.cpp:136 #7 0x00007f3a3b5b3b73 in QEventLoop::exec (this=0x7fff8be05920, flags=...) at kernel/qeventloop.cpp:212 #8 0x00007f3a3b5b7237 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1188 #9 0x00007f3a3bba0668 in QGuiApplication::exec () at kernel/qguiapplication.cpp:1446 #10 0x00007f3a3c4210b3 in QApplication::exec () at kernel/qapplication.cpp:2746 #11 0x00007f3a44282d8c in kdemain (argc=2, argv=0x7fff8be06048) at /home/martin/src/kf5/kde/workspace/kwin/main.cpp:555 #12 0x0000000000400c7f in main (argc=2, argv=0x7fff8be06048) at /opt/build/kf5/kde/workspace/kwin/kwin_dummy.cpp:3
note: problem doesn't happen if there is no window manager running yet
patch for Qt: https://codereview.qt-project.org/#change,85654
Git commit 6210b6bb8af128c8e93c77330af80185d8ac3bec by Martin Gräßlin. Committed on 21/05/2014 at 06:10. Pushed by graesslin into branch 'master'. Ensure the xcb connection gets flushed before the event dispatcher blocks This is a workaround for Qt versions which do not yet have the change https://codereview.qt-project.org/85654 It is important to have this workaround as applications can get stalled when a framework uses xcb and doesn't flush the connection manually. REVIEW: 118234 M +19 -0 src/platformtheme/CMakeLists.txt A +1 -0 src/platformtheme/config-platformtheme.h.cmake M +33 -0 src/platformtheme/main.cpp http://commits.kde.org/frameworkintegration/6210b6bb8af128c8e93c77330af80185d8ac3bec
i didn't tested yet the above commit, but i noticed this behaviour also when using kwin(_x11 ;-) with lxqt (so not sure is comment 3 100% true) on login (needed to press something during login)
the commit fixes the behaviour within KDE session, but the above comment is still valid (well, as is to be expected ;-) @Martin, the Qt review is, i hope, targeted for stable branch?
(In reply to comment #7) > @Martin, the Qt review is, i hope, targeted for stable branch? yes, but it's still not approved.