> Please do the following tasks via telnet and report back to the list:
> - Copy the Xfree86.0.log to a safe place and post it here.
Its attatched to this email.
>
> - Check if X is still running or not (ps -A | grep X) and point down
> it's pid, and if it is do:
>- do "gdb "
>-
Since my last reply that Yahoo hasn't delivering emails to me and I'm not
sure if you'll receive this one or not either. To make things even worse
I'll be away for the next couple days and I don't expect to be able to
check my mail.
I just read some of the replies in the list archive and it se
On Wed, Apr 24, 2002 at 03:24:17PM -0400, Leif Delgass wrote:
> I was looking at the code in glint_dri.c to add the page table thinking
> that we could set the DRM_RESTRICTED flag for the descriptor table as is
> done there. However, in looking at drmAddBufs and the ioctl, the last arg
> is the a
On Wednesday 24 April 2002 11:31 am, Leif Delgass wrote:
> I know you need to flag the final descriptor at the end of the pass by
> setting END_OF_LIST_STATUS in BM_COMMAND (third dword of the descriptor).
> In Utah-glx, there's also a series of register writes added to end of the
> buffer to "go
On Wednesday 24 April 2002 11:32 am, you wrote:
> Regardless of security concerns, the idea was to use this primary buffer
> for storing the state update emitted from the DRM. The first entry of
> the descriptor table would point to this primary buffer, and the
> followings to the client submitte
Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00E7_14E65D2E.D7854E83"
On 24 Apr 2002, Jose Fonseca wrote:
> On Wed, 2002-04-24 at 14:13, Jens Owen wrote:
> > ...
> >
> > Jose,
> >
> > I don't have a complete answer for you, but here is *some* background
> > information that might help.
> >
> > The drmAddBufs style was created with the origianal DRI infrastructur
On 2002.04.24 19:36 Peter Andersson wrote:
>>
>>
>> Please supply more information about the failure. Is there any message
>> on the system log (usually /var/log/messages). Can you access the
>> computer trhu network after the hang?
>>
> Yes, i can access the computer after the hang, via telnet
Ian Romanick wrote:
>
> On Tue, Apr 23, 2002 at 12:49:20AM +0100, Keith Whitwell wrote:
>
> > Well, you're doing something you're not supposed to do & as a result
> > glXGetProcAddress isn't working right.
> >
> > Do you really need to call your symbol glBegin? How about xyzBegin or
> > similar
Ian Romanick wrote:
>
> On Tue, Apr 23, 2002 at 12:49:20AM +0100, Keith Whitwell wrote:
>
> > Well, you're doing something you're not supposed to do & as a result
> > glXGetProcAddress isn't working right.
> >
> > Do you really need to call your symbol glBegin? How about xyzBegin or
> > similar
Alan Hourihane wrote:
>
> On Wed, Apr 24, 2002 at 12:19:25PM -0600, Jens Owen wrote:
> > Alan,
> >
> > Mike Mestnik has kindly volunteered to get the 4.2 DRM modules submitted
> > to the Linux kernel. I'd forgotten about the tar ball you have on your
> > XFree86 page. Do you know if anybody is
>
>
>Please supply more information about the failure. Is there any message
>on the system log (usually /var/log/messages). Can you access the
>computer trhu network after the hang?
>
Yes, i can access the computer after the hang, via telnet and ftp.
Although i cannot shut down the computer via t
On 2002.04.24 19:09 Jens Owen wrote:
> ...
>
> Jose,
>
> I recall hearing that having an AGP vs. PCI bus connection is
> independent of whether you can use the GART functionality or not.
> Something along the lines of it's possible to plug a Rage128 into a PCI
> slot and still have the page mapp
On Wed, Apr 24, 2002 at 12:19:25PM -0600, Jens Owen wrote:
> Alan,
>
> Mike Mestnik has kindly volunteered to get the 4.2 DRM modules submitted
> to the Linux kernel. I'd forgotten about the tar ball you have on your
> XFree86 page. Do you know if anybody is already working on this--I'm
> just
Alan,
Mike Mestnik has kindly volunteered to get the 4.2 DRM modules submitted
to the Linux kernel. I'd forgotten about the tar ball you have on your
XFree86 page. Do you know if anybody is already working on this--I'm
just trying to make sure we don't duplicate effort.
Mike Mestnik wrote:
>
It would seem that Ian Romanick ([EMAIL PROTECTED]) said:
> Doing a quick check on eBay found PCI G200 (and older!) cards, but no G400+
> cards. It also turned up a couple Savage4 PCI cards, a Trident Blade3D
> card, and an SiS 6326 card. The other question, that may be more difficult
> to answe
Jose Fonseca wrote:
>
> On Wed, 2002-04-24 at 14:13, Jens Owen wrote:
> > I believe the r128 driver's PCI support still utilizes GART
> > functionality to allow non-contiguous memory to be utilized. Your
> > driver may be the first to need true PCI support, and *possibly* the
> > last to need i
On Wed, 2002-04-24 at 18:33, Peter Andersson wrote:
> I have applied the patch and recompiled the entire "dri tree" and still
This is not necessary. Once you build it once, you just need to go the
directory where the change was and make
make
su -c "make install"
unless it's in the kernel dir
On Wed, Apr 24, 2002 at 06:42:21PM +0100, Jose Fonseca wrote:
> On Wed, 2002-04-24 at 14:13, Jens Owen wrote:
> > I believe the r128 driver's PCI support still utilizes GART
> > functionality to allow non-contiguous memory to be utilized. Your
> > driver may be the first to need true PCI support,
On Wed, 2002-04-24 at 14:13, Jens Owen wrote:
> ...
>
> Jose,
>
> I don't have a complete answer for you, but here is *some* background
> information that might help.
>
> The drmAddBufs style was created with the origianal DRI infrastructure
> that supported a partial implementation of the Gamm
I have applied the patch and recompiled the entire "dri tree" and still
experience the same problems, eg the computer hangs when i try to use
open gl applications. Could this be a result of the program trying to
use the "xv" display method? As i have understood there are no hardware
accelerate
On Tue, Apr 23, 2002 at 12:49:20AM +0100, Keith Whitwell wrote:
> Well, you're doing something you're not supposed to do & as a result
> glXGetProcAddress isn't working right.
>
> Do you really need to call your symbol glBegin? How about xyzBegin or
> similar?
I have managed to solve this prob
On Wed, 2002-04-24 at 16:49, Frank C.Earl wrote:
> On Wednesday 24 April 2002 06:15 am, you wrote:
>
> Hi, there!
>
> > For enabling DMA on Mach64 I'll need to allocate two extra DMA buffers: a
> > primary DMA buffer and a decription table buffer.
>
> All you need for now is a descriptor table.
On Wed, 24 Apr 2002, Frank C. Earl wrote:
> On Wednesday 24 April 2002 06:15 am, you wrote:
>
> Hi, there!
>
> > For enabling DMA on Mach64 I'll need to allocate two extra DMA buffers: a
> > primary DMA buffer and a decription table buffer.
>
> All you need for now is a descriptor table. The
On Wednesday 24 April 2002 06:15 am, you wrote:
Hi, there!
> For enabling DMA on Mach64 I'll need to allocate two extra DMA buffers: a
> primary DMA buffer and a decription table buffer.
All you need for now is a descriptor table. The buffers that you have
already allocated via the DRM's fram
I haven't had much chance to do testing recently, but hopefully tonight.
What I have noticed so far (with a Radeon 7500):
There are still some rendering anamolies with tuxracer (which I
believe someone else also mentioned). Namely, the ice is very blocky.
Gltron has some issu
"José Fonseca" wrote:
>
> For enabling DMA on Mach64 I'll need to allocate two extra DMA buffers: a
> primary DMA buffer and a decription table buffer.
>
> The way most cards (R128,MGA) do this is to map (on the DDX) pieces of AGP
> memory for these extra buffers, but this isn't possible with PC
On Tue, 2002-04-23 at 19:27, Jens Owen wrote:
>
> BTW, does anyone know what the dri-4.0 modules are used for? They are
> seriously out of date.
I think they're intended for use with XFree86 4.0.x where we broke
backwards compatibility.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linu
On Wed, 2002-04-24 at 12:57, Peter Andersson wrote:
> >
> >Anyway, MACH64_{READ,WRITE} will likely have to be changed to use
> >{in,out}_le32 (in mach64_drv.h) for it to work on PPC.
>
> You are probably right here because although the driver is loaded it
> hangs when i try to use OpenGL applica
On 2002.04.24 12:41 Michel Dänzer wrote:
> On Wed, 2002-04-24 at 10:52, José Fonseca wrote:
> > On 2002.04.24 09:34 Michel Dänzer wrote:
> > > ...
> > >
> > > Anyway, MACH64_{READ,WRITE} will likely have to be changed to use
> > > {in,out}_le32 (in mach64_drv.h) for it to work on PPC.
> > >
> >
>
On Wed, 2002-04-24 at 10:52, José Fonseca wrote:
> On 2002.04.24 09:34 Michel Dänzer wrote:
> > ...
> >
> > Anyway, MACH64_{READ,WRITE} will likely have to be changed to use
> > {in,out}_le32 (in mach64_drv.h) for it to work on PPC.
> >
>
> As Peter managed to get everything to compile, yesterd
For enabling DMA on Mach64 I'll need to allocate two extra DMA buffers: a
primary DMA buffer and a decription table buffer.
The way most cards (R128,MGA) do this is to map (on the DDX) pieces of AGP
memory for these extra buffers, but this isn't possible with PCI only
cards (i.e., without AGP/
>
>
>
>Anyway, MACH64_{READ,WRITE} will likely have to be changed to use
>{in,out}_le32 (in mach64_drv.h) for it to work on PPC.
>
You are probably right here because although the driver is loaded it
hangs when i try to use OpenGL applications, so far i have only tried
games prboom (doom clone)
Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00B7_82D15B6B.D0134E60"
On 2002.04.24 09:34 Michel Dänzer wrote:
> ...
>
> Anyway, MACH64_{READ,WRITE} will likely have to be changed to use
> {in,out}_le32 (in mach64_drv.h) for it to work on PPC.
>
As Peter managed to get everything to compile, yesterday I was looking
into this but when looking at r128_drv.h but it
On Wed, 2002-04-24 at 07:44, Peter Andersson wrote:
>
> The second problem is that the kernel identifies my graphicsboard as pci
> while it is in fact agp. This might be due to a problem i had while
> compiling the kernel, agpgart didn´t know what to do with "flush_cache"
> for ppc so i had to
On 2002.04.24 07:06 Felix Kühling wrote:
> On Wed, 24 Apr 2002 07:44:59 +0200
> Peter Andersson <[EMAIL PROTECTED]> wrote:
>
> > Okey, i think i have located some of the problems one is that there
> > only are 4mb of sdram on my Mach64 graphics board and that the driver
> > requests:
> >
> > (WW
>
>
>
>I looked at your XFree86-log. It says you're using 32 bit color depth.
>Try 16. That will reduce the amount of memory used by 2d and also
>increase 3d performance a lot.
>
You are so right! I set the resolution to 16 bit and everything worked
as it should! I now have hardware accalerated 3
38 matches
Mail list logo
