On Fri, 28 Jun 2002, José Fonseca wrote:
> 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 majo
Alex Deucher wrote:
> 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,
Somebod
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
On Thu, Jun 27, 2002 at 06:12:53PM -0400, Leif Delgass wrote:
>OK, mach64-0-0-5-branch is open for your hacking and testing pleasure!
Great Leif!
>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
>c
On Thu, 2002-06-27 at 15:46, Keith Whitwell wrote:
> So, instead of DRM_OS_COPYFROMUSR_NC, maybe DRM_COPY_FROM_USER_UNCHECKED
> might be clearer.
>
> Similarly, DRM_OS_KRNFROMUSR is pretty cryptic -- maybe
> DRM_COPY_FROM_USER_IOCTL or something?
>
> Oh, and I just found DRM_OS_FETCHU_32_NC --
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
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 con
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 th
Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00E7_27E61D1D.C6224B00"
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, O
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
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. Vid
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 a
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
--
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
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 "/usr/X11R6/lib/modul
> 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
Mod
On Thu, Jun 27, 2002 at 11:48:40AM +0100, Sergey V. Udaltsov wrote:
> > 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
> > addre
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 tr
> 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 LoaderPrintSymbol(0x08
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
--
On Thu, 2002-06-27 at 10:30, Sergey V. Udaltsov wrote:
> 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 ?? ()
On Thu, 2002-06-27 at 03:38, John J. Tobin wrote:
> No change, it still hard locks the system. I tried the binary snapshot
> too and the kernel modules wouldn't build.
mmm... ; (
> The windows for gears will open and then a section of the lower half of
> the screen becomes corrupted at the loc
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 0x
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
25 matches
Mail list logo
