Michael wrote:
>
> On Wed, Feb 20, 2002 at 01:28:38AM +, Keith Whitwell wrote:
> > Just a note that I've committed the bulk of a functional tcl radeon driver to
> > the new 'tcl-0-0-branch'. This is basically my code as of about a 10 days
> > ago, which exercises most of the t&l hardware but
> >
> > Have you looked at Alan H's tools for sanity-checking DRI installs? I've
> > always thought that these might be useful when trying to write an
> > installer
> > for DRI binary distributions.
> >
> > Keith
> >
>
> Daryll mentioned them and said he would try to contact Alan. I don't have
On Wed, Feb 20, 2002 at 01:28:38AM +, Keith Whitwell wrote:
> Just a note that I've committed the bulk of a functional tcl radeon driver to
> the new 'tcl-0-0-branch'. This is basically my code as of about a 10 days
> ago, which exercises most of the t&l hardware but doesn't have any cool
> o
On 19 Feb 2002, Sergey V. Udaltsov wrote:
> > That's because tunnel tries to use alpha blending _and_ fog, which isn't
> > possible on mach64 (we're looking into a workaround though). If you
> OK. For a moment, I just will remember this fact.
> > > 2. For some reason, X server gets signal 11 a
On 2002.02.20 02:07 Keith Whitwell wrote:
> José Fonseca wrote:
> >
> > ...
> >
> > Trunk:
> >
> > For the drivers at the trunk I'll assume that the user will have XFree
> > 4.2.0 so it will only be necessary to pack:
> > - the DDX driver (/usr/X11R6/lib/modules/drivers/*_drv.o)
> > - the Mesa dri
José Fonseca wrote:
>
> I've been trying to figure out what is needed for releasing DRI binary
> snapshots. There are two different trees with different particularities
> that I'm interested for now: the trunk and the mach64-0-0-2-branch.
>
> Common:
>
> In both cases there is the need for the
On 2002.02.19 19:35 Michael Thaler wrote:
> On Tue, Feb 19, 2002 at 07:02:47PM +, Jose Fonseca wrote:
>
> > Michael, please try to copy the glxinfo & glxgears binaries to other
> > place and run them from there.
>
> Jose, I copied glxinfo and glxgears from /usr/X11R6 to /root and tried it
>
I've been trying to figure out what is needed for releasing DRI binary
snapshots. There are two different trees with different particularities
that I'm interested for now: the trunk and the mach64-0-0-2-branch.
Common:
In both cases there is the need for the sources of the DRM to be built on
Michael wrote:
> I don't see your problem? I'm using debian unstable. Adding
> /usr/foo/bar/ to /etc/ld.so.conf and running /sbin/ldconfig works just
> fine (as Jose described)
>
> see man 8 ld.so, it searches LD_LIBRARY_PATH, /etc/ld.so.cache then
> /usr/lib and /lib.
You're right. It was a re
Just a note that I've committed the bulk of a functional tcl radeon driver to
the new 'tcl-0-0-branch'. This is basically my code as of about a 10 days
ago, which exercises most of the t&l hardware but doesn't have any cool
optimizations. Since then I've been working on cool optimizations, but
t
I've put the UT (partial) source, the specific version of openal and build
instructions at http://mefriss1.swan.ac.uk/~jfonseca/dri/ut/ .
This is just a tarball of what I had on my hardriver and it hasn't been
tested for a long time so please be patient if you encounter problems.
Regards,
Jos
On 2002.02.19 20:47 Leif Delgass wrote:
> On Tue, 19 Feb 2002, Michael Thaler wrote:
>
> > Unfortunately Unreal is not working. It is loading and running just
> > fine, the menues are displayed correctly but the intro and the game
> > graphics are just rubbish. Has anyone seen that before? I inst
On Wed, Feb 20, 2002 at 01:05:54AM +0100, Malte Cornils wrote:
> Symlinking to the "correct" libGL (in /usr/X11R6-DRI) is almost the
> same as copying it to /usr/lib, it still interferes with the
> distro's packaging system and might not survive the next upgrade (on
> Debian unstable, that mean
Ian Romanick wrote:
>
> On Tue, Feb 19, 2002 at 07:28:54PM +0100, Malte Cornils wrote:
> > Jose Fonseca wrote:
> >
> > > No, there's no need. You probably just have to change the order on which
> > > /usr/lib/ and /usr/X11R6/lib/ directories appear on /etc/ld.so.conf and
> > > run '/sbin/ldconfig
Ian Romanick wrote:
>
> On Tue, Feb 19, 2002 at 04:42:02PM +0100, Timothee Besset wrote:
> > What is the name of the extension? Since it's not implemented in the DRI,
> > I can tell for sure that it's not used on linux, and it's likely not used
> > on win32 either (at least for Q3, the number of
> That's because tunnel tries to use alpha blending _and_ fog, which isn't
> possible on mach64 (we're looking into a workaround though). If you
OK. For a moment, I just will remember this fact.
> > 2. For some reason, X server gets signal 11 after closing any GL
> > program. Is it registered b
Hi Dieter,
Dieter Nützel wrote:
> OK, Allen Akin told you what the LSB standard is:
> libGL* belongs into /usr/lib.
>
> lrwxrwxrwx1 root root 25 Feb 17 01:50 libGL.so.1 ->
> /usr/X11R6/lib/libGL.so.1
> X11R6/lib> l libGL* libglut*
> lrwxrwxrwx1 root root 12
Malte Cornils wrote:
> Leif Delgass wrote:
> > I thought this was done by "make install", I have:
> >
> > % ls -l /usr/lib/libGL*
> > lrwxrwxrwx1 root root 27 Feb 18 19:34 /usr/lib/libGL.so
> > -> /usr/X11R6-DRI/lib/libGL.so
> > lrwxrwxrwx1 root root 29 Feb 18
On 19 Feb 2002, Sergey V. Udaltsov wrote:
> Hi all
>
> Once again, I managed to came through the waters and fires of the
> updating and building process. Again, got DRM working with my humble
> Mobility (at least with glxgears/tunnel).
> There are 2 minor questions:
> 1. After all these discussi
Hi all
Once again, I managed to came through the waters and fires of the
updating and building process. Again, got DRM working with my humble
Mobility (at least with glxgears/tunnel).
There are 2 minor questions:
1. After all these discussions in IRC, I realized that fog in Mach64 is
not ready ye
Leif Delgass wrote:
> I thought this was done by "make install", I have:
>
> % ls -l /usr/lib/libGL*
> lrwxrwxrwx1 root root 27 Feb 18 19:34 /usr/lib/libGL.so
> -> /usr/X11R6-DRI/lib/libGL.so
> lrwxrwxrwx1 root root 29 Feb 18 19:34
> /usr/lib/libGL.so.1 -> /u
Ian Romanick wrote:
>>Any hints how to do it in a better way?
> How about the obvious? Don't put libGL (and friends) in /usr/lib. Always
> put them in /usr/X11*/lib. If you have some other libGL (standalone Mesa,
> perhaps), but it in /usr/local/lib.
Yes, I might do that if it wouldn't greatly
Try rebuilding from the current CVS branch, I commited a fix to make
lightmap lighting work.
On Tue, 19 Feb 2002, David Bronaugh wrote:
> I know that at least in quake3 with my Rage Mobility P/M chip in my
> laptop, lightmap lighting doesn't work. I am not sure if this is peculiar
> to my setu
On Tue, 19 Feb 2002, Michael Thaler wrote:
> Unfortunately Unreal is not working. It is loading and running just
> fine, the menues are displayed correctly but the intro and the game
> graphics are just rubbish. Has anyone seen that before? I installe UT
> from a windows CD with the newest packag
I know that at least in quake3 with my Rage Mobility P/M chip in my
laptop, lightmap lighting doesn't work. I am not sure if this is peculiar
to my setup (I just thought, hey, it's a crappy old chip) but it might be
relevant to the UT problem (I think UT is big on lightmap lighting).
David Bro
On Tue, Feb 19, 2002 at 07:20:13PM +, Jose Fonseca wrote:
> > Thank you for all your efforts to get the Mach64 driver working. I
>
> Finally... :-)
I think you made a lot of laptop guys happy:-))
> Yes. I manage to run Unreal with a 4 Mb ATI Rage Mobility. You really
Is the intro displaye
On Tue, Feb 19, 2002 at 07:02:47PM +, Jose Fonseca wrote:
> Michael, please try to copy the glxinfo & glxgears binaries to other
> place and run them from there.
Jose, I copied glxinfo and glxgears from /usr/X11R6 to /root and tried it
with /root/glxinfo and /root/glxgears and it still uses
On Tue, 2002-02-19 at 18:51, Michael Thaler wrote:
> On Tue, Feb 19, 2002 at 05:17:16PM +, Jose Fonseca wrote:
>
> > No, there's no need. You probably just have to change the order on which
> > /usr/lib/ and /usr/X11R6/lib/ directories appear on /etc/ld.so.conf and
> > run '/sbin/ldconfig'
>
On Tue, Feb 19, 2002 at 11:05:08AM -0800, Ian Romanick wrote:
|
| How about the obvious? Don't put libGL (and friends) in /usr/lib.
The Linux OpenGL ABI standard requires that libGL and libGLU be in
/usr/lib. Obviously a lot of applications will work even if that's not
true, but some apps, Mak
On Tue, 19 Feb 2002, Malte Cornils wrote:
> Jose Fonseca wrote:
> >>mthaler:~# ldd /usr/X11R6/bin/glxinfo
> >>libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0x4009c000)
> >>where quake3 probably uses the libGL from /usr/lib/
> >>lrwxrwxrwx1 root root 31 19. Feb 12:11 /usr/lib
On Tue, Feb 19, 2002 at 07:28:54PM +0100, Malte Cornils wrote:
> Jose Fonseca wrote:
>
> > No, there's no need. You probably just have to change the order on which
> > /usr/lib/ and /usr/X11R6/lib/ directories appear on /etc/ld.so.conf and
> > run '/sbin/ldconfig'
>
> Unfortunately, /usr/lib is
On Tue, Feb 19, 2002 at 03:35:45PM +0100, Koen Kooi wrote:
> Most of my problems were solved when disabling the framebuffer:
How can you do that?
Greetings,
Michael
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/list
On Tue, Feb 19, 2002 at 05:17:16PM +, Jose Fonseca wrote:
> No, there's no need. You probably just have to change the order on which
> /usr/lib/ and /usr/X11R6/lib/ directories appear on /etc/ld.so.conf and
> run '/sbin/ldconfig'
I just symlinked the libGL and the libGLU in /usr/X11R6/lib to
On Tue, 2002-02-19 at 18:28, Malte Cornils wrote:
> Jose Fonseca wrote:
> >>mthaler:~# ldd /usr/X11R6/bin/glxinfo
> >>libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0x4009c000)
> >>where quake3 probably uses the libGL from /usr/lib/
> >>lrwxrwxrwx1 root root 31 19. Feb 12:11 /
Jose Fonseca wrote:
>>mthaler:~# ldd /usr/X11R6/bin/glxinfo
>>libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0x4009c000)
>>where quake3 probably uses the libGL from /usr/lib/
>>lrwxrwxrwx1 root root 31 19. Feb 12:11 /usr/lib/libGL.so.1.2 ->
>/usr/X11R6-DRI/lib/libGL.so.1.2
No, Q3 and RTCW use TMU 0 and 1 only. I see some commented out code in
RTCW that is supposed to do some dynamic lighting on the third TMU if
available. Otherwise everything's pretty much hardcoded on 0 and 1.
TTimo
On Tue, 19 Feb 2002 09:51:27 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
> On
On Tue, Feb 19, 2002 at 04:42:02PM +0100, Timothee Besset wrote:
> What is the name of the extension? Since it's not implemented in the DRI,
> I can tell for sure that it's not used on linux, and it's likely not used
> on win32 either (at least for Q3, the number of extensions used was
> restricte
On Tue, 2002-02-19 at 16:40, Michael Thaler wrote:
> On Tue, Feb 19, 2002 at 03:13:39PM +, José Fonseca wrote:
>
> > The only explanation I see is that glxinfo is not picking up the correct
> > libGL.so. Since this issue can came back to haunt you later, please do
> > 'ldd /usr/X11R6/bin/gl
On Tue, Feb 19, 2002 at 03:13:39PM +, José Fonseca wrote:
> The only explanation I see is that glxinfo is not picking up the correct
> libGL.so. Since this issue can came back to haunt you later, please do
> 'ldd /usr/X11R6/bin/glxinfo' and also 'ldd /usr/X11R6/bin/glxgears' (paths
> may v
"Frank C. Earl" wrote:
>
> On Monday 18 February 2002 10:35 pm, Keith Whitwell wrote:
>
> > The rings are in agp space. It's a bug in the security model of the i810,
> > it's arcane, but believe me it's real.
>
> Which leaves it open to attack because the AGP space isn't covered by the
> prote
On Wed, Feb 20, 2002 at 02:13:17AM +1100, Simon Fowler wrote:
> Loading the radeon.o module with the debug option enabled dumps a
> load of gunk all over my /var/log/kern.log file . . . It overwrites
> the file way before the point where it would have started writing,
> so something strange is hap
On Tue, 2002-02-19 at 15:35, Koen Kooi wrote:
>
> Most of my problems were solved when disabling the framebuffer:
The framebuffer is the memory on the video card, so what exactly have
you disabled? :)
> [...]
> (WW) ATI(0): Cannot shadow an accelerated frame buffer.
> [...]
Isn't this a perfec
What is the name of the extension? Since it's not implemented in the DRI,
I can tell for sure that it's not used on linux, and it's likely not used
on win32 either (at least for Q3, the number of extensions used was
restricted to only the major ones).
One thing that RTCW uses on win32/ATI though,
>
>
>mthaler:~# glxinfo
>name of display: :0.0
>display: :0 screen: 0
>direct rendering: No
>server glx vendor string: SGI
>server glx version string: 1.2
>server glx extensions:
>
Try running glxinfo with LIBGL debugging enabled (LIBGL_DEBUG=verbose
glxinfo), that might help to trace the proble
José Fonseca wrote:
>
> On 2002.02.19 14:36 Michael Thaler wrote:
> > On Tue, Feb 19, 2002 at 03:10:19PM +0100, R. Reucher wrote:
> >
> > ...
> > (II) ATI(0): Direct rendering enabled
> >
> > It definitely says direct rendering is enabled!
> >
>
> Yes. That's is definitely true.
>
> > ...
> >
>
On Monday 18 February 2002 10:35 pm, Keith Whitwell wrote:
> The rings are in agp space. It's a bug in the security model of the i810,
> it's arcane, but believe me it's real.
Which leaves it open to attack because the AGP space isn't covered by the
protection system. Got to wonder what they
On 2002.02.19 14:36 Michael Thaler wrote:
> On Tue, Feb 19, 2002 at 03:10:19PM +0100, R. Reucher wrote:
>
> ...
> (II) ATI(0): Direct rendering enabled
>
> It definitely says direct rendering is enabled!
>
Yes. That's is definitely true.
> ...
>
> I still get:
>
> mthaler:~# glxinfo
> name
On Tue, Feb 19, 2002 at 10:01:52AM +0100, Timothee Besset wrote:
> A quick note:
>
> When you guys encounter bugs with DRI drivers on Id games, you can
> certainly get some help from me :-)
Then perhaps you can answer this question for us. Do either Q3 or RtCW use
the 3rd texture unit on Radeon
Having recently installed and got running an original Radeon QD
card, I've discovered a simple and reliable way to lock the card up:
I run the xscreensaver-demo version of gears with -delay 0 -fps
-wireframe. I've seen the same lockup with flightgear once, with one
of the fastest aircraft, and now
On Tuesday 19 February 2002 15:36, Michael Thaler wrote:
> (II) ATI(0): Direct rendering enabled
>
> It definitely says direct rendering is enabled!
Ok, then it's working correctly ! Sorry for any confusion caused by me :-)...
> > Hmmm, this might just be caused by the less color bits you're usin
Hello,
Most of my problems were solved when disabling the framebuffer:
[...]
(WW) ATI(0): Cannot shadow an accelerated frame buffer.
[...]
This helps both on GATOS (2d) and DRI (3d). I have an ATI RAGE XL
(onboard tyan S2462) with 4MB, so things may work different on your sys.
I hope this helps
On Tue, Feb 19, 2002 at 03:10:19PM +0100, R. Reucher wrote:
> Then it's still not working correctly ! Please look at your XFree86.0.log
> again and search for "direct rendering" !!!
(II) ATI(0): [drm] created "mach64" driver at busid "PCI:1:0:0"
(II) ATI(0): [drm] added 4096 byte SAREA at 0xc88
On Tuesday 19 February 2002 14:48, Michael Thaler wrote:
> On Tue, Feb 19, 2002 at 02:00:54PM +0100, R. Reucher wrote:
>
> Thank you very much! Now I get:
>
> mthaler:~# lsmod
> Module Size Used byNot tainted
> mach64 71544 1
>
> but glxinfo still shows:
>
>
On Tue, Feb 19, 2002 at 02:00:54PM +0100, R. Reucher wrote:
Thank you very much! Now I get:
mthaler:~# lsmod
Module Size Used byNot tainted
mach64 71544 1
but glxinfo still shows:
mthaler:~# glxinfo
name of display: :0.0
display: :0 screen: 0
direct re
I don't have a Mach64 chipset but looked at the attached files...
You seem to get out of video memory, starting X at a lower depth might help
(16bpp, that is) !
>From your X log:
...
(WW) ATI(0): DRI static buffer allocation failed -- need at least 9216 kB
video memory
(II) ATI(0): Using XFre
On Tue, Feb 19, 2002 at 10:44:43AM +, José Fonseca wrote:
> Please check:
> - if /usr/lib/libGL.so.1 is pointing to /usr/X11R6-DRI/lib/libGL.so.
lrwxrwxrwx1 root root 10 19. Feb 12:17 /usr/lib/libGL.so ->
libGL.so.1
lrwxrwxrwx1 root root 12 19. Feb 12:17
On 2002.02.19 10:14 Michael Thaler wrote:
> Hi,
>
> I compiled the mac64 driver following Leifs excellent mini-HOWTO. I
> did not find any errors after compiling in world.log. I installed
> XFree86 to /usr/X11R6-DRI, inserted mach64.o with insmod (I have
> agpgart compiled into the kernel) and st
Hi,
I compiled the mac64 driver following Leifs excellent mini-HOWTO. I
did not find any errors after compiling in world.log. I installed
XFree86 to /usr/X11R6-DRI, inserted mach64.o with insmod (I have
agpgart compiled into the kernel) and started X with
/usr/X11R6-DRI/bin/X which worked fine. I
On 2002.02.19 03:21 Daryll Strauss wrote:
> On Mon, Feb 18, 2002 at 06:50:36PM -0800, Gareth Hughes wrote:
> > Sergey V. Udaltsov wrote:
> > > ...
> > > The main point of this letter: could someone please consider the
> > > possibility of periodical publishing mach64.tar.gz using the method
> of
>
On Tue, Feb 19, 2002 at 08:31:03AM +0100, Peter Surda wrote:
> > If the CPU usage is really a problem, an interrupt is probably the way
> > to go; don't know if and how the chip supports that though.
> Sounds good.
Ok, I did some tests:
- it isn't DMA-specific. It happens also with DMA disabled, s
A quick note:
When you guys encounter bugs with DRI drivers on Id games, you can
certainly get some help from me :-)
I can look at the code and tell you how some things are done, and correct
problems if any. You shouldn't expect me to become a direct contributor to
DRI developement though, low l
61 matches
Mail list logo
