Bug 47641 - Fullscreen OpenGL apps crash X (Voodoo 3)
Summary: Fullscreen OpenGL apps crash X (Voodoo 3)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-06 10:37 UTC by Steven Brown
Modified: 2007-04-18 16:34 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-31 11:22:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XF86Config-4 (1.97 KB, text/plain)
2001-07-07 09:17 UTC, Steven Brown
no flags Details

Description Steven Brown 2001-07-06 10:37:38 UTC
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.

How reproducible:

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.

Additional info:

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

Comment 1 Alexei Podtelezhnikov 2001-07-06 17:18:53 UTC
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?

Comment 2 Steven Brown 2001-07-07 09:17:55 UTC
Created attachment 22927 [details]

Comment 3 Steven Brown 2001-07-07 09:27:05 UTC
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.

Comment 4 Alexei Podtelezhnikov 2001-07-07 18:18:41 UTC
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 
turned OFF. 

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.

Comment 5 Mike A. Harris 2001-07-13 03:54:15 UTC
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?

Comment 6 Mike A. Harris 2001-07-13 03:58:18 UTC
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.

Comment 7 Mike A. Harris 2001-07-18 18:17:03 UTC
Bero can you comment on this?

Comment 8 Mike A. Harris 2001-07-31 09:13:31 UTC
Bero?  Any problems you know of WRT GL and KDM?

Comment 9 Bernhard Rosenkraenzer 2001-07-31 09:38:15 UTC
No known problems, and definitely nothing I can reproduce here on a Matrox G200
or an ATI Rage Mobility M4.

Comment 10 Bernhard Rosenkraenzer 2001-07-31 09:39:48 UTC
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.

Comment 11 Mike A. Harris 2001-07-31 11:22:25 UTC
Will test on Voodoo 3.

Comment 12 Mike A. Harris 2001-08-08 11:33:55 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.