Michael D. Crawford wrote:
>
> glxinfo says dri is not available if I remove the library as I did. So I
> rebuilt Mesa and reinstalled it. The full output of glxinfo on my machine
> follows. Note that it says "direct rendering: Yes" but the version strings
> don't match. Does that indicate the
Michael D. Crawford wrote:
glxinfo says dri is not available if I remove the library as I did. So I
rebuilt Mesa and reinstalled it. The full output of glxinfo on my machine
follows. Note that it says "direct rendering: Yes" but the version strings
don't match. Does that indicate the
On Wed, 10 Jan 2001, Alan Cox wrote:
> > The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.
>
> Yep. Its Mesa 3.3/DRI 1.0. XFree86 CVS is Mesa 3.4/DRI 2.0. That has several
> advantages including mostly working on Matrox cards which 1.0 never did (for
> me anyway) and handling
> The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.
Yep. Its Mesa 3.3/DRI 1.0. XFree86 CVS is Mesa 3.4/DRI 2.0. That has several
advantages including mostly working on Matrox cards which 1.0 never did (for
me anyway) and handling things that Mesa 3.3 tried to allocate the odd
The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.
Michael is quite right in saying he needed to blow it away. The only
way I could get DRI working until recently was to transplant a copy
of libGL.so from the XFree86 build tree into /usr/lib, delete or rename
the Mesa package
On Mon, Jan 08, 2001 at 04:37:32PM -0800, J Sloan wrote:
> Ragnar Hojland Espinosa wrote:
> > Well, the real problem is that (at least Voodoo3) DRI didn't work _before_
> > with the "latest" test and pre kernels, and X < 4.0.2 (unless there was some
> > combination I didn't manage to find) even
On Mon, Jan 08, 2001 at 10:45:09PM +, Michael D. Crawford wrote:
> glxinfo says dri is not available if I remove the library as I did. So I
> rebuilt Mesa and reinstalled it. The full output of glxinfo on my machine
> follows. Note that it says "direct rendering: Yes" but the version
On Mon, 8 Jan 2001, J Sloan wrote:
> This is a little OT for linux-kernel, but I'll take a swing at it
> since I'm running 2.4 and Xfree 4 with a voodoo 3.
>
> After upgrading to Red Hat 7.0, I noticed 3D screensavers
> and Quake 3 Arena were dog slow - in the end, I basically
> had to make
On Mon, 8 Jan 2001, J Sloan wrote:
This is a little OT for linux-kernel, but I'll take a swing at it
since I'm running 2.4 and Xfree 4 with a voodoo 3.
After upgrading to Red Hat 7.0, I noticed 3D screensavers
and Quake 3 Arena were dog slow - in the end, I basically
had to make sure the
On Mon, Jan 08, 2001 at 10:45:09PM +, Michael D. Crawford wrote:
glxinfo says dri is not available if I remove the library as I did. So I
rebuilt Mesa and reinstalled it. The full output of glxinfo on my machine
follows. Note that it says "direct rendering: Yes" but the version strings
On Mon, Jan 08, 2001 at 04:37:32PM -0800, J Sloan wrote:
Ragnar Hojland Espinosa wrote:
Well, the real problem is that (at least Voodoo3) DRI didn't work _before_
with the "latest" test and pre kernels, and X 4.0.2 (unless there was some
combination I didn't manage to find) even if it was
The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.
Michael is quite right in saying he needed to blow it away. The only
way I could get DRI working until recently was to transplant a copy
of libGL.so from the XFree86 build tree into /usr/lib, delete or rename
the Mesa package
The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.
Yep. Its Mesa 3.3/DRI 1.0. XFree86 CVS is Mesa 3.4/DRI 2.0. That has several
advantages including mostly working on Matrox cards which 1.0 never did (for
me anyway) and handling things that Mesa 3.3 tried to allocate the odd
On Wed, 10 Jan 2001, Alan Cox wrote:
The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.
Yep. Its Mesa 3.3/DRI 1.0. XFree86 CVS is Mesa 3.4/DRI 2.0. That has several
advantages including mostly working on Matrox cards which 1.0 never did (for
me anyway) and handling
J Sloan ([EMAIL PROTECTED]) sez:
> This is a little OT for linux-kernel
Off-topic to debug a new kernel feature that will significantly add to the
competitiveness of Linux on the desktop and in engineering applications?
Remember, my original report was that DRI was reported to be working in
Ragnar Hojland Espinosa wrote:
> On Mon, Jan 08, 2001 at 02:56:05PM -0800, J Sloan wrote:
>
> > In my case, that meant nuking mesa from my system and
> > letting Linux use what was left, which got me back the good
> > accelerated performance - you may choose a less drastic
> > option. I don't
On Mon, Jan 08, 2001 at 02:56:05PM -0800, J Sloan wrote:
> In my case, that meant nuking mesa from my system and
> letting Linux use what was left, which got me back the good
> accelerated performance - you may choose a less drastic
> option. I don't see any breakage from the absence of mesa.
This is a little OT for linux-kernel, but I'll take a swing at it
since I'm running 2.4 and Xfree 4 with a voodoo 3.
After upgrading to Red Hat 7.0, I noticed 3D screensavers
and Quake 3 Arena were dog slow - in the end, I basically
had to make sure the mesa libs didn't get found before the
real
On Mon, Jan 08, 2001 at 06:35:43PM +, Michael D. Crawford wrote:
> OK, I built XFree86 4.0.2 and DRI seems to be working for me now under
> 2.4.0-ac4. (Starting with 2.4.0, it wouldn't, this is with an ATI XPert 2000
> AGP).
>
> BUT - although /var/log/XFree86.0.log documents the startup of
Michael D. Crawford ([EMAIL PROTECTED]) said:
> This makes me suspect it's not really working, or else my build of the Mesa-3.4
> library wasn't configured right - but note that if I disable DRI, one of the
> Mesa demos will comment that it's not available.
It sounds as if you're using a Mesa
OK, I built XFree86 4.0.2 and DRI seems to be working for me now under
2.4.0-ac4. (Starting with 2.4.0, it wouldn't, this is with an ATI XPert 2000
AGP).
BUT - although /var/log/XFree86.0.log documents the startup of DRI, DRM and AGP,
and states the info about their initialization and stuff so
OK, I built XFree86 4.0.2 and DRI seems to be working for me now under
2.4.0-ac4. (Starting with 2.4.0, it wouldn't, this is with an ATI XPert 2000
AGP).
BUT - although /var/log/XFree86.0.log documents the startup of DRI, DRM and AGP,
and states the info about their initialization and stuff so
Michael D. Crawford ([EMAIL PROTECTED]) said:
This makes me suspect it's not really working, or else my build of the Mesa-3.4
library wasn't configured right - but note that if I disable DRI, one of the
Mesa demos will comment that it's not available.
It sounds as if you're using a Mesa lib
On Mon, Jan 08, 2001 at 06:35:43PM +, Michael D. Crawford wrote:
OK, I built XFree86 4.0.2 and DRI seems to be working for me now under
2.4.0-ac4. (Starting with 2.4.0, it wouldn't, this is with an ATI XPert 2000
AGP).
BUT - although /var/log/XFree86.0.log documents the startup of DRI,
This is a little OT for linux-kernel, but I'll take a swing at it
since I'm running 2.4 and Xfree 4 with a voodoo 3.
After upgrading to Red Hat 7.0, I noticed 3D screensavers
and Quake 3 Arena were dog slow - in the end, I basically
had to make sure the mesa libs didn't get found before the
real
On Mon, Jan 08, 2001 at 02:56:05PM -0800, J Sloan wrote:
In my case, that meant nuking mesa from my system and
letting Linux use what was left, which got me back the good
accelerated performance - you may choose a less drastic
option. I don't see any breakage from the absence of mesa.
Well,
Ragnar Hojland Espinosa wrote:
On Mon, Jan 08, 2001 at 02:56:05PM -0800, J Sloan wrote:
In my case, that meant nuking mesa from my system and
letting Linux use what was left, which got me back the good
accelerated performance - you may choose a less drastic
option. I don't see any
J Sloan ([EMAIL PROTECTED]) sez:
This is a little OT for linux-kernel
Off-topic to debug a new kernel feature that will significantly add to the
competitiveness of Linux on the desktop and in engineering applications?
Remember, my original report was that DRI was reported to be working in
I get, with XFree86 4.0.1 and an ATI Rage Millenium card:
> (EE) r128(0): R128DRIScreenInit failed (DRM version = 2.1.2, expected 1.0.x).
> Disabling DRI.
Jeff Hartmann ([EMAIL PROTECTED]) says:
> XFree 4.0.2 will fix this
OK, so I'll give a try at building 4.0.2 the Slackware way. While
> Could XFree86 4.0.2 fix this? I had been waiting until the binary packages were
> available from ftp.slackware.com because Patrick Volkerding lays out the
> directories in a slightly different manner that he argues pretty convincingly is
> preferable, but it would be a drag for me to
Alan Olsen said once upon a time (Sat, 6 Jan 2001):
> On Sat, 6 Jan 2001, Michael D. Crawford wrote:
>
> > AGP, VIA support, DRM, and r128 DRM are all compiled in statically rather than
> > as modules.
>
> AGPGART doe *not* work if compiled statically. Compile it as a module.
> You will be much
Alan Olsen said once upon a time (Sat, 6 Jan 2001):
On Sat, 6 Jan 2001, Michael D. Crawford wrote:
AGP, VIA support, DRM, and r128 DRM are all compiled in statically rather than
as modules.
AGPGART doe *not* work if compiled statically. Compile it as a module.
You will be much happier.
Could XFree86 4.0.2 fix this? I had been waiting until the binary packages were
available from ftp.slackware.com because Patrick Volkerding lays out the
directories in a slightly different manner that he argues pretty convincingly is
preferable, but it would be a drag for me to reproduce by
I get, with XFree86 4.0.1 and an ATI Rage Millenium card:
(EE) r128(0): R128DRIScreenInit failed (DRM version = 2.1.2, expected 1.0.x).
Disabling DRI.
Jeff Hartmann ([EMAIL PROTECTED]) says:
XFree 4.0.2 will fix this
OK, so I'll give a try at building 4.0.2 the Slackware way. While
On Saturday 06 January 2001 10:30 pm, Alan Olsen wrote:
| AGPGART doe *not* work if compiled statically. Compile it as a
| module. You will be much happier. (i.e. It might actually work.) I
| would also compile DRM and the r128 drivers as modules as well.
it's worked fine compiled into the
On Sat, 6 Jan 2001, Michael D. Crawford wrote:
> AGP, VIA support, DRM, and r128 DRM are all compiled in statically rather than
> as modules.
AGPGART doe *not* work if compiled statically. Compile it as a module.
You will be much happier. (i.e. It might actually work.) I would also
compile
I was testing the 2.4.0 kernel by running "make exec" in the Mesa-3.4 sources,
which builds and runs a bunch of demos, and was suprised to see one of the tests
emit a message that said DRI wasn't available. It had been working before.
Just to make sure I then booted off of 2.4.0-prerelease-ac5
I was testing the 2.4.0 kernel by running "make exec" in the Mesa-3.4 sources,
which builds and runs a bunch of demos, and was suprised to see one of the tests
emit a message that said DRI wasn't available. It had been working before.
Just to make sure I then booted off of 2.4.0-prerelease-ac5
On Sat, 6 Jan 2001, Michael D. Crawford wrote:
AGP, VIA support, DRM, and r128 DRM are all compiled in statically rather than
as modules.
AGPGART doe *not* work if compiled statically. Compile it as a module.
You will be much happier. (i.e. It might actually work.) I would also
compile DRM
On Saturday 06 January 2001 10:30 pm, Alan Olsen wrote:
| AGPGART doe *not* work if compiled statically. Compile it as a
| module. You will be much happier. (i.e. It might actually work.) I
| would also compile DRM and the r128 drivers as modules as well.
it's worked fine compiled into the
40 matches
Mail list logo
