Yesterday I updated these things in our distribution:
- mesa 6.5.2
- xorg-server 1.1.1 with patch to build with mesa 6.5.2 sources (taken from fedora)
- all drivers updated to include latest DRI drivers from mesa 6.5.2 and latest
2D drivers from xf86-video-* releases
With these updates, beryl redraws parts of the screen as white parts. Some, but
not all, shadows appear as white borders and some parts of the screen are
covered in white squares.
This problem is always reproducible, until I remove libGL.so which came with
mesa 6.5.2, and replace it with the libGL.so from our 6.5.1 package. At that
moment, all shadows are drawn fine, all redraws are fine and no white parts are
visible at the screen anymore. At that moment Xorg still uses 6.5.2 for AIGLX (I
didn't restart X after replacing the library), all drivers are still from 6.5.2
and the rest of mesa is also from 6.5.2.
When I run glxinfo with this older version of libGL, I get these errors:
DISPATCH ERROR! _glapi_add_dispatch failed to add glAreTexturesResident!
DISPATCH ERROR! _glapi_add_dispatch failed to add glGenTextures!
DISPATCH ERROR! _glapi_add_dispatch failed to add glIsTexture!
libGL warning: 3D driver claims to not support visual 0x4b
The last warning is the same I get with 6.5.2 libGL.so and is related to the
R200 drivers not implementing that, which doesn't have anything to do with this
My guess is that the above error messages could be a good pointer to find out
what's wrong. Looking at the name of the functions, it's plausible that textures
aren't initialized correctly with the new method used by mesa 6.5.2.
You describe (clearly) exactly the same problem we are now seeing in Mandriva
I have attempted to update to to xorg-server 220.127.116.113 to see if that helps but
it does not.
I guess it's a mesa issue, could it be releated to GLX_EXT_tfp not appearing
under GLX Extensions in glxinfo? It appears under client and server extensions
fine. (I read somewhere this could be an issue).
Also I do not get the DISPATCH_ERROR messages, but get all the other problems so
these could be a red herring.
I am using the i810 driver.
FWIW, on archlinux (which I and the bug reporter both use) a number of people
have found that the recent upgrade of the libgl-dri mesa package
(http://www.archlinux.org/packages/10201/) to v6.5.2 appears to be the culprit.
Temporarily downgrading that package back to 6.5.1 appears to fix the issue.
(It did for me.) See arch's bug report at http://bugs.archlinux.org/task/6080
for more details.
Of course, this isn't a long term solution, and it still needs to be fixed
upstream here (or perhaps in beryl), but at least there's a workaround.
For reference, everything works for Pardus 2007 with xorg-server-7.2_rc3 + Mesa
6.5.2, package can be found at
(In reply to comment #3)
> For reference, everything works for Pardus 2007 with xorg-server-7.2_rc3 + Mesa
> 6.5.2, package can be found at
Interesting. I've got pretty much the same patches are you but do get the problem.
What drivers has this been tested on? For reference did you use beryl or compiz
(although in my tests both failed with the same symptoms) and did you make sure
your did not pass the --use-copy argument and obviously were not using Xgl, nor
the nVidia driver?
You are making sure compiz/beryl are using indirect rendering, right?
I can also reproduce this on my i810-based system, same distribution
(Archlinux), same X.Org, same Mesa. Downgrading to libGL.so from 6.5.1 "fixes"
the problem with i810 also and also generates the same errors from my initial
I can always reproduce the bug on my i810 based system (Intel G965 motherboard).
I have cloned git HEADs of xorg-server and mesa, applied the proposed patches in
bug 8991 and I'm still getting a white screen for Beryl. The screen also
flickers a lot at the Beryl splash logo.
I can also reproduce this error with mesa 6.5.2. "Downgrading" libgl.so "fixes"
the problem for me as well and I'm too on an intel card.
(In reply to comment #4)
> What drivers has this been tested on? For reference did you use beryl or compiz
> (although in my tests both failed with the same symptoms) and did you make sure
> your did not pass the --use-copy argument and obviously were not using Xgl, nor
> the nVidia driver?
We use beryl with that setup, we did not pass --use-copy or anything else, we
use AIGLX only and this is the list of drivers used in our xorg-video package;
And i forgot to add, we have lots of ati/intel users using beryl, by the way
attaching your Xorg.log and "LIBGL_DEBUG=verbose glxinfo" output may help to see
what may be the problem.
Created attachment 8335 [details]
glxinfo (with debug on)
Here is my glxinfo as you suggest. The do_wait: drmWaitVBlank bit is "normal"
in that it happened before when all was well.
Created attachment 8336 [details]
The two attachements are both with Mesa head from git (just built) and a
recompiled xserver RC3 (head didn't build for me) and rebuilt i810 driver.
Compiz (rebuilt) didn't work either.
My glproto is slightly older 1.4.7 (1.4.8 is out but I was hearing rumours that
it was borken?)
OK, this seems to be fixed for me.
1) Updated glproto to 1.4.8
2) Recompiled Mesa 6.5.2
3) Recompiled Xorg xserver 7.2. RC3 + Patches from bug 8991
4) Recompiled i810 driver (not sure if needed)
5) Recompiled compiz (not sure if needed - infact I doubt it is needed as beryl
also worked fine without recompile)
As far as I'm concerned I was just an idiot and this bug can be closed as
FWIW I also updated a couple of other protocols (xrandr to 1.2 and damage to git
(1.1)) but I doubt that matters here.
Yes, there's an incompatibility between glproto 1.4.8 and older versions, and
the current xserver GLX code hardcodes values from the new version. It's bizarre
that old versions of libGL worked though.
I pushed a change to xserver git to require glproto >= 1.4.8 for GLX. That's not
technically correct but will hopefully alert people to rebuild Mesa against the
new glproto as well.
So how do you explain the fact that this issue happens with xorg-server 1.1.1
and mesa 6.5.2 both compiled against glproto 1.4.8?
(In reply to comment #16)
> So how do you explain the fact that this issue happens with xorg-server 1.1.1
> and mesa 6.5.2 both compiled against glproto 1.4.8?
I can't... I suspect there are several issues here. E.g. you say that only parts
of the screen are white, whereas I'd expect the glproto mismatch to cause all of
it to be white, at least all the window contents managed by X.
I'm reopening for now, but I wonder if this couldn't be at least partially an
application issue, see e.g.
See also bug 9576.
(In reply to comment #14)
> OK, this seems to be fixed for me.
> 1) Updated glproto to 1.4.8
> 2) Recompiled Mesa 6.5.2
> 3) Recompiled Xorg xserver 7.2. RC3 + Patches from bug 8991
> 4) Recompiled i810 driver (not sure if needed)
> 5) Recompiled compiz (not sure if needed - infact I doubt it is needed as
glproto-1.4.8 with git HEADs of mesa and xserver + patches did not work for me.
I will try the official releases of Mesa and xserver now.
git HEADs of glproto, mesa, xorg-server ( + patches from bug 8991 ) and i810 are
now working without any problems. The bug should probably be closed.
OK, it really is a protocol mismatch issue.
With all these API changes things get quite complex. It seems that, besides
glproto, there's more things that change: the xorg-server/GL/glx headers
generated from Mesa/src/mesa/glapi XML files...
The gl server API generation scripts are not included in the tarball releases of
mesa. I checked out CVS on mesa_6_5_2 (don't know how to checkout a tag in GIT
and 6.5.2 is released before transition to git), used the "make server" target
from the glapi directory and rebuilt xorg-server 1.1.1 with the result.
After restarting X and starting beryl, my screen was completely corrupted due to
bad settings I tried. After removing all settings for beryl, it starts up fine,
borders returned to shadows again and the random white object flickering is
Well... I've tested these patch in my ubuntu machine following these steps:
- Installing glproto 1.4.8
- Rebuilding ubuntu xorg 1.1.1
- Rebuilding mesa git with attached patch
Result: Nothing changed! :(
Now I'm trying to package xorg 1.2.0 from git (+ patch) and new mesa... I've just to wait :|
(In reply to comment #21)
> Now I'm trying to package xorg 1.2.0 from git (+ patch) and new mesa... I've
> just to wait :|
Well... I got it... I mean that I packaged and installed xorg 1.2.0 patched, mesa from git patched and I've rebuilt some extra input modules to control my X session... BTW....
Running an X session with Beryl (using AiGLX with texture from pixmaps), while the transparency are available (for example the transparent cube works) all the windows are completely white. Rebuilding beryl didn't change anything.
The only way I found to get beryl working was using the --use-copy option, but if I'm not wrong that doesn't use AiGLX...
Do you have any tip for helping me?
(In reply to comment #22)
> (In reply to comment #21)
> > Now I'm trying to package xorg 1.2.0 from git (+ patch) and new mesa... I've
> > just to wait :|
> Well... I got it... I mean that I packaged and installed xorg 1.2.0 patched,
> mesa from git patched and I've rebuilt some extra input modules to control my X
> session... BTW....
I presume you know that xserver 1.2.0 has been officially released? (i.e. no need to build from git).
> Running an X session with Beryl (using AiGLX with texture from pixmaps), while
> the transparency are available (for example the transparent cube works) all the
> windows are completely white. Rebuilding beryl didn't change anything.
> The only way I found to get beryl working was using the --use-copy option, but
> if I'm not wrong that doesn't use AiGLX...
> Do you have any tip for helping me?
Have you applied the relevent patches from: bug 8991? I currently apply the glXDRIbindTexImage-target patch from there. I also apply several other patches recommended to me which can be found here:
Also make sure you build Mesa with -fno-strict-aliases as is recommended by the Mesa devs.
To get AIGLX working fine with Beryl, a few things have to be done:
- make sure glproto for mesa and xorg-server and beryl are the same
- make sure the DRI part of xorg-server is built using API hooks from mesa (xorg-server-1.1.x is using mesa 6.5 GLX API, xorg-server 1.2.x is using mesa 6.5.2 GLX API, for other combinations you have to fix this yourself)
- Build mesa with -fno-strict-aliasing in CFLAGS
For xorg-server-1.2.0, I applied these patches for AIGLX and Beryl:
Patches can be found in http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11/xorg-server/, or probably from Fedora CVS, as that's where I picked quite some from.
Other patches should not be required when building with Mesa 6.5.2.
(In reply to comment #23)
> I presume you know that xserver 1.2.0 has been officially released? (i.e. no
> need to build from git).
Ehm... I didn't really know that :P, btw was just to have tha latest version wich includes also some vbo things added few time ago on mesa and now merged also in xorg...
From recent tests using the 1.2.0 server released I've also seen that it doesn't compile using mesa-git so I had to build it against mesa 6.5.2.
In fact, now I'm doing that: compiling latest released versions of Xorg and Mesa with some patches for xorg (while nothing seems needed for mesa 6.5.2).
Btw, many thanks for your help... I'll let you know the results soon as I can
PS: Is there any chance to make all working with a patched version of Xorg 7.1 rebuilt against mesa 6.5.2?
(In reply to comment #25)
> In fact, now I'm doing that: compiling latest released versions of Xorg and
> Mesa with some patches for xorg (while nothing seems needed for mesa 6.5.2).
> Btw, many thanks for your help... I'll let you know the results soon as I can
Well this worked completely, now I'm running Xorg 7.2 with Mesa 6.5.2 using Beryl with texture from pixmap active (and with new mesa's features that allow me tu run the water plugin :P).
Btw latest question remains... Could I get mesa 6.5.2 working with beryl and patched Xorg 7.1 (I'd prefer to use that version for a better compatibility with my distro = ubuntu)?
PS: For people who want test I've debs for all these things ;)
Ops... I forgot to mention that I've some problems with other 3d applications like globs (globs.sf.net) or second life client (I don't use it, just for testing): I simply see a blank (black) window: no crashes and all seem to work there but I can't see anything.
Maybe they should be recompiled or it is another (un)known bug?
Others apps like Neverball, 3dbliard and beryl itself worked without recompiling :o