from my laptop
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M
AGP 2x (rev 64) (prog-if 00 [VGA])
looks the same to me and mine works :-) so yours should ...
On Fri, 12 Mar 2004, Mike Mestnik wrote:
> I don't know, if it loads or not, I stoped trying when I found ought
I don't know, if it loads or not, I stoped trying when I found ought that
only Rage pro was supported. However the 2d driver workes fine.
01:00.0 Class 0300: 1002:4c4d (rev 64)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M
AGP 2x (rev 64) (prog-if 00 [VGA])
Sub
Send your cards PCI ids to the list,
Mike what card have you the DRM shouldn't load for any card that doesn't
have the triangle engine really..
Dave.
On Thu, 11 Mar 2004, Mike Mestnik wrote:
> At first I thought it just might have been my system. In debuging the
> problem I found ought that m
At first I thought it just might have been my system. In debuging the
problem I found ought that my chip dose not have triangle setup. It's not
likely that it will be supported by DRI. However the 2d driver gave me
xrendr support, this will help with TV out for me.
As for the kmod if you post t
On Wed, 12 Feb 2003, Martin Spott wrote:
>Date: Wed, 12 Feb 2003 14:36:41 +0100 (CET)
>From: Martin Spott <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>List-Id:
>Subject: Re: mach64-0-0-6-branch
>
>> [...] Since the GATOS head is now based
>> on current XFree86 cvs, I may not have a new patch until
On Wed, 17 Jul 2002, Keith Whitwell wrote:
> >>I've done all the others. Lets see if testing was required...
> >>
> >
> > So, should I commit the fix for r128? I've tested that and it works fine.
>
> Yes, go ahead.
>
> > I took a look at the other drivers concerning the read buffer fix. I
Leif Delgass wrote:
> On Wed, 17 Jul 2002, Keith Whitwell wrote:
>
>
>>Leif Delgass wrote:
>>
>>>On Wed, 17 Jul 2002, Leif Delgass wrote:
>>>
>>>
>>>
On 17 Jul 2002, Michel Dänzer wrote:
>On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
>
>
>>I've fixed this
On Wed, 17 Jul 2002, Keith Whitwell wrote:
> Leif Delgass wrote:
> > On Wed, 17 Jul 2002, Leif Delgass wrote:
> >
> >
> >>On 17 Jul 2002, Michel Dänzer wrote:
> >>
> >>
> >>>On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
> >>>
> I've fixed this for drivers that use t_dd_triemit.h -- cur
Leif Delgass wrote:
> On Wed, 17 Jul 2002, Leif Delgass wrote:
>
>
>>On 17 Jul 2002, Michel Dänzer wrote:
>>
>>
>>>On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
>>>
I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
and r200.
>>>Great job! The clippin
On Wed, 17 Jul 2002, Leif Delgass wrote:
> On 17 Jul 2002, Michel Dänzer wrote:
>
> > On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
> > > I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
> > > and r200.
> >
> > Great job! The clipping problems I originally repo
On 17 Jul 2002, Michel Dänzer wrote:
> On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
> > I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
> > and r200.
>
> Great job! The clipping problems I originally reported with the
> xscreensaver gears hack and fsv are fixe
On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
> I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
> and r200.
Great job! The clipping problems I originally reported with the
xscreensaver gears hack and fsv are fixed.
--
Earthling Michel Dänzer (MrCooper)/ Debia
Michel Dänzer wrote:
> On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
>
>>On Tue, 16 Jul 2002, Keith Whitwell wrote:
>>
>>
Well, it's not high on my list. I don't think flat-shading is used that
often, and the changes don't have any effect on smooth shading. Actually,
it _elimin
On Wed, 17 Jul 2002, Leif Delgass wrote:
> On 17 Jul 2002, Michel Dänzer wrote:
>
> > On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
> > > On Tue, 16 Jul 2002, Keith Whitwell wrote:
> > >
> > > > > Well, it's not high on my list. I don't think flat-shading is used that
> > > > > often, and
On 17 Jul 2002, Michel Dänzer wrote:
> On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
> > On Tue, 16 Jul 2002, Keith Whitwell wrote:
> >
> > > > Well, it's not high on my list. I don't think flat-shading is used that
> > > > often, and the changes don't have any effect on smooth shading. Ac
On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
> On Tue, 16 Jul 2002, Keith Whitwell wrote:
>
> > > Well, it's not high on my list. I don't think flat-shading is used that
> > > often, and the changes don't have any effect on smooth shading. Actually,
> > > it _eliminates_ some saves/restor
Thanks for the snapshots Leif. For what you've shown me it seems that
the problem lives in TAG(interp) of mach64_native_vbtmp.h.
Unfortunetaly I haven't been able to do much testing yet, because after
updating my local CVS tree with the recent changes I was forced to recompile
the whole tree aga
I saw a similar problem in torcs. First I thought it was just a problem
with too little z-buffer accuracy. But when you look closely you see
that the polygon is too bright.
http://www.dd.chalmers.se/~kuhlfeli/torcsbug.jpg
On Mon, 15 Jul 2002 19:08:29 -0400 (EDT)
Leif Delgass <[EMAIL PROTECTED]>
The problem only appears when the procedural texture in the center of the
octagon is clipped by the window edge. Here's a shot of it unclipped:
http://retinalburn.net/linux/q3a-unclipped.jpg
So far, I've only noticed this on a few of the procedural textures that
rotate and/or stretch. This one
I forgot to mention that commenting out the fallback primitive functions
didn't have an effect.
On Mon, 15 Jul 2002, Leif Delgass wrote:
> Here's a couple screenshots of the multitexture bug in quake3 lightmap
> mode (two slightly different angles):
>
> http://retinalburn.net/linux/q3a-bug1.j
On Fri, 21 Jun 2002, Stefan Lange wrote:
> >Another question. I am using the Gatos driver for hardware accelerated
> >DVD watching. Can I use them together with the DRI Mach64 drivers?
> >
>
> I doubt that mixing these drivers will work, because gatos uses its own
> drm-module (correct me if I'
>
>Another question. I am using the Gatos driver for hardware accelerated
>DVD watching. Can I use them together with the DRI Mach64 drivers?
>
I doubt that mixing these drivers will work, because gatos uses its own
drm-module (correct me if I'm wrong). You'd probably have to merge both
codeba
Also you might want to know that I had problems getting the wrong kernel
headers under woody. It seams that 'as explained in the docs for
kernel-header-*' the debian headers may not be the same as the kernel headers.
If you compile a kernel module ought side the kernel tree it's doomed to get
th
Hello,
> I just tried to compile the newest mach64-0-0-4 branch to do some
> tests and got the following error:
>
> make[10]: Entering directory
>
>`/usr/local/src/DRI-CVS/build/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel'
> === KERNEL HEADERS IN /lib/modules/2.4.18/build/include
>There are some problems remaining on the DMA which could affect
>certain slower machines. Could you tell me what's your processor
>and its speed? Also check if there is any message in
>/var/log/messages. Just to be sure...
The CPU is Celeron 433 mhz.
Latest message was: Jun 15 08:35:41 fede k
On 2002.06.01 23:49 Leif Delgass wrote:
> ...
>
> I found and fixed this problem (I was using ring.tail to set the offset
> for buffer "aging" before it was incremented).
>
> ...
>
> I've cleaned this up a bit and done the work in COMMIT_RING.
>
> ...
>
> OK, I'm still not sure if I have this
On Sat, 1 Jun 2002, Leif Delgass wrote:
> the ring_wait is really not necessary, since 128 16kB buffers can use a
> max of 512 of the 1024 descriptors. We'd need 4MB of buffers to fill
> the ring.
On second thought, this is only true as long as we're not reusing buffers.
If we reuse buffers f
On Fri, 31 May 2002, José Fonseca wrote:
> On 2002.05.31 02:53 Leif Delgass wrote:
> > On Thu, 30 May 2002, José Fonseca wrote:
> >
> > I've fixed one bug already that was related to the ring tail being left
> > pre-incremented (the table_end I had before wasn't). Some of my problems
> > were r
On 2002.05.31 02:53 Leif Delgass wrote:
> On Thu, 30 May 2002, José Fonseca wrote:
>
> > Leif,
> >
> > On 2002.05.30 02:02 José Fonseca wrote:
> > > ... Tomorrow I'll take a look more carefully to see if I find
> anything
> > > suspicious. ...
> >
> > I've been analyzing the diff very carefully a
On Thu, 30 May 2002, José Fonseca wrote:
> Leif,
>
> On 2002.05.30 02:02 José Fonseca wrote:
> > ... Tomorrow I'll take a look more carefully to see if I find anything
> > suspicious. ...
>
> I've been analyzing the diff very carefully and what I've found so far are
> just some details which
Leif,
On 2002.05.30 02:02 José Fonseca wrote:
> ... Tomorrow I'll take a look more carefully to see if I find anything
> suspicious. ...
I've been analyzing the diff very carefully and what I've found so far are
just some details which can be taken care later (i.e., no bugs sorry) :
- This co
On 2002.05.30 01:13 Leif Delgass wrote:
> Jose,
>
> It's taking me a little longer than expected to finish the changes I
> mentioned. I'm trying to set this up so that it will be possible to test
> emitting buffers to the ring as they come in, but keep the original code
> in place, while sharing
On Thu, 23 May 2002 23:05:32 +0100
José Fonseca <[EMAIL PROTECTED]> wrote:
> On 2002.05.23 22:37 Leif Delgass wrote:
> > I've committed code to read BM_GUI_TABLE to reclaim processed buffers and
[...]
> > Monday the 20th but after Saturday the 18th, could you test to see if
> > this
> > happens?
On 2002.05.23 22:37 Leif Delgass wrote:
> I've committed code to read BM_GUI_TABLE to reclaim processed buffers and
> disabled frame and buffer aging with the pattern registers. I've
> disabled
> saving/restoring the pattern registers in the DDX and moved the wait for
> idle to the XAA Sync. Thi
Hi all
So, I took the first snapshot with textures - and ready to say something
good. Well, DRI now works even in 1280x1024 - great thanks to Leif and
others. At least I don't have to modify XF86Config every time...
1. glxinfo - OK, usual report.
2 glxgears does not show me any real difference
Leif,
On 2002.05.18 16:59 Leif Delgass wrote:
> ...
>
> I was just thinking that we could replace buffer aging with a check of
> BM_GUI_TABLE in freelist_get when searching the pending list, similar to
> what I'm doing with the dispatch. Since we know the physical address of
> each buffer, we c
On Sat, 18 May 2002, José Fonseca wrote:
> On 2002.05.18 10:33 Leif Delgass wrote:
> > OK, I finally committed my changes thus far as a checkpoint. I'm reading
> > BM_GUI_TABLE in the dispatch routine to see when we hit the hardware
> > pointer and wait once we reach it. So the dispatch is trea
On 2002.05.18 10:33 Leif Delgass wrote:
> OK, I finally committed my changes thus far as a checkpoint. I'm reading
> BM_GUI_TABLE in the dispatch routine to see when we hit the hardware
> pointer and wait once we reach it. So the dispatch is treating the
> descriptor table as a ring, and it help
On Wednesday 15 May 2002 06:51 am, Leif Delgass wrote:
> I'm getting close to committing this now. I got gui-master blits working,
> and pseudo-DMA is stable. Actually, the pseudo-DMA is probably faster
> without blits, but I'm hoping that it will help with DMA. The DMA is
> still prone to loc
> Leif, to be able to do a) I would like to base on the buffer aging code
> you have already written. There is no need for commiting anything as I
> don't want to update my tree now - could you just send me a diff of your
> current tree as is so that I can see how you did?
I'm getting close to
> fixing this :) Anyway, you should not expect 2D + 3D acceleration too
> soon.
OK. At least - thanks for explanation.
> problems right now (especially on the mach64 branch :).
:)) I see. It makes sense.
> I solved both the resolution and 2d acceleration problems for me by
> having two X servers
On 02 May 2002 23:19:10 +0100
"Sergey V. Udaltsov" <[EMAIL PROTECTED]> wrote:
> BTW, it was mentioned it was easy to enable 2D acceleration back. Is it
> true? Can it be done in snapshots (by checking this illustrious
> pATI->directRenderingEnabled). So people could use snapshot drivers in
> ever
> Yes, that's the goal. "Synchronous" DMA means that we wait for the card
> to idle after submitting each DMA pass, rather than going on to do other
> things and polling or handling interrupts to check for completion of the
> DMA transfer. Synchronous operation isn't meant to be fast, it's just
On 2 May 2002, Sergey V. Udaltsov wrote:
> Hi
>
> > Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in
> > CVS now. Just update and rebuild and install the kernel module. This is
> > not related to your original problem though, I'm not sure what would be
> > causing a
Hi
> Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in
> CVS now. Just update and rebuild and install the kernel module. This is
> not related to your original problem though, I'm not sure what would be
> causing a lockup on vt switches if no GL contexts are running.
On Thu, May 02, 2002 at 06:34:11AM -0400, Mike A. Harris wrote:
> >mtrr: Serverworks LE detected. Write-combining disabled.
>^^
> Ick. Problem #1
Yeah, I suspected as much. This damned computer has given me quite a bit
of trouble in the details.
Yup.
> unfortunately. Ser
On Wed, 1 May 2002, Kees Cook wrote:
>I've finally had a chance to upgrade to XFree86 4.2.0, and am trying out
>the bleeding edge builds for mach64. :)
>
>Quick version: it doesn't work.
>
>Long version: I think I have an AGP problem.
>
>glxinfo reports that direct rendering is off.
>the mach64
Hi
> Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in
> CVS now. Just update and rebuild and install the kernel module. This is
> not related to your original problem though, I'm not sure what would be
> causing a lockup on vt switches if no GL contexts are running.
On 1 May 2002, Sergey V. Udaltsov wrote:
> Hi
>
> > Do you use some framebuffer device?
> To the best of my knowledge - no.
>
> > You can start to give us the last lines of /var/log/messages, as I think
> > that there should be a kernel oops in there. The XFree86.log may be
> > interesting to
Hi
> Do you use some framebuffer device?
To the best of my knowledge - no.
> You can start to give us the last lines of /var/log/messages, as I think
> that there should be a kernel oops in there. The XFree86.log may be
> interesting too.
YESS! There is OOPS. See attached.
Cheers,
Sergey
M
On 2002.04.30 22:33 Sergey V. Udaltsov wrote:
> Hi
>
> I cleaned up all modules and run 0-0-4 from clean state - still same
> lockup on X termination. Actully, I get the lockup not in termination
> but in attempts to switch to any textual console.:(
Do you use some framebuffer device?
>
> > Th
Hi
I cleaned up all modules and run 0-0-4 from clean state - still same
lockup on X termination. Actully, I get the lockup not in termination
but in attempts to switch to any textual console.:(
> The reason is that I've changed the dripkg/install scripts sometime, and I
Could you please give me
On Tue, 30 Apr 2002, José Fonseca wrote:
> On 2002.04.30 10:54 Sergey V. Udaltsov wrote:
> > > No. There isn't any yet. But we can arrange to something be printed
> > on
> > > the system log when the DMA is enabled on runtime.
> > That would be nice. Also, Leif offered to turn DMA on if bus mas
> In the previous 0-0-3 branch we almost never messed with the DRM, so it
> was binary compatible between all snapshots. Now is exactly the opposite.
> Nevertheless you shouldn't need to stop X if you're running your distro X.
> You need only if you are running X from a mach64 branch, because i
On 2002.04.30 10:54 Sergey V. Udaltsov wrote:
> > It seems that the mach64 kernel moduled wasn't replaced from memory,
> > causing a kernel oops. Usually you need to run install.sh without X
> > running (I usually do init 3).
> Well, at least with 0-0-3 I managed to do in without stopping X. Just
> It seems that the mach64 kernel moduled wasn't replaced from memory,
> causing a kernel oops. Usually you need to run install.sh without X
> running (I usually do init 3).
Well, at least with 0-0-3 I managed to do in without stopping X. Just
"install.sh" and restarting X was enough. OK, if you
On 2002.04.30 09:38 Sergey V. Udaltsov wrote:
> > From this moment the mach64 binary snapshots in
> > http://dri.sourceforge.net/snapshots/bleeding-edge/ are taken from the
> > 0-0-4 branch.
> Thanks. Just tried. Well, it seems 0-0-4 has long way to go:)
> First, I just run "install.sh" and resta
> From this moment the mach64 binary snapshots in
> http://dri.sourceforge.net/snapshots/bleeding-edge/ are taken from the
> 0-0-4 branch.
Thanks. Just tried. Well, it seems 0-0-4 has long way to go:)
First, I just run "install.sh" and restarted X. I got segmentation fault
on glxinfo - after di
On 2002.04.29 20:49 Leif Delgass wrote:
> On Mon, 29 Apr 2002, José Fonseca wrote:
> > ...
> > From this moment the mach64 binary snapshots in
> > http://dri.sourceforge.net/snapshots/bleeding-edge/ are taken from the
> > 0-0-4 branch.
> >
> > Note that the DMA is disabled by default, and there w
On Mon, 29 Apr 2002, José Fonseca wrote:
> On 2002.04.29 16:14 Sergey V. Udaltsov wrote:
> > Actually, Leif is right. DRI really works on 1024x768 but... very slow
> > (thanks to PIO?). My Rage Mobility cannot run Counter-Strike properly
> > (the game is unplayable in this mode). In 800x600 it is
On Sat, 2002-04-27 at 21:24, Leif Delgass wrote:
>
> I've just commited the endianess conversion for register reads/writes to
> the branch, so you won't have to keep applying Michel's patch. I used
> le32_to_cpu/cpu_to_le32 since that's what the other drivers use and I
> was getting a compiler w
On Sat, 27 Apr 2002, Peter Andersson wrote:
> > Hi,
> >
> > I cvs updated mach64-0-0-4-branch last night and recompiled (previous
> > update was on sunday). Right after starting glxgears the screen switched
> > off (like with xset dpms force off) and the machine hung. The sysrq keys
> > did
> Hi,
>
> I cvs updated mach64-0-0-4-branch last night and recompiled (previous
> update was on sunday). Right after starting glxgears the screen switched
> off (like with xset dpms force off) and the machine hung. The sysrq keys
> didn't work.
>
> Maybe Peter Anderson's problems are not P
On 2002.04.21 21:13 Leif Delgass wrote:
> On Sun, 21 Apr 2002, Leif Delgass wrote:
> > ...
> >
> > Yes, I think waiting for idle here is overkill. According to the
> > programmer's guide, you only need to wait for idle when reading a
> register
> > or bit field updated by the draw engine, or when
On Sun, 21 Apr 2002, José Fonseca wrote:
> On 2002.04.21 19:40 Leif Delgass wrote:
> > On Sun, 21 Apr 2002, José Fonseca wrote:
> >
> > > > We just need to add the fifo check now.
> > >
> > > I've just add it but it makes gears drop from 222 to 185 fps in my
> > system.
> > > I don't know if thi
On 2002.04.21 19:40 Leif Delgass wrote:
> On Sun, 21 Apr 2002, José Fonseca wrote:
>
> > > We just need to add the fifo check now.
> >
> > I've just add it but it makes gears drop from 222 to 185 fps in my
> system.
> > I don't know if this is caused by droped triangles when there is no
> FIFO
>
On Sun, 21 Apr 2002, José Fonseca wrote:
> > We just need to add the fifo check now.
>
> I've just add it but it makes gears drop from 222 to 185 fps in my system.
> I don't know if this is caused by droped triangles when there is no FIFO
> check, or if the FIFO check makes a big overload. So
On 2002.04.21 07:56 Leif Delgass wrote:
> Well, I knocked one item off the list. I implemented sequential
> multi-register writes in the primitive functions. Seems to help my
> framerate a bit even with pseudo-DMA. I changed the primitive functions
> to supply the register addresses as the memo
> I found that calls to TexParameter were not setting the texture wrapping
> and texture filter in some cases (where the driver private texture object
> struct had not already been allocated). This is now fixed and solves the
> following bugs:
Well done! It seems armagetron is really fixed.
S
Leif Delgass
> http://www.retinalburn.net
>
> -- Forwarded message --
> Date: Thu, 7 Mar 2002 22:40:14 -0500 (EST)
> From: Leif Delgass <[EMAIL PROTECTED]>
> To: José Fonseca <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: [Dri-devel] Re: mach6
EST)
From: Leif Delgass <[EMAIL PROTECTED]>
To: José Fonseca <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: [Dri-devel] Re: mach64 mulltiarb
I'll try to take a look at when multitex is set. I did find a problem
that I committed a fix for. When stepping through multiarb, I notice
I'll try to take a look at when multitex is set. I did find a problem
that I committed a fix for. When stepping through multiarb, I noticed
that when UpdateTexUnit is called for unit=1, SetTexImages was being
passed the texture object bound to unit 0. Turns out that the
mmesa->tmu_source[]
--- Leif Delgass <[EMAIL PROTECTED]> wrote: >
I commited a fix for single texturing which works
> now. Turns out the
> teximages weren't being marked for upload in
> UpdateTextureUnit, so
> UploadTexImages never got called. Multitexture is
Great. I was also hunting this problem.
> still not
On 2002.03.04 18:25 Keith Whitwell wrote:
> Jose Fonseca wrote:
> >
> > ...
> >
> > It's a good setup. Unfortunately, my devel box and test box are my
> > laptop - the one and only computer I have at home. Seldom I hope to
> lend
> > a 2nd laptop of a friend of mine to deal with X crashes.
>
> If
On Mon, Mar 04, 2002 at 05:56:50PM +, Keith Whitwell wrote:
> Ian Romanick wrote:
> >
> > On Mon, Mar 04, 2002 at 05:33:30PM +, Keith Whitwell wrote:
> >
> > > I'm using nfs to get executables from devel to test boxes, but I'd like
> > > something less insecure...
> >
> > In other proje
Jose Fonseca wrote:
>
> On Mon, 2002-03-04 at 17:33, Keith Whitwell wrote:
> > "José Fonseca" wrote:
> > >
> > >Part 1Type: Plain Text (text/plain)
> > > Encoding: 8bit
> >
> > Jose. Your messages are looking like this --^
> >
>
> :-( I was using CVS version of Balsa (a Gnome M
On Mon, 2002-03-04 at 17:33, Keith Whitwell wrote:
> "José Fonseca" wrote:
> >
> >Part 1Type: Plain Text (text/plain)
> > Encoding: 8bit
>
> Jose. Your messages are looking like this --^
>
:-( I was using CVS version of Balsa (a Gnome MUA) but it seems that I
shouldn't be doi
Ian Romanick wrote:
>
> On Mon, Mar 04, 2002 at 05:33:30PM +, Keith Whitwell wrote:
>
> > I'm using nfs to get executables from devel to test boxes, but I'd like
> > something less insecure...
>
> In other projects I have found that using rsync works quite well. There
> have been enough pr
On Mon, Mar 04, 2002 at 05:33:30PM +, Keith Whitwell wrote:
> I'm using nfs to get executables from devel to test boxes, but I'd like
> something less insecure...
In other projects I have found that using rsync works quite well. There
have been enough problems with Linux NFS over the years
"José Fonseca" wrote:
>
>Part 1Type: Plain Text (text/plain)
> Encoding: 8bit
Jose. Your messages are looking like this --^
Anyway wrt error messages, it works well if stderr doesn't come out on the
display being debugged, so can't hang anything even if 2d/3d interaction is
br
On 2002.03.04 09:38 Leif Delgass wrote:
> Well, my disks just spun up for the nightly updatedb cron, so that's my
> cue to go to bed, but I wanted to give you a quick update. I've got
> scissors and cliprects working, with the exception of overlapping GL
> windows having some problems, but we had
Leif,
I just finished _vb.c. It compiles with just a warning of a missing
defintion. Do you prefer I commit or do you want to take a look first?
Are you still working on this? Have you some spare minutes for IRC?
Regards,
José Fonseca
On 2002.02.28 23:38 Leif Delgass wrote:
> On Thu, 28 Feb
On Thu, 28 Feb 2002, José Fonseca wrote:
> Leif,
>
> I've finished the work on the the mach64_* files except for the
> *_{tris,vb} ones. I've also included the remaining of your changes.
>
> There still are several things that I'm not sure, but I'll leave those
> issues to the moment that we
On 2001.11.21 07:27 Mike A. Harris wrote:
> On Tue, 20 Nov 2001, Dorin Lazar wrote:
>
> >> Sorry to bother you again. I talked with the people from ATI -
> they said
> >> that (and I quote)
> >>
> >> Hello Dorin.
> >>
> >> I noticed in your form you are doing work with Linux. We have
provided
On Tue, 20 Nov 2001, Dorin Lazar wrote:
>> Sorry to bother you again. I talked with the people from ATI - they said
>> that (and I quote)
>>
>> Hello Dorin.
>>
>> I noticed in your form you are doing work with Linux. We have provided the
>> necessary documents to the Xfree86 and DRI proje
85 matches
Mail list logo
