Re: [Dri-devel] mach64 binaries: do not work

2002-03-12 Thread Sergey V. Udaltsov

 Well.. this can take a few days since I have to get some time to mess with 
 these scripts. Sorry.
Take your time. Stabilizing things after 0-0-3 branching has definitely
much higher priority. It is not a big problem to rebuild these objects.
But - just to make it easier - could you please make i810_dma.c and
i830_dma.c compilable (they give error messages about some wait
identifiers - so I just have to comment out these lines). Is it a result
of not complete merging or what?

 Does the X log says Direct Rendering Enabled or Direct Rendering 
 Disabled?
(II) ATI(0): [drm] installed DRM signal handler
(II) ATI(0): [DRI] installation complete
(II) ATI(0): [drm] Added 128 16384 byte DMA buffers
(II) ATI(0): [drm] Mapped 128 DMA buffers at 0x40c18000
(II) ATI(0): Direct rendering enabled

 If it does says it's enabled then the problem is related with libGL.so 
 somehow. If it doesn't then it's related to the kernel module / X.
I am pretty confident it is libGL. But the version used by glxinfo is
/usr/X11R6/lib/libGL.so.1.2

Any ideas?

Regards,

Sergey

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] mach64 binaries: do not work

2002-03-12 Thread Sergey V. Udaltsov

 make -f Makefile.linux mach64.o
Thanks. I did not know. I just did make

I just noticed the error about dynamic loading: libGL cannot load
/usr/X11R6-DRI/lib/modules/dri/mach64_dri.so. I think it is the error in
your build scripts. They should use X11R6 directory instead, arent'
they? After I created the link from X11R6 to X11R6-DRI - everything is
fine (more or less, to the current state of the driver). 

Thanks for the help.

Cheers,

Sergey

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] mach64 binaries: do not work

2002-03-12 Thread José Fonseca

On 2002.03.12 11:18 Sergey V. Udaltsov wrote:
  make -f Makefile.linux mach64.o
 Thanks. I did not know. I just did make
 

There is a problem in the i8x0 modules source with the most recent 
kernels. I already had received a report of this problem which I forwarded 
to this list, since it's really outside of my competence to fix it.

 I just noticed the error about dynamic loading: libGL cannot load
 /usr/X11R6-DRI/lib/modules/dri/mach64_dri.so. I think it is the error in
 your build scripts. They should use X11R6 directory instead, arent'
 they? After I created the link from X11R6 to X11R6-DRI - everything is
 fine (more or less, to the current state of the driver).
 

Yes, libGL should be using /usr/X11R6 indeed. I'm going to take libGL out 
of binary packages, as Jens did, so that this problem is no longer an 
issue.

 Thanks for the help.
 
 Cheers,
 
 Sergey
 

José Fonseca

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] mach64 binaries: do not work

2002-03-11 Thread Sergey V. Udaltsov

Hi all

There are problems with the bleeding edge binaries:
1. First of all, the kernel module cannot be loaded because of some
unresolved symbols. And even when I do rm *.o, make, the resulting
mach64.o has some unresolved symbols (on depmod)! I do not know how it
is possible. insmod -f manages to load this bad module, but I do not
know how...

2. Well, I run updated X but glxinfo shows there is no DR - and the
driver is usual mesa:( Ldd informs me about correct libGL and libGLU
used for glxinfo. Any ideas? In X log, I do not see any errors reportes
- it seems DRI is loaded as necessary

Cheers,

Sergey



___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] mach64 binaries: do not work

2002-03-11 Thread Jose Fonseca

On Mon, 2002-03-11 at 14:37, Sergey V. Udaltsov wrote:
 Hi all
 
 There are problems with the bleeding edge binaries:
 1. First of all, the kernel module cannot be loaded because of some
 unresolved symbols. And even when I do rm *.o, make, the resulting

The .o shouldn't be packaged, or even built. I'll have to check why this
is happening.

 mach64.o has some unresolved symbols (on depmod)! I do not know how it
 is possible. insmod -f manages to load this bad module, but I do not
 know how...
 

hmm.. this could be caused for having a kernel source tree
(/usr/src/linux-2.4) that doesn't match your installed kernel
configuration. I also experienced this in RHL 7.2 with unrelated kernel
modules and the only way I found to overcome was to build a new kernel
from the sources and use it.

Could you please past the output of insmod to see what are the failed
symbols?

 2. Well, I run updated X but glxinfo shows there is no DR - and the
 driver is usual mesa:( Ldd informs me about correct libGL and libGLU
 used for glxinfo. Any ideas? In X log, I do not see any errors reportes
 - it seems DRI is loaded as necessary
 

Well, first let's try to figure out the first problem as this second one
could be a side effect.

 Cheers,
 
 Sergey
 

Jose Fonseca



___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] mach64 binaries: do not work

2002-03-11 Thread Sergey V. Udaltsov

 The .o shouldn't be packaged, or even built. I'll have to check why this
 is happening.
Well, hope the next version will be free of these wrong object files.

 Could you please past the output of insmod to see what are the failed
 symbols?
Well, now it is OK. Sorry for disturbing on this issue. For some reason,
it took the old version of mach64.o (bundled with tarball). Now I really
rebuilt it - and still no success in point 2. The module loaded without
problems.

  2. Well, I run updated X but glxinfo shows there is no DR - and the
  driver is usual mesa:( Ldd informs me about correct libGL and libGLU
  used for glxinfo. Any ideas? In X log, I do not see any errors reports
  - it seems DRI is loaded as necessary
So, still same situation... No DR, just Indirect Mesa. Can it be the
problem of XFree 4.2.0 based on old Mesa?

 Well, first let's try to figure out the first problem as this second one
 could be a side effect.
No, it is not... Any other ideas?

Cheers,

Sergey

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel