On Thu, May 03, 2001 at 08:53:32PM -0700, Eric Anholt wrote:
> I've got diffs to get BSD DRM almost compiling for tdfx and mga up on my
> site. Check bsd-2-0-0-branch diffs (and the drm_agpsupport.h file, I didn't
> feel like merging linux and bsd agp into a single file right now). They are
>
> On Thu, May 03, 2001 at 08:53:32PM -0700, Eric Anholt wrote:
> > I've got diffs to get BSD DRM almost compiling for tdfx and mga up on my
> > site. Check bsd-2-0-0-branch diffs (and the drm_agpsupport.h file, I
didn't
> > feel like merging linux and bsd agp into a single file right now). They
On Fri, May 04, 2001 at 11:51:09AM +0100, Doug Rabson wrote:
>
> > On Thu, May 03, 2001 at 08:53:32PM -0700, Eric Anholt wrote:
> > > I've got diffs to get BSD DRM almost compiling for tdfx and mga up on my
> > > site. Check bsd-2-0-0-branch diffs (and the drm_agpsupport.h file, I
> didn't
> > >
On Thu, 3 May 2001, Joseph Carter wrote:
> On Thu, May 03, 2001 at 09:47:23PM -0700, Jeffrey W. Baker wrote:
> > > There also appears to be a conflict with the Radeon 64 and the KT133A (or
> > > at least the Abit KT7A..)
> > I've got a KT133A and a Radeon All-in-Wonder, with no problems at all.
>
Why is this a problem? How many people out there are swapping back and
forth between a V3 and V5 on the same machine and need to change symlinks?
Adam
On Fri, 4 May 2001, Mike A. Harris wrote:
> I'd like opinions on what would be the best way of determining at
> runtime what glide library to
On Fri, May 04, 2001 at 01:12:47PM +0100, Iain Thomas wrote:
> > As I said, it seems specific to the Radeon 64, the 32s have been reported
> > to work fine.
>
> We all know that the various Radeons have differend core clock-speeds,
> right?
We do now. =)
> The retail 64M is 183Mhz, the plain
On Fri, 4 May 2001, Joseph Carter wrote:
> On Fri, May 04, 2001 at 01:12:47PM +0100, Iain Thomas wrote:
> > > As I said, it seems specific to the Radeon 64, the 32s have been reported
> > > to work fine.
> > We all know that the various Radeons have differend core clock-speeds,
> > right?
> We do
I'd like opinions on what would be the best way of determining at
runtime what glide library to use? The current problem is that
there are 2 Glide libraries for Glide3 - one for Voodoo 3, and
another for Voodoo 5. This is inconvenient to say the least.
Currently, we symlink libglide3.so.3.10.0
It depends on what part of the process you want to solve.
For the DRI, the easiest solution would be to have the dri_tdfx.o
dynamically load the appropriate Glide. The X server knows what hardware
it is running on and passes that to the client (via the PCI id). If you
did this, you could also cha
Gareth Hughes wrote:
>
> Brian Paul wrote:
> >
> > I don't have my G400 installed right now but next time I do I'll look
> > into this.
>
> Brian, I'm swapping a G400 in this weekend to finish the 3.5 merge
> stuff, so I can take a look if you like.
I was planning on looking into it today. We'
Brian Paul wrote:
>
> Gareth Hughes wrote:
> >
> > Brian Paul wrote:
> > >
> > > I don't have my G400 installed right now but next time I do I'll look
> > > into this.
> >
> > Brian, I'm swapping a G400 in this weekend to finish the 3.5 merge
> > stuff, so I can take a look if you like.
>
> I wa
>
> I'm planning a late night tonight on the tdfx stuff (I'd like to get it
> basically ready to commit), and was going to look at various MGA stuff
> tomorrow. Feel free to work on this, and I can take the merge nastiness
> and Tribes2 stuff ;-)
Speaking of which, I've been thinking about ord
Adam K Kirchhoff wrote:
>
> >
> > I'm planning a late night tonight on the tdfx stuff (I'd like to get it
> > basically ready to commit), and was going to look at various MGA stuff
> > tomorrow. Feel free to work on this, and I can take the merge nastiness
> > and Tribes2 stuff ;-)
>
> Speaking
Today, Mike A. Harris wrote:
>I'd like opinions on what would be the best way of determining at
>runtime what glide library to use? The current problem is that
>there are 2 Glide libraries for Glide3 - one for Voodoo 3, and
>another for Voodoo 5. This is inconvenient to say the least.
>
>Curren
Gareth Hughes wrote:
>
> Brian Paul wrote:
> >
> > Gareth Hughes wrote:
> > >
> > > Brian Paul wrote:
> > > >
> > > > I don't have my G400 installed right now but next time I do I'll look
> > > > into this.
> > >
> > > Brian, I'm swapping a G400 in this weekend to finish the 3.5 merge
> > > stuff
--- xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c.orig Fri May 4 17:49:16
2001
+++ xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c Fri May 4 17:49:32
+2001
@@ -235,7 +235,7 @@
if (!xf86LoaderCheckSymbol("drmAvailable"))return FALSE;
if (!xf86LoaderCheckSymb
Guido Guenther wrote:
>
> --- xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c.orig Fri May 4 17:49:16
>2001
> +++ xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c Fri May 4 17:49:32
>2001
> @@ -235,7 +235,7 @@
> if (!xf86LoaderCheckSymbol("drmAvailable"))return F
> For the DRI, the easiest solution would be to have the dri_tdfx.o
> dynamically load the appropriate Glide. The X server knows what
> hardware it is running on and passes that to the client (via the PCI
> id). If you did this, you could also change the X tree to include the
> appropriate glide.h
On Fri, May 04, 2001 at 11:02:05AM -0400, Jon Niehof wrote:
> > For the DRI, the easiest solution would be to have the dri_tdfx.o
> > dynamically load the appropriate Glide. The X server knows what
> > hardware it is running on and passes that to the client (via the PCI
> > id). If you did this, y
On Thu, May 03, 2001 at 08:15:19PM -0500, Andy Isaacson wrote:
> On Thu, May 03, 2001 at 04:26:00PM -0600, Brian Paul wrote:
> > Would it be better if the DRI User Guide were divided into a number of
> > separate HTML pages, instead of one long document? I could do that
> > with the sgml2html c
Jon Pennington wrote:
>
> On Thu, May 03, 2001 at 08:15:19PM -0500, Andy Isaacson wrote:
>
> > On Thu, May 03, 2001 at 04:26:00PM -0600, Brian Paul wrote:
>
> > > Would it be better if the DRI User Guide were divided into a number of
> > > separate HTML pages, instead of one long document? I c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since at least yesterday, the 3rd, the Radeon packages fail to
correctly identify the Radeon VE card, even though it's listed as an
option.
Also, the binary package (just the drivers) for today (the 4th), seems
to be missing core/libdrm.a .
- --
Mark Allan wrote:
>
> Mark Allan wrote:
> >
> > Brian Paul wrote:
> > >
> > > Pasi Kärkkäinen wrote:
> > > >
> > > > Hello!
> > > >
> > > > Are there known blending bugs in the mga-driver (g400)? When I render many
> > > > additive polygons on the top of each other with small alpha-value
> > > >
Ah, I see you're running into the same problem I did a while back.
(I'm the Debian glide maintainer.)
What we do is actually pretty close to that, I use debconf for the
interface though with a little work it could easily be split out.
Basicly at install time I use lspci to find the cards in the
In lines 267,308 of i810_dri.c there is:
pI810->pDRIInfo = pDRIInfo;
pDRIInfo->devPrivate = pI810DRI;
and in 731 the there is again:
pI810DRI=(I810DRIPtr)pI810->pDRIInfo->devPrivate;
Is there any reason for that? Otherwise one could apply:
--- xc/programs/Xserver/hw/xfree86/drivers/i8
>> Andy Isaacson <[EMAIL PROTECTED]> writes:
> to create an account for just that purpose. If someone who already has
> a SourceForge account could do so, I'd appreciate it...
Done. Request id 421523. Let's hope for a positive reply.
--
Marcelo
__
I have it disabled in my host.cf but it stops compilation.
Greetings,
Dieter
gcc -c -O -mcpu=k6 -fomit-frame-pointer -mpreferred-stack-boundary=2
-malign-functions=4 -fschedule-insns2 -fexpensive-optimizations -ansi -Wall
-Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmis
On Fri, 4 May 2001, Adam K Kirchhoff wrote:
>Date: Fri, 4 May 2001 09:10:34 -0400 (EDT)
>From: Adam K Kirchhoff <[EMAIL PROTECTED]>
>To: Mike A. Harris <[EMAIL PROTECTED]>
>Cc: dri-devel <[EMAIL PROTECTED]>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Subject: Re: [Dri-devel] Determining the prop
On Sat, May 05, 2001 at 01:32:07AM +1000, Gareth Hughes wrote:
> Adam K Kirchhoff wrote:
> > Speaking of which, I've been thinking about ordering Tribes2 and was
> > wondering if there are any issues that we should be aware of?
>
> Go and buy this game. It rocks. Loki has done a great job, and
When it comes 'bus lock up' and VIA chipset ... checkout
http://www.viahardware.com/ there you should find latest
via 'PCI latency patch' that also fixes ... (or supposed to fix)
such random locks up ...
btw. That patch is in the latest greatest kernels. including
2.4.3-acX (X > 12) and later.
On Fri, May 04, 2001 at 08:19:44PM -0500, Andy Isaacson wrote:
> On Sat, May 05, 2001 at 01:32:07AM +1000, Gareth Hughes wrote:
> > Adam K Kirchhoff wrote:
> > > Speaking of which, I've been thinking about ordering Tribes2 and was
> > > wondering if there are any issues that we should be aware of?
On Fri, May 04, 2001 at 08:19:44PM -0500, Andy Isaacson wrote:
> On Sat, May 05, 2001 at 01:32:07AM +1000, Gareth Hughes wrote:
> > Adam K Kirchhoff wrote:
> > > Speaking of which, I've been thinking about ordering Tribes2 and was
> > > wondering if there are any issues that we should be aware of?
Andy Isaacson wrote:
>
> On Sat, May 05, 2001 at 01:32:07AM +1000, Gareth Hughes wrote:
> > Adam K Kirchhoff wrote:
> > > Speaking of which, I've been thinking about ordering Tribes2 and was
> > > wondering if there are any issues that we should be aware of?
> >
> > Go and buy this game. It rock
On Fri, 4 May 2001, Jon Niehof wrote:
>> For the DRI, the easiest solution would be to have the dri_tdfx.o
>> dynamically load the appropriate Glide. The X server knows what
>> hardware it is running on and passes that to the client (via the PCI
>> id). If you did this, you could also change the
On Fri, 4 May 2001, Philip Willoughby wrote:
>>Any pre-existing code out there to solve this problem? I don't
>>have any 3dfx cards to test with at all, so any help getting a
>>solution happening would be great.
>>
>>Thoughts/comments/suggestions, etc.?
>
>What I would do, as a quick-and-dirty h
My development machine tracks debian unstable pretty closely (apt-get
update && apt-get -u upgrade every few days), and recently when I had a
chance to grab the latest DRI tree and built it, I had client programs
failing to start with
straum% gears
gears: error while loading shared libraries: /da
On Fri, May 04, 2001 at 09:22:59PM -0400, Zilvinas Valinskas wrote:
> When it comes 'bus lock up' and VIA chipset ... checkout
> http://www.viahardware.com/ there you should find latest
> via 'PCI latency patch' that also fixes ... (or supposed to fix)
> such random locks up ...
>
> btw. That pat
37 matches
Mail list logo
