From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3-12 i686)
Description of problem:
Trying to run any fullscreen OpenGL app such as tuxracer, Tribes 2, etc. in
a window causes X to crash, bringing the user back to the xdm/gdm/kdm
login. I've heard rumor that this is a Voodoo 3 related problem in this
version of XFree86, but haven't heard of a solution yet. The apps work
fine when run in a window, but fullscreen is a guaranteed instant crash.
Steps to Reproduce:
1. Run a fullscreen OpenGL application in X (probably specific to voodoo 3
Actual Results: X crashes, returning the user to the xdm-ish login.
Additionally, virtual consoles (control+alt+f1 for example) are screwed up
afterwards; they will show leftover graphics instead of text until the
system is rebooted.
Expected Results: A fat penguin should have slid down a mountainslope
trying to catch herring and some poor tribes 2 player should have been
r0xx0red by my m4d skillz.
I've heard this is Voodoo 3 specific, but can't find any substantial info
on it or how to fix it. Such apps used to work on my system before I
installed RedHat 7.1 (Ironically, to try and improve performance of said
Can you "create a new attachment" using the link below individualy
with /etc/X11/XF86Config-4 and with /var/log/XFree86.*.log (right after crash,
before you restart X).
The fact that it happenes only in fullscreen mode migt be due to the lack of
video memory. Can you reproduce it at, say, 1024x768x16bpp, or lower?
Created attachment 22927 [details]
While trying to get an XFree86.log to send in, I found what is causing the
problem (but not the solution). It's kdm related. I have DESKTOP="KDE" in
/etc/sysconfig/desktop so I can use kdm instead of gdm. The problem of X
crashing on fullscreen apps only occurs when using kdm instead of gdm. (Even
when using gdm to login to a KDE session fullscreen apps work fine). These
fullscreen crashes are repeatable via standard login with kdm in runlevel 5, or
by going to runlevel 3 and using kdm manually.
I'm not sure how to get an XFree86.*.log file after the crash, as kdm restarts
the X server instantly, but I believe this should be reproducible on any system
now just by configuring RedHat to use kdm.
This reminds me of the bug 36682. Aparently, KDE (Qt) and GL apps do not like
each other. I almost found a solution to that. Somebody on kde-devel told me
that Qt is supposed to be compiled WITHOUT GL support on XFree86. By default,
GL is ON in Qt. I checked .spec in qt.src.rpm, I didn't find where GL was
Maybe, I'm wrong, but I'm yet to hear a comment on this possible build mistake
in Qt. Mike, Bernhard, please tell us how Qt is compiled in RedHat, and if it
is appropriate or not, and briefly why.
It does not occur on every system using KDM, so I need your logs.
Does it occur if you do *not* use kdm/xdm/etc.? Change to runlevel 3
and run startx instead, does this fix it?
If it does not fix it, you can get the logs from /var/log then, make copies and
attach the log using the links below.
Bero can you comment on this?
Bero? Any problems you know of WRT GL and KDM?
No known problems, and definitely nothing I can reproduce here on a Matrox G200
or an ATI Rage Mobility M4.
We're compiling Qt with GL support because we want to provide this
functionality. We're using weak symbols for linking to GL though (patch in
qt-2.3.1-1 and higher), so this shouldn't be a problem, at least not with
anywhere near recent packages.
Will test on Voodoo 3.
I do not have this problem with Voodoo 3.
You *MUST* use 16bpp if you want 3D with DRI, and
you *MUST* use a lower resolution if you want DRI on a
16Mb card. DRI requires oodles of RAM, and can't get it if
you use high res. Solution is lower res, or card with more
Make sure the libglide3 symlink is pointing to the Voodoo3
Glide3 library in /usr/lib. Run glidelink if necessary.