Running /usr/bin/gvim with $DISPLAY set to ":0" renders the icons there correctly. On the other hand, running /usr/bin/gvim , after doing export DISPLAY="localhost:0", makes many icons on the toolbar have black or white backgrounds. This happens with other gtk+2.0 applications via ssh (which uses remote X). I'm on Mageia Linux 1 on a Core i3 x86-64 machine with «00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09)». Now, I've tested it with the vesa driver and the problem went away, and it also happens with my existing xorg.conf file after I remove the explicit 1280x1024 mode and the preferred mode directive. I don't have this problem in a VirtualBox Virtual Machine either or on my x86-64 with an ATI Mobility Radeon card Acer laptop running Mandriva Linux Cooker. Please look into this bug. I'll attach my xorg.conf files (the "vesa" one and the Intel-driver one) soon. Regards, -- Shlomi Fish
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.
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.