Bugzilla Bug 178006

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