Bug 135250 - desktop unusable due to flickering of windows if not "focus follows click"
Summary: desktop unusable due to flickering of windows if not "focus follows click"
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 135400 135562 135568 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-10-07 15:21 UTC by Arthur Marsh
Modified: 2006-11-02 13:56 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Patch as described. (6.54 KB, patch)
2006-10-07 23:22 UTC, Sune Vuorela
Details
kwin/client.cpp patch (2.30 KB, patch)
2006-10-09 12:16 UTC, Lubos Lunak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arthur Marsh 2006-10-07 15:21:38 UTC
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.
Comment 1 Sune Vuorela 2006-10-07 23:21:29 UTC
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)
Comment 2 Sune Vuorela 2006-10-07 23:22:42 UTC
Created attachment 18055 [details]
Patch as described.

The 'revert' patch
Comment 3 Sune Vuorela 2006-10-08 10:56:22 UTC
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
Comment 4 Sune Vuorela 2006-10-08 11:08:16 UTC
and just for the record, it is not related for the fix mentioned in my first message, this is from a later svn-commit
Comment 5 Lubos Lunak 2006-10-09 12:16:16 UTC
Created attachment 18066 [details]
kwin/client.cpp patch

Please confirm that this patch fixes the problem.
Comment 6 Lubos Lunak 2006-10-10 12:25:59 UTC
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 );
         }
     }
 
Comment 7 Lubos Lunak 2006-10-10 17:57:03 UTC
*** Bug 135400 has been marked as a duplicate of this bug. ***
Comment 8 Lubos Lunak 2006-10-13 16:51:15 UTC
*** Bug 135568 has been marked as a duplicate of this bug. ***
Comment 9 Lubos Lunak 2006-10-13 16:51:44 UTC
*** Bug 135562 has been marked as a duplicate of this bug. ***
Comment 10 John Relph 2006-11-01 01:03:22 UTC
This bug has been shipped in Fedora Core 6.  And it really needs to be fixed.