Version: (using KDE KDE 3.5.5) Installed from: Debian testing/unstable Packages OS: Linux Reported as Debian bug #391357. When using kwin 3.5.5-1 from Debian unstable, and in my case a focus setting of "focus strictly under mouse", windows flicker, making the desktop unusable. One other user reports that if focus is set to "click to focus", this problem does not occur.
Hi! I have been looking a bit into this. I have looked on the diff of kdebase-3.5.4/kwin and kdebase-3.5.5/kwin and slowly tried to eliminate the differences. It is the fix to http://bugs.kde.org/122425 that is the 'bad guy' in this sense. Reverting by using attached patch makes the flickering go away. (But it reopens 122425, which is a wishlist item)
Created attachment 18055 [details] Patch as described. The 'revert' patch
I tried to minimize the patch even further down and the following makes the flickering go away. I havo no clue in what other effect this will have. /Sune $ cat kdebase-3.5.5/debian/patches/30_kwin.diff diff -u kdebase-3.5.4.unpatched/kwin/client.cpp kdebase-3.5.4.unpatched/kwin/client.cpp --- kdebase-3.5.4.unpatched/kwin/client.cpp 2006-05-22 20:13:01.000000000 +0200 +++ kdebase-3.5.4.unpatched/kwin/client.cpp 2006-05-22 20:13:01.000000000 +0200 @@ -506,7 +504,6 @@ xrects, rects.count(), ShapeSet, mode ); delete[] xrects; } - updateShape(); } QRegion Client::mask() const
and just for the record, it is not related for the fix mentioned in my first message, this is from a later svn-commit
Created attachment 18066 [details] kwin/client.cpp patch Please confirm that this patch fixes the problem.
SVN commit 594159 by lunakl: Build the input shape on a helper window instead of directly, this avoids having a hole in the shape temporarily. This seems to break non-click-to-focus mouse policies on some systems (works fine here though). BUG: 135250 CCMAIL: kde-packager@kde.org M +19 -6 client.cpp --- branches/KDE/3.5/kdebase/kwin/client.cpp #594158:594159 @@ -477,17 +477,30 @@ // calls it or when the decoration is created/destroyed if( Shape::version() >= 0x11 ) // 1.1, has input shape support - { // there appears to be no way to find out if a window has input - // shape set or not, so always set propagate the input shape - // (it's the same like the bounding shape by default) - XShapeCombineShape( qt_xdisplay(), frameId(), ShapeInput, 0, 0, + { // There appears to be no way to find out if a window has input + // shape set or not, so always propagate the input shape + // (it's the same like the bounding shape by default). + // Also, build the shape using a helper window, not directly + // in the frame window, because the sequence set-shape-to-frame, + // remove-shape-of-client, add-input-shape-of-client has the problem + // that after the second step there's a hole in the input shape + // until the real shape of the client is added and that can make + // the window lose focus (which is a problem with mouse focus policies) + static Window helper_window = None; + if( helper_window == None ) + helper_window = XCreateSimpleWindow( qt_xdisplay(), qt_xrootwin(), + 0, 0, 1, 1, 0, 0, 0 ); + XResizeWindow( qt_xdisplay(), helper_window, width(), height()); + XShapeCombineShape( qt_xdisplay(), helper_window, ShapeInput, 0, 0, frameId(), ShapeBounding, ShapeSet ); - XShapeCombineShape( qt_xdisplay(), frameId(), ShapeInput, + XShapeCombineShape( qt_xdisplay(), helper_window, ShapeInput, clientPos().x(), clientPos().y(), window(), ShapeBounding, ShapeSubtract ); - XShapeCombineShape( qt_xdisplay(), frameId(), ShapeInput, + XShapeCombineShape( qt_xdisplay(), helper_window, ShapeInput, clientPos().x(), clientPos().y(), window(), ShapeInput, ShapeUnion ); + XShapeCombineShape( qt_xdisplay(), frameId(), ShapeInput, 0, 0, + helper_window, ShapeInput, ShapeSet ); } }
*** Bug 135400 has been marked as a duplicate of this bug. ***
*** Bug 135568 has been marked as a duplicate of this bug. ***
*** Bug 135562 has been marked as a duplicate of this bug. ***
This bug has been shipped in Fedora Core 6. And it really needs to be fixed.