On Wed, 2002-06-26 at 23:50, Jens Owen wrote:
For the drivers you've ported to your OS independent templates (radeon,
r128 and mga), it looks like the *_drv.c and Makefile support are all
that's left in the OS directories. If you can get these out of there,
even by adding a few OS ifdefs
German Gomez Garcia wrote:
Hello, I have some money to spend (finally!!!) so I'm thinking
of replacing my old G400MAX for a new card, as I prefer open source, I
have to choose between ATI and Matrox, and the optios (for me) are
the new Parhelia 512 or the AIW Radeon 8500 DV, I'll buy
I've tried to use remote debugging and got the backtrace of the SIGSEVG:
Program received signal SIGSEGV, Segmentation fault.
0x0841e74e in ?? ()
(gdb) bt
#0 0x0841e74e in ?? ()
#1 0x083fbca7 in ?? ()
#2 0x083198bb in ?? ()
#3 0x080b7e05 in ProcCopyArea ()
#4 0x080b58d7 in Dispatch ()
#5
On Thu, Jun 27, 2002 at 11:54:53AM +0200, Massimiliano Lingua wrote:
[...]
3) Did you set backbuffer size and texsize in XF86Config like I
suggested in the README?
Max, where can I find that README? I would like to put it in the same
place as the binary snapshots.
José Fonseca
The problem is that stock gdb doesn't know about XFree86 modules. There
are patched versions of gdb for that, but even so you can get more
information by calling the LoaderPrintSymbol function for each of the
addresses before a '??', i.e. at the gdb prompt:
call
Hi,
Just wanted to say that I got my Radeon 8500 today (off ebay), to
replace a G400 (seems to be a common combination then?).
Radeon8500:
2D is supported, including working XVideo provided by the Gatos-project,
I only had to upgrade to XFree86 4.2.0 to get anything
working... Haven't
The output went into the /var/log/XFree86.0.log (or to the console where
you started the X server), not to the GDB screen.
Yes!!! What I got:
0x841eb84 ATIMach64SetDPMSMode+46a
Module /usr/X11R6/lib/modules/drivers/atimisc_drv.o
Section .text
0x83fa220 XAA+21cf
Module
On Thu, Jun 27, 2002 at 05:26:37PM +0100, Sergey V. Udaltsov wrote:
The output went into the /var/log/XFree86.0.log (or to the console where
you started the X server), not to the GDB screen.
Yes!!! What I got:
0x841eb84 ATIMach64SetDPMSMode+46a
Module
Might want to post this on the site somewhere - appears that utah-glx
has posted specs for some SiS chipsets (300 630).
http://prdownloads.sourceforge.net/utah-glx/300ds03.pdf?download
http://prdownloads.sourceforge.net/utah-glx/630ds10a.pdf?download
-Al
Eric,
Just trying to compile this under linux. Does this look familiar? I couldn't
really see where it was coming from.
I've just tried to insert the bsd-3-0-0-branch os-support directory into my
trunk tree. Maybe that's too ambitious...
Keith
On Thu, 2002-06-27 at 13:14, Keith Whitwell wrote:
Eric,
Just trying to compile this under linux. Does this look familiar? I couldn't
really see where it was coming from.
I've just tried to insert the bsd-3-0-0-branch os-support directory into my
trunk tree. Maybe that's too
Well, I've got most of the FreeBSD troubles straightened out I think. I
went ahead and did some glxgears benchmarks, waiting for the numbers to
stabilize, of gentoo vs freebsd-current.
System is a 128MB 2xCeleron517 (BP6, OCed), diskless, booting gentoo or
-current off of a -current system.
Eric Anholt wrote:
Well, I've got most of the FreeBSD troubles straightened out I think. I
went ahead and did some glxgears benchmarks, waiting for the numbers to
stabilize, of gentoo vs freebsd-current.
System is a 128MB 2xCeleron517 (BP6, OCed), diskless, booting gentoo or
-current off
Keith Whitwell wrote:
Eric Anholt wrote:
Well, I've got most of the FreeBSD troubles straightened out I think. I
went ahead and did some glxgears benchmarks, waiting for the numbers to
stabilize, of gentoo vs freebsd-current.
System is a 128MB 2xCeleron517 (BP6, OCed),
I don't think the docs are much help with regard to 3D. there actually
is a working sis DRI driver for 300 series chips that can be found
here:
http://www.winischhofer.net/linuxsis630.shtml
perhaps it could be synced up to the current DRI tree.
Alex
Might want to post
OK, mach64-0-0-5-branch is open for your hacking and testing pleasure!
The trunk as of June 26 is merged in, so we now have Mesa 4.0.3 and I've
converted the mach64 driver to the drmCommand interface. The branch
compiles and works fine, and as a bonus, the bug with clears in the first
GL
Leif Delgass wrote:
OK, mach64-0-0-5-branch is open for your hacking and testing pleasure! The
trunk as of June 26 is merged in, so we now have Mesa 4.0.3 and I've converted
the mach64 driver to the drmCommand interface. The branch compiles and works
fine, and as a bonus, the bug with
On Thu, Jun 27, 2002 at 04:35:16PM -0600, Brian Paul wrote:
[...]
Just curious: do you guys have a plan for moving the mach64 code into the
trunk? Are there any major issues that need to be resolved first?
In my perspective the major issues missing are:
1. Make sure the new DMA model works
18 matches
Mail list logo
