On Thu, Oct 24, 2002 at 03:59:35PM +0200, Michel Dänzer wrote:
> IMHO the best thing would be to educate users about
> /lib/modules/`uname -r`/build .
So, how about a "Please put a symbolic link to the location of your kernel
build tree under /lib/modules/"`uname -r`"/build" if that file doesn't y
On Thu, Oct 24, 2002 at 09:10:01AM +0100, Keith Whitwell wrote:
> >http://studsun1.ira.uka.de/~s_malte/nwn_tcl.png
> >http://studsun1.ira.uka.de/~s_malte/nwn.png
>
>
> Hmm. Looks like depth fighting, but that doesn't make much sense as I
> wouldn't expect there to be multipass rendering going o
On Thu, Oct 24, 2002 at 01:31:14AM +0200, Malte Cornils wrote:
> Is there any way I could help in a different way, maybe you could guess
> something after looking at a screenshot? If you supply a patch, I promise
> I'll test it, of course. With TCL it's way faster :-)
B
On Wed, Oct 23, 2002 at 07:54:26AM +0100, Keith Whitwell wrote:
> environment variables: 'R200_NO_VTXFMT' and 'R200_NO_TCL' are the big ones.
The latter one fixed the problems. See other mail in thread.
> Beyond that, you will have to look at the code. I'd recommend especially
> looking at the
On Wed, Oct 23, 2002 at 01:27:24AM +0200, Felix Kühling wrote:
> On Wed, 23 Oct 2002 00:37:47 +0200
> Malte Cornils <[EMAIL PROTECTED]> wrote:
> > I'm having a visual problem with an application (NWN under Wine) - it works
> > fine with LIBGL_ALWAYS_INDIRECT=true b
Hi,
I'm having a visual problem with an application (NWN under Wine) - it works
fine with LIBGL_ALWAYS_INDIRECT=true but displays the problem (some textures
flicker and show wrong colours) with hardware-accelerated r200.
How can I selectively disable/enable hardware acceleration for certain
OpenG
Hi,
On Tue, Oct 22, 2002 at 01:07:24PM +0200, Michel Dänzer wrote:
> The gotcha about TREE is that you have to provide the include directory, so
> you'd have to use TREE=/home/mcornils/kernel-source-2.4.18/include in this case.
Errm, is this documented somewhere? Couldn't this be part of the inst
On Mon, Oct 21, 2002 at 08:08:20PM +0200, Benjamin Herrenschmidt wrote:
> >[using /usr/include/linux etc symlinks]
> >Worked for ages.
>
> Well, maybe, but it has always been the wrong thing to do,
> at least according to Linus, and this have been more of
> a problem with recent kernels. Some reas
On Sun, Oct 06, 2002 at 08:07:41PM +0200, Michel Dänzer wrote:
> > BTW, how do I get a backtrace of this? get a statically-linked xserver
> > binary, run that under gdb?
>
> Assuming that this is some sort of binary incompatibility, a static
> build won't exhibit the problem (neither will a full
On Sun, Oct 06, 2002 at 04:39:23PM +0200, Michel Dänzer wrote:
> > and get a blank screen - the monitor loses signal - and I can't switch back
> > to the console. C-M-del helps, though.
>
> That means you _are_ on console, it's just not visible. ;)
> > (==) RADEON(0): Silken mouse enabled
> Hmm,
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
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
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
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
Manuel Teira wrote:
> Have you got errores related to the glide library?
> Perhaps you should comment out the line:
> #define HasGlide3 YES
> in the host.def file.
> Or perhaps would be good to comment it out in our mach64 branch.
oops. That's likely the problem. I got so used to configure-like
s
Manuel Teira wrote:
> If you find any problem compiling the new branch, please make me know.
OK, let me see. With regards to that libXau problem: it
's sufficient to just copy /usr/X11R6/lib to /usr/X11R6-DRI/lib, the
rest of the tree isn't necessary. Otherwise, I followed the DRI
compilation gui
[EMAIL PROTECTED] wrote:
> > /usr/bin/ld: cannot find -lXau
> [...]
> Perhaps the fastest solution is copying the /usr/X11R6 to the
> /usr/X11R6-DRI directory to avoid this compilation problems. Then, the
> installation will overwrite the important stuff.
I'm currently trying to compile this, too
Jens-Peter Konrath wrote:
> Hi!
> Is the ATI Rage Pro supported by DRI? I noticed that there is a
> mach64*-branch in the cvs repository. Is it of any use?
For the support question see the list archives, the recent disussion
covers it up quite well. The Mach64 branch tagged to 20th of
December (t
[EMAIL PROTECTED] wrote:
> I have a Intel STL2 mainboard, with integrated Ati Rage 3D IIC video card.
> Card is not AGP slotted, it is PCI (integrated) card.
IIRC, PCI is not the problem, but the Rage IIC is so old that it's
not very useful as a 3D accelerator anyway and there never was and
proba
Carl Busjahn wrote:
> Hey,
> I have mach64 (or technically rage pro! why'd he call it mach64??) in my
> desktop, and I will be getting a k6-2 550 tomarrow so I'll have a better
> test platform (with kernel.org messing up cyrix arr, and 3dnow so
> essential...). I've actually had the code working
Manuel Teira wrote:
> Hello. Once again I try to get any answer about Mach64 DRI development.
> Is there any work in progress? Is the development for the Mach64 dead?
Having heard no sign of those who expressed an interest in pursuing
development themselves on this list, and the original author n
22 matches
Mail list logo
