Bug 13683

Summary: XACE-SELINUX merge causes flickering.
Product: xorg Reporter: Lukasz Krotowski <lukasz.krotowski>
Component: Server/GeneralAssignee: Eamon Walsh <ewalsh>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: nigel
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Black rectangle when switching tabs in browser.
none
Xorg config file used with faulty server.
none
Xorg log from faulty server.
none
Test Patch none

Description Lukasz Krotowski 2007-12-15 17:21:48 UTC
During screen update (switching tabs in browser, context menu popup etc.) invalidated recs are filled with black color. Which causes uneasy flickering. It happens both with EXA and XAA. With DRI and without DRI. Server built from last commit before XACE-SELINUX merge work fine.
Comment 1 Lukasz Krotowski 2007-12-15 17:22:56 UTC
Created attachment 13135 [details]
Black rectangle when switching tabs in browser.
Comment 2 Lukasz Krotowski 2007-12-15 17:24:15 UTC
Created attachment 13136 [details]
Xorg config file used with faulty server.
Comment 3 Lukasz Krotowski 2007-12-15 17:24:48 UTC
Created attachment 13137 [details]
Xorg log from faulty server.
Comment 4 Eamon Walsh 2007-12-17 18:38:46 UTC
*** Bug 13715 has been marked as a duplicate of this bug. ***
Comment 5 Eamon Walsh 2007-12-17 18:40:53 UTC
Please disable XACE by compiling with 
Comment 6 Nigel Cunningham 2007-12-17 18:49:26 UTC
Eamon, your comment seems to have been truncated. Could you say what option you want disabled and where?

Ta!

Nigel
Comment 7 Eamon Walsh 2007-12-17 18:54:19 UTC
Nevermind previous.  Try the attached patch.
Comment 8 Eamon Walsh 2007-12-17 18:55:13 UTC
Created attachment 13177 [details] [review]
Test Patch
Comment 9 Lukasz Krotowski 2007-12-17 19:08:54 UTC
Sish, just after 'make clean'. ;) Nevermind, the good thing is that above patch fixes issue for me. Thanks.
Comment 10 Nigel Cunningham 2007-12-17 19:27:31 UTC
Works for me too. Thanks!
Comment 11 Eamon Walsh 2007-12-17 20:13:31 UTC
I have committed a fix to master.

However, I'd like to know what desktop environments and applications you encountered this problem on.  Is this occuring only on gtk or qt apps?  What about non-toolkit apps such as Firefox or OpenOffice?

The cause of this bug is that I changed the default behavior for windows that have a background set to "None".  The previous behavior was to make them transparent which is a security problem.  I changed it to solid black.  Note that according to the X Protocol, background None results in "undefined behavior" so I am allowed to do this.  However it looks like some toolkits and/or applications are relying on the transparent behavior.
Comment 12 Lukasz Krotowski 2007-12-17 20:44:42 UTC
Faulty apps:
Gtk apps (gtk version 2.12.1): liferea, kazehakase (with gecko engine), gvim.
Non-toolkit: seamonkey (version 1.1.5).

Pure X apps (like urxvt) worked fine. I've not tried Qt or OOo.
Comment 13 Lukasz Krotowski 2007-12-17 20:47:13 UTC
Desktop environment: none, just fluxbox. O even single urxvt without anything else.
Comment 14 Lukasz Krotowski 2007-12-17 21:14:59 UTC
More tests:
OOo (version 2.3.0): flickers.
kcachegrind (qt version 3.3.8, kdelibs version 3.5.8): flickers.
Comment 15 Nigel Cunningham 2007-12-17 22:37:11 UTC
I saw it with KDE, in the panel (especially app icons) and in thunderbird and Firefox. Not sure if I saw it in konsole.
Comment 16 Søren Sandmann Pedersen 2007-12-18 13:15:09 UTC
GTK+ certainly relies on bg=None windows retaining the existing contents of the screen in many cases, to minimize flashing.

The protocol spec says this:

> If the background is None, the previous screen contents from other windows of the same depth as the window are simply left in place if the contents come from the parent of the window or an inferior of the parent; otherwise, the initial contents of the exposed regions are undefined. 

(From the description of the CreateWindow request)

So as long as the windows have the same depth, I believe GTK+ is justified in relying on this.
Comment 17 Eamon Walsh 2007-12-18 13:52:16 UTC
OK, I missed that, I only read as far as the "undefined background" sentence.  The old SECURITY extension did the same thing so I felt somewhat confident in the approach.

I guess this is going to have to be fixed some other way, perhaps by keeping track of undrawn regions and censoring them out in the CopyArea code.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.