Although media-libs/mesa-6.5.2-r1 is marked x86 stable now, I have experienced problems with accelerated video drivers, via (K8N800, Unichrome Pro rev 01, my laptop) as well as radeon (Radeon 9200SE, RV280 rev 01, my computer at work). My main interest was with sci-chemistry/viewmol (using x11-libs/openmotif), but especially with via I met multiple problems -- GL screensavers were previewed out of the configuration window, and even glxgears appeared out of their window, either right from the start or after moving the window across the screen. Viewmol simply stopped displaying anything except a white window or, occasionally, a window with some scrambled mess inside. With radeon, unmasking media-libs/mesa-6.5.3 to test it seems to solve the problems, but with via, installing cutting edge versions of mesa and xorg helped viewmol only to freeze up my entire system with sys-kernel/gentoo-sources-2.6.21 or simply segfault on start with sys-kernel/gentoo-sources-2.6.18-r6. Masking >=media-libs/mesa-6.5.2, >=x11-base/xorg-server-1.2.0, and >=x11-base/xorg-x11-7.2 works.
Have you tried rebuilding some of these GL apps against the newer Mesa/Xserver?
(In reply to comment #1) > Have you tried rebuilding some of these GL apps against the newer Mesa/Xserver? I think so. Interestingly, with radeon video card upgrading Mesa to 6.5.3 seemes to have helped without rebuilding applications; downgrading to 6.5.1-r4 after the attempted upgrade on VIA hardware took more recompilation, first downgrading x11-base/xorg-x11 and x11-base/xorg-server to compatible versions, and then recompiling all the x11-drivers/* installed to have them use the appropriate ABI version, but recompilation of sci-chemistry/viewmol was not necessary either. Before I resorted to the downgrade of Mesa and X server, I had tried recompiling x11-libs/openmotif and sci-chemistry/viewmol at least. And even if that means I had left some important library aside, glxgears are part of Mesa distribution itself, so at least that program should not have any broken dependency responsible for its wrong display behaviour, I hope. Since the problematic VIA platform is in my personal laptop, I can experiment with it more or less freely, limited almost exclusively by my supply of spare time, my knowledge and my skill. So I welcome any test recommendations. Since I have found http://bugs.freedesktop.org/show_bug.cgi?id=9810 and of two bugs it points to at least http://bugs.freedesktop.org/show_bug.cgi?id=9965 seems to have been fixed, I should possibly return to experiments with Mesa 6.5.3. On the other hand, according to http://wiki.openchrome.org/tikiwiki/tiki-index.php?page=3DStatus I should probably either revert Mesa as low as to 6.4.1 (no longer in portage tree) or buy another hardware. Unfortunately I lack the skill necessary to have the third option: to take over the 3D Unichrome driver developement.
Interestingly, with radeon video card upgrading Mesa to 6.5.3 seemes to have > helped without rebuilding applications; Same here. On my stable x86 system with a radeon RV280, using the open source radeon driver, the current stable mesa 6.5.2-r1 is unusable for many OpenGL apps. PlanetPenguin Racer, Stellarium, etc. all have serious text rendering issues. Unmasking the hard-masked 6.5.3 fixes the problem, and I haven't seen any crashes yet. If it's not possible to bump mesa back a version due to xorg dependencies, it may be a good idea to bump it forward asap in stable to a version that works.
>Interestingly, with radeon video card upgrading Mesa to 6.5.3 seemes to have >helped without rebuilding applications; also helped my x86 system with accelerated video driver (VIA KM400/KM400A). so all application work as good as with <mesa-6.5.2
I've tried the newest versions at my VIA K8N800 laptop, including Mesa 7.0 (mesa-6.5.3.ebuild is easy to adapt, just changing the name and leaving out an epatch line in src_unpack), but my results are disappointing. After having to disable the glx module in xorg.conf, since glxgears and even glxinfo were freezing my machine, I finally noticed that the x11-base/xorg-server ebuild uses Mesa sources for building of the glx module (so much for modularity?). Changing MESA_PV in the ebuild from 6.5.2 to 6.5.3 or 7.0 looked easy, but proved next to impossible. Apparently the xorg-server uses several source files of Mesa, that are no longer in its newest versions, starting from 6.5.3. Thus upgrading xorg-server for newer Mesa version would mean rewriting it; I haven't found even the courage to check how much, not to speak of actually doing the work. To sum it up, until there is new version of xorg-server using new Mesa, we are in principle stuck with Mesa 6.5.2. Successful collaboration between Mesa 6.5.3 and Xorg glx module build from Mesa 6.5.2 sources is probably sheer luck. When Mesa 6.5.2 does wrong, downgrade is probably the only reasonably safe solution for now.
(In reply to comment #5) > I've tried the newest versions at my VIA K8N800 laptop, including Mesa 7.0 > (mesa-6.5.3.ebuild is easy to adapt, just changing the name and leaving out an > epatch line in src_unpack), but my results are disappointing. After having to > disable the glx module in xorg.conf, since glxgears and even glxinfo were > freezing my machine, I finally noticed that the x11-base/xorg-server ebuild > uses Mesa sources for building of the glx module (so much for modularity?). > Changing MESA_PV in the ebuild from 6.5.2 to 6.5.3 or 7.0 looked easy, but > proved next to impossible. Apparently the xorg-server uses several source files > of Mesa, that are no longer in its newest versions, starting from 6.5.3. Thus > upgrading xorg-server for newer Mesa version would mean rewriting it; I haven't > found even the courage to check how much, not to speak of actually doing the > work. > > To sum it up, until there is new version of xorg-server using new Mesa, we are > in principle stuck with Mesa 6.5.2. Successful collaboration between Mesa 6.5.3 > and Xorg glx module build from Mesa 6.5.2 sources is probably sheer luck. When > Mesa 6.5.2 does wrong, downgrade is probably the only reasonably safe solution > for now. > Thank you everybody for the accurate information in this thread. I was lost trying to figure out where to start looking for the solution to corrupted text in Planet Penguin Racer that many others have also reported. This seems to be an old thread, but the problem is still there, because the current stable release for mesa is mesa-6.5.2-r1. Downgrading is not trivial because currently there is no older version in the portage tree. Following worked for me. The penguin texts are readable and everything else seems to work. I updated mesa and it's dependencies and did no further updates or recompilations of other packages. I do not know how this will affect my next update of xorg-server with mixed x86/~x86 packages. I probably should postpone that update until the newer mesa is marked stable. Maybe the details of my update are helpful for someone else also: Contents of my /etc/portage/package.keywords: media-libs/mesa x11-libs/libdrm x11-proto/xextproto x11-libs/libXext x11-proto/inputproto x11-libs/libX11 x11-proto/xf86driproto x11-libs/libXxf86vm x11-proto/dri2proto x11-apps/mesa-progs The package updates: [ebuild U ] x11-proto/inputproto-1.5.0 [1.4.2.1] [ebuild U ] dev-libs/expat-2.0.1-r1 [2.0.1] [ebuild U ] x11-proto/xextproto-7.0.4 [7.0.2] [ebuild U ] x11-libs/libdrm-2.4.4 [2.3.0] [ebuild U ] x11-proto/xf86driproto-2.0.4 [2.0.3] [ebuild U ] x11-libs/libX11-1.1.5 [1.1.4] [ebuild U ] x11-libs/libXext-1.0.4 [1.0.3] [ebuild U ] x11-libs/libXxf86vm-1.0.2 [1.0.1] [ebuild U ] media-libs/mesa-7.2 [6.5.2-r1] I had to compile libdrm twice due to some gcc-internal error in the first run that probably has something to do with my hw or compiler flags. The emerge of mesa ended in the following message and hung: Switching to xorg-x11 OpenGL interface.../var/tmp/portage/media-libs/mesa-7.2/temp/environment: line 3108: 6829 Killed eselect opengl set --use-old ${OPENGL_DIR} I killed the first eselect process in the ps -a listing and the emerge finished successfully. I have xorg-server-1.3.0.0-r6 installed btw.
Mesa 7.3-r1 is now stable on all arches. If anyone still has opengl issues with a fully update system (xorg-server 1.5.3-r5), please don't hesitate to reopen this bug or to file new ones. Closing as per comment #6 Thanks
