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
[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
[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 -
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
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
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
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 -
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 recent
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, it
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 build
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 but displays the problem (some textures
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 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 :-)
BTW, I've put up two
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 reasons are
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
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 on here.
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 yet
17 matches
Mail list logo
