Bug 40926

Created attachment 51252 [details]
The Intel-driver xorg.conf file

This is the xorg.conf file used by the Intel driver.

Created attachment 51253 [details]
The VESA xorg.conf file

This is the VESA xorg.conf file that doesn't exhibit the offending behaviour.

Sounds like your client is trying to use SHM memory over a SSH proxied connection, which understandably does not work. (The client thinks it has a local connection when in fact it is a remote one.) If you run xtrace on gvim for the remote connections (which includes DISPLAY=localhost:0) and see if it is trying to use SHM, and see if it is ignoring the XErrors generated.

Hi Chris,

(In reply to comment #3)
> Sounds like your client is trying to use SHM memory over a SSH proxied
> connection, which understandably does not work. (The client thinks it has a
> local connection when in fact it is a remote one.) If you run xtrace on gvim
> for the remote connections (which includes DISPLAY=localhost:0) and see if it
> is trying to use SHM, and see if it is ignoring the XErrors generated.

before I run xtrace, I should note that some people told me this bug is a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=37629 which was bisected and there's a workaround there.

Indeed, since the solution there is to turn off SHM to prevent the client from being stupid. Neither bug has yet to indicate a driver bug (since all the comparisons are with different client code paths).

(In reply to comment #3)
> Sounds like your client is trying to use SHM memory over a SSH proxied
> connection, which understandably does not work. (The client thinks it has a
> local connection when in fact it is a remote one.) If you run xtrace on gvim
> for the remote connections (which includes DISPLAY=localhost:0) and see if it
> is trying to use SHM, and see if it is ignoring the XErrors generated.

These are the only lines with SHM mentioned in the gvim.xtrace:

000:<:0069: 16: Request(98): QueryExtension name='MIT-SHM'
000:<:006a:  4: MIT-SHM-Request(140,0): QueryVersion
000:<:00ba: 16: MIT-SHM-Request(140,1): Attach shmseg=0x05c00021 shmid=0x01c50002 readonly=false(0x00)

Can you upload the whole trace somewhere?

Created attachment 51272 [details]
The compressed gvim.xtrace.

This is the gvim xtrace as compressed by "xz".

(In reply to comment #7)
> Can you upload the whole trace somewhere?

I uploaded it as an attachment.

Actually, the work around I did disables caching of pixmap binding locations and does not turn off SHM in X (comment 5).

Meanwhile I did notice 1-2 smaller issues with my workaround, but I haven't investigated any further, yet. The new artefact I look is white open-/libreoffice buttons.
So while enabled caching of pixmap binding locations draws colors correctly but black where transparency should be, my patched driver draws white where colors should be but transparency correctly. Rather annoying, especially since the problem occurs with one program only.

Created attachment 52972 [details]
running dia with MIT-SHM disabled

I've tried disabling MIT-SHM extensions but the problem is still present.

with xtrace i can see that the applications ask for the extension but the server say it doesn't supports it.

000:<:0067: 16: Request(98): QueryExtension name='MIT-SHM'
000:>:0067:32: Reply to QueryExtension: present=false(0x00) major-opcode=0 first-event=0 first-error=0

When disabling MIT-SHM I also have the issue with local applications. 
(dia.xtrace.gz is xtrace from running dia on my laptop with MIT-SHM disabled)

I fount the fix for this issue.

I have the fix for natty (2.14 driver) and oneiric (2.15 driver)

the fix for 2.15 driver can be applied to the trunk.

Created attachment 53122 [details] [review]
This patch fix the transparency issue

i briefly tested this patch. but appliing this fix the issue when disabling MIT-SHM and also when using remote application (ssh -X)

*** Bug 37629 has been marked as a duplicate of this bug. ***

(In reply to comment #13)
> I fount the fix for this issue.
> 
> I have the fix for natty (2.14 driver) and oneiric (2.15 driver)
> 
> the fix for 2.15 driver can be applied to the trunk.

I just want to mention that the fixes are available on launchpad :
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/785280

That patch has quite a few side-effects. I think the crux is

diff --git a/src/i965_render.c b/src/i965_render.c
index 825fc13..8c7e2ac 100644
--- a/src/i965_render.c
+++ b/src/i965_render.c
@@ -1305,7 +1305,7 @@ gen4_set_picture_surface_state(intel_screen_private *intel
 
        memset(ss, 0, sizeof(*ss));
        ss->ss0.surface_type = BRW_SURFACE_2D;
-       if (is_dst)
+       if (is_dst || 1)
                ss->ss0.surface_format = i965_get_dest_format(picture);
        else
                ss->ss0.surface_format = i965_get_card_format(picture);

which implies that application is trying to render using alpha from a alpha-less pixmap.

Knowing what to look for, is half the battle:

000:<:1184: 16: Request(53): CreatePixmap depth=0x20 pid=0x05c00143 drawable=0x000000ae width=18 height=18
000:<:1185: 20: RENDER-Request(150,4): CreatePicture pid=0x05c00144 drawable=0x05c00143 format=0x0000003a values={}
000:<:1186: 20: RENDER-Request(150,4): CreatePicture pid=0x05c00145 drawable=0x05c00143 format=0x00000026 values={}
000:<:1187:1320: Request(72): PutImage format=ZPixmap(0x02) drawable=0x05c00143 gc=0x05c00030 width=18 height=18 dst-x=0 dst-y=0 left-pad=0x00 depth=0x20
000:<:1188: 36: RENDER-Request(150,8): Composite op=Over(0x03) src=0x05c00144 mask=0x05c00145 dst=0x05c00142 xSrc=0 ySrc=0 xMask=0 yMask=0 xDst=7 yDst=7 width=18 height=18

which is just insane.

Or a clever trick to premulitply the color channels. Argh.

(In reply to comment #17)
> That patch has quite a few side-effects. I think the crux is
> 
> diff --git a/src/i965_render.c b/src/i965_render.c
> index 825fc13..8c7e2ac 100644
> --- a/src/i965_render.c
> +++ b/src/i965_render.c
> @@ -1305,7 +1305,7 @@ gen4_set_picture_surface_state(intel_screen_private
> *intel
> 
>         memset(ss, 0, sizeof(*ss));
>         ss->ss0.surface_type = BRW_SURFACE_2D;
> -       if (is_dst)
> +       if (is_dst || 1)
>                 ss->ss0.surface_format = i965_get_dest_format(picture);
>         else
>                 ss->ss0.surface_format = i965_get_card_format(picture);
> 
> which implies that application is trying to render using alpha from a
> alpha-less pixmap.

this patch have pretty much the same behavior as this one for what I can quickly see (background image transition in gnome):

=== modified file 'src/i965_render.c'
--- src/i965_render.c	2011-10-14 11:01:34 +0000
+++ src/i965_render.c	2011-11-03 19:27:26 +0000
@@ -2220,13 +2220,13 @@
 		i965_set_picture_surface_state(intel,
 					       intel->render_source_picture,
 					       intel->render_source,
-					       FALSE);
+					       TRUE);
 	if (intel->render_mask) {
 		binding_table[2] =
 			i965_set_picture_surface_state(intel,
 						       intel->render_mask_picture,
 						       intel->render_mask,
-						       FALSE);
+						       TRUE);
 	}
 }

So I ripped out the surface binding cache:

commit 2174f840158aa9cfa370ade38be28f8dc8e4b526
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 3 20:41:31 2011 +0000

    uxa: Remove caching of surface binding location
    
    If the pixmap were to be used multiple times within a batch with
    mulitple formats, the cache would only return the initial location with
    the incorrect format and so cause rendering glitches. For instance, GTK+
    uses the same pixmap as an xrgb source and as an argb mask in order to
    premultiply and composite in a single pass. Rather than introduce an
    overly complication caching (handle, format) mechanism, kiss and remove
    the invalid implementation.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40926
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

That should fix this and the various incarnations.

Owain reported that this successfully fixed the issue with black icon backgrounds he was seeing, so closing.