On Monday 15 April 2002 12:46 pm, you wrote:
> On Mon, 2002-04-15 at 00:15, Allen H. Ibara wrote:
> > > Hmm. Can you try without AGP? You'll have to rebuild the DRM kernel
> > > module and the 2D driver with the #define PCIGART_ENABLED active for
> > > that to work, and apparently there are other
[Setting Cc to just the dri-devel list; this doesnt seem appropriate
to the utah-glx list.
(particularly since I'm the only solaris developer on it ;-)]
[Note also that I'm not subscribed to dri-devel, though]
On Mon, Apr 15, 2002 at 09:44:39PM -0600, Jens Owen wrote:
> Philip Brown wrote:
> >
Philip Brown wrote:
>
> On Mon, Apr 15, 2002 at 09:19:35PM -0600, Jens Owen wrote:
> > However, I have to point out--that whomever is doing
> > the work get's their way; and since I don't have the bandwidth to
> > support the solaris DRM drivers--that's all I'm going to say, except:
> > If the
Jose,
Was your concern addressed in today's chat?
Jose Fonseca wrote:
>
> I have been looking into the DRM's DMA/CCE/CP initialization subroutines
> (those named *_do_init{dma,cce,cp} ) of the current DRI drivers, and I
> still don't know how they protect themselves from making faults due to
>
Jose Fonseca wrote:
> I still don't understand how it's not worth to work on this but have
> separate equivalent code is. Well, it was just my two cents...
Jose,
I think you're asking the right questions. Personally, if I were
supporting an entire OS, I would prefer to maintain only a varient
On 16 Apr 2002, Michel [ISO-8859-1] Dänzer wrote:
>
> Those affected by the lockups please test this patch against the DRI
> trunk. It puts the DRI block in RADEONEnterVT() back first, where it was
> in XFree86 4.1, which I understand didn't exhibit this problem (right?).
>
>
> --
> Earthling M
On Mon, 15 Apr 2002, Leif Delgass wrote:
> On Tue, 16 Apr 2002, José Fonseca wrote:
>
> > On 2002.04.16 00:39 Felix Kühling wrote:
> > > Sorry, I forgot to redirect standard error to my world.log :(. In fact
> > > the build of mach64_screen.o failed here, too with the same error
> > > messages
On 2002.04.16 01:38 Leif Delgass wrote:
> On Tue, 16 Apr 2002, José Fonseca wrote:
> > ...
> >
> > No. I have the problem too. It's a new structure member that I added to
> > the 2D driver, which compiles fine. I didn't noticed before the effect
> in
> > the 3D driver as well. The R128 has this sa
On Tue, 16 Apr 2002, José Fonseca wrote:
> On 2002.04.16 00:39 Felix Kühling wrote:
> > Sorry, I forgot to redirect standard error to my world.log :(. In fact
> > the build of mach64_screen.o failed here, too with the same error
> > messages.
> >
> >> These kind of problems happen when there s
On 2002.04.16 00:39 Felix Kühling wrote:
> Sorry, I forgot to redirect standard error to my world.log :(. In fact
> the build of mach64_screen.o failed here, too with the same error
> messages.
>
>> These kind of problems happen when there some deep changes in headers
>> (such as the branch as
Sorry, I forgot to redirect standard error to my world.log :(. In fact
the build of mach64_screen.o failed here, too with the same error
messages.
> These kind of problems happen when there some deep changes in headers
> (such as the branch as suffered lately) and you're building on a
> previ
Those affected by the lockups please test this patch against the DRI
trunk. It puts the DRI block in RADEONEnterVT() back first, where it was
in XFree86 4.1, which I understand didn't exhibit this problem (right?).
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFr
On 2002.04.15 23:32 Felix Kühling wrote:
> I just cvs updated my mach64-0-0-3-branch. make ran without problems
> without problems. But make install gave me the following errors:
>
> ...
>
> Then I also tried a clean make World; make install, with the same
> result. I checked the logfile of ma
I just cvs updated my mach64-0-0-3-branch. make ran without problems
without problems. But make install gave me the following errors:
make[5]: Entering directory
`/var/local/src/mach64003/build/xc/lib/GL/mesa/src/drv/mach64'
rm -f mach64_screen.o
gcc -c -O2 -ansi -Wall -Wpointer-arith -Wstrict
#dri-devel on irc.openprojects.net
4:00pm EST (2100 UTC)
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
The chat is on now. Looks like my earlier message hasn't gone through
yet. Trying again...
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Mon, 2002-04-15 at 07:14, Nicholas Leippe wrote:
> > We have massive reports of VT switching hangs in XFree86 4.2.0
> > with almost all Radeon hardware, but with other hardware as well.
> > This problem has occured aparently since the prereleases 4.1.99.*
> > and up through to the final release
Too tired after riding, must sleep... If I'm still up I'll look in briefly...
Keith
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
> > I reported a problem to the gatos list a long while back that
> > I think may be related. (I thought it was strictly a gatos
> > thing, but have no idea, so I'll share it now).
> > I'm running X from cvs (old, but post 4.2.0) on my radeon 64mb.
> > Once I've run _any_ gl app, if I attempt to
Thanks for finding that. You can apply the patch.
Although the cleanup_dma function isn't used at all in the gamma
driver yet (it should be - I know), but the AGP code hasn't been
tested a whole lot either.
Alan.
On Sun, Apr 14, 2002 at 11:00:02 +0100, Jos Fonseca wrote:
> When I found what I b
When I found what I believe to be a bug in gamma DRM which could lead to a
kernel oops on PCI cards.
The line is gamma_dma.c:669:
DRM_IOREMAPFREE( dev_priv->buffers );
but dev_priv->buffers has a non-NULL value only if it's not a PCI card, as
seen in gamma_dma.c:625:
On Mon, 2002-04-15 at 00:15, Allen H. Ibara wrote:
> > Hmm. Can you try without AGP? You'll have to rebuild the DRM kernel
> > module and the 2D driver with the #define PCIGART_ENABLED active for
> > that to work, and apparently there are other instabilities without AGP
> > on i386, so it might b
I have been looking into the DRM's DMA/CCE/CP initialization subroutines
(those named *_do_init{dma,cce,cp} ) of the current DRI drivers, and I
still don't know how they protect themselves from making faults due to
bad initialization parameters. Since I this is a little complicated to
put over IRC
On Mon, 2002-04-15 at 17:46, Philip Brown wrote:
> On Mon, Apr 15, 2002 at 12:35:41PM +0100, Jose Fonseca wrote:
> > I know that main reason for resuming the development of Utah-GLX was the
> > difficulties involved in porting the DRM to others OS, such as Solaris.
> > But why not reuse the DRI's
On Mon, Apr 15, 2002 at 12:35:41PM +0100, Jose Fonseca wrote:
> I know that main reason for resuming the development of Utah-GLX was the
> difficulties involved in porting the DRM to others OS, such as Solaris.
>
> But why not reuse the DRI's Mesa and DXX drivers code and port and/or
> remake a s
Martin Spott wrote:
>
> > If you can ssh in, can you run the program from gdb from a ssh session?
>
> Just to prevent you from thinking I overlooked this posting
> I did a few tries with gdb yesterday but I didn't see the expected result.
> This is to say, 'gdb' was pretty quiet at all, so
On Mon, 2002-04-15 at 14:19, Tony Rogvall wrote:
> "José Fonseca" wrote:
>
> > On 2002.04.13 04:36 Leif Delgass wrote:
> > > On Thu, 11 Apr 2002, José Fonseca wrote:
> > >
> > > Do we know for sure that pci gart is supported on mach64? The rage 128
> > > and radeon drivers both write to PCI GART
"José Fonseca" wrote:
> On 2002.04.13 04:36 Leif Delgass wrote:
> > On Thu, 11 Apr 2002, José Fonseca wrote:
> >
> > Do we know for sure that pci gart is supported on mach64? The rage 128
> > and radeon drivers both write to PCI GART registers, but I don't see
> > anything analogous in the Rage
On Mon, 2002-04-15 at 11:33, Nicolas Aspert wrote:
> ...
>
> Hello
>
> I just noticed that the link in section 5.1.3 to the ATI AGP faq points
> to a 'page not found' :-( Maybe it have moved but maybe it has been
> simply removed.
It seems that ATI has redesigned its developer relation contents
Every time I refer to Utah-GLX code I can't avoid to think about the
enormous amount of duplication that would be to maintain a completely
different set of OpenGL drivers. Regardless of the OS the code in libGL
(meaning the Mesa driver) should be about 99% the same.
I know that main reason for r
José Fonseca wrote:
> I've just updated the FAQ. Besides of including the new section
> about binary compatibility from Jens Owen I also added a new top
> section focusing on the implementation details, including new
> material covering topics such as texture management, Mesa's graphics
> pip
31 matches
Mail list logo
