My Radeon has been sucking it back too. In Quake3 anything to do with 2d
is broken. And when I tried to quit it crashes and I'm forced to
reboot. Also Quake3 can't change video modes.
-Miles
On Sat, 7 Apr 2001, Harold Oga wrote:
> On Sat, Apr 07, 2001 at 09:36:00PM -0700, Joseph Carter wrote
On Sat, Apr 07, 2001 at 09:36:00PM -0700, Joseph Carter wrote:
>I would have to check, but I believe that it's already using 32.
>
>Yes, according to xdpyinfo:
>
>bitmap unit, bit order, padding:32, LSBFirst, 32
Hi,
Ok, I just tried it and it looks like the radeon driver doesn't support
24b
On Sat, Apr 07, 2001 at 10:15:20PM -0600, Harold Oga wrote:
> Hi,
>I have no problems with my Radeon LE on a MSI K7T Pro-2a board, which
> is a KT133, not a KT133a. One thing that you have setup different than I
> do is that you have it setup for 24bpp rather than 32bpp, which is what I
> hav
On Sat, Apr 07, 2001 at 08:31:52PM -0700, Jeffrey W. Baker wrote:
> > I'm still having problems with the Radeon. Since I grabbed the BIOS
> > settings on the last reboot, I'll try to provide as much information as I
> > can in the hopes that the problem may be reproduced, worked around, or
> > fi
On Sat, Apr 07, 2001 at 08:03:38PM -0700, Joseph Carter wrote:
>Section "Screen"
> Identifier "Default Screen"
> Device "ATI Radeon VIVO"
> Monitor "Dell P110"
> DefaultDepth24
># DefaultDepth16
> SubSection "Display"
>
On Sat, 7 Apr 2001, Joseph Carter wrote:
> I'm still having problems with the Radeon. Since I grabbed the BIOS
> settings on the last reboot, I'll try to provide as much information as I
> can in the hopes that the problem may be reproduced, worked around, or
> fixed. I've been using Mercury's
I'm still having problems with the Radeon. Since I grabbed the BIOS
settings on the last reboot, I'll try to provide as much information as I
can in the hopes that the problem may be reproduced, worked around, or
fixed. I've been using Mercury's CVS DRI Debian packages.
After a few hours, the m
Hi,
The resources page at:
http://dri.sourceforge.net/res.phtml
lists a number of precompiled libglide3.so ; it does not however say which
version of each architecture they were compiled for.
In my case I used the Alpha version from there which gave an Illegal
instruction when ran; I guess it
I haden't got this error message for a while.
---
[drm:radeon_freelist_get] *ERROR* returning NULL!
---
but when those start coming system is usually near total freeze.
same thing this time.
I'm puzzled. Not sure what that function is supposed to do. I tried to
look at it a bit but my knowledge
On Sat, Apr 07, 2001 at 07:14:44PM +0200, Chmouel Boudjnah wrote:
> > It would be better if the TREE variable were honored by the kernel module
> > in CVS. In the meantime, I have made this change in my local tree. It
> > won't work with 2.2 kernels of course, but who is still using those? ;)
>
as before 2D is working just fine.
3D.
when I run gears for some time eventually it hangs.
Now it seems that the gears starts to use 99.9% of CPU time instead of the
X.
So I compiled gears with -g and ran it remotely from gdb.
so here's what I got.
.
.
2966 frames in 5.001 seconds = 593.081 F
Joseph Carter wrote:
>
> On Fri, Apr 06, 2001 at 11:04:20AM -0400, Trond Eivind Glomsr?d wrote:
> > When building the DRI tree with DRM module for the kernel, the default
> > location to look for headers should be (this is the way Linus started
> > recommending last summer, if memory serves):
> >
Hi,
I just bought an ATI Radeon SDR 32mb board, installed it on my
Pentium II 333MHz box, and tried DRI, but to no avail. I want to run
fgfs (FlightGear:flight simulator for X using glx). Withoug DRI, fgfs
runs correctly, but it is very slow as a matter of fact. I have been
using Matrox G20
Joseph Carter <[EMAIL PROTECTED]> writes:
> It would be better if the TREE variable were honored by the kernel module
> in CVS. In the meantime, I have made this change in my local tree. It
> won't work with 2.2 kernels of course, but who is still using those? ;)
latest 2.2.x kernel has the /
On Friday 06 April 2001 05:50 pm, you wrote:
> I had to patch the source to get the module to load into my kernel -
> routines in drm_scatter.h were not being compiled.
Alan already fixed this a different way just last night.
Might need to revert it.
--
Nobody will ever need more than 640 kB R
On Fri, Apr 06, 2001 at 05:50:20PM -0600, Joe Van Andel wrote:
> I had to patch the source to get the module to load into my kernel -
> routines in drm_scatter.h were not being compiled.
>
This isn't the correct patch. the 20010407 tarball will have this fixed.
> Also, shou
On Fri, Apr 06, 2001 at 09:23:41PM -0400, Buddy Smith wrote:
> It changes:
>
> xc/lib/GL/mesa/src/drv/radeon/radeon_screen.c
> xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h
> xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
> xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_prob
I had to patch the source to get the module to load into my kernel -
routines in drm_scatter.h were not being compiled.
Also, should this installer install libglut.so.3 along with
libGLU.so.1.3 ?
*** mga_drv.c.bak Fri Apr 6 17:26:16 2001
--- mga_drv.c Fri Apr 6 17:26:29 2001
18 matches
Mail list logo
