I've added the new PCI ids to the shared/drm_pciids.txt
Dave.
On Wed, 21 Apr 2004, Adam Jackson wrote:
> On Wednesday 21 April 2004 07:42, Vykupitel wrote:
> > Hello,
> > I've got problem with tdfx driver.Someone told me that tdfx driver
> > development is halted,but I need to add one type of c
It looks good to me.
Dave.
> confirmation of the patch before I apply it. (I applied the other three).
> Can someone take a look at this?
>
> In the future DRI-related patches should probably be sent to the dri-devel
> list.
>
> -Brian
>
>
> Tilman Sauerbeck wrote:
> > Hi,
> > the attached patc
although I'm sure debian are correct, I don't think this change is
appropriate for a stable release, it adds extra user space requirements..
so I won't be applying it in its current form, I might try firmware
loading and fall back to using the in-built microcode, it won't satisfy
Debian but that's
On Sun, 25 Apr 2004, Vladimir Dergachev wrote:
> >
> > It's a completely different 3D engine.
>
> Could you tell me why ?
>
> I can understand if textures and TCL are different due to different number
> of pipelines etc, but I would have expected glxgears to work.
>
> Also, checking the documenta
On Mon, 26 Apr 2004, Michel [ISO-8859-1] Dänzer wrote:
> On Sun, 2004-04-25 at 18:32, Vladimir Dergachev wrote:
> >
> > 1. Am I correct to assume that since direct rendering was enabled
> > the X was using CP accel funcs which then proves that CP is
> > working correctly ?
>
On Mon, 2004-04-26 at 00:12, Nathanael Nerode wrote:
> This is the most up-to-date version. Something very similar to this
> version is going into Debian's Linux kernel packages. (Herbert Xu claims
> to have removed the memcpy's in *_firmware_loader.c, though I don't
> know exactly how it did it.
I'm glad to see someone working on this. I know it's going to be a huge
hassle to get up and running (assuming it works at all) but it'll be worth
it just to show ATI linux users that it is possible to create stable,
fast, 2D/3D drivers for their R300 cards for XFree86 (since ATI seems
quite incap
On Sun, 2004-04-25 at 18:32, Vladimir Dergachev wrote:
>
> 1. Am I correct to assume that since direct rendering was enabled
> the X was using CP accel funcs which then proves that CP is
> working correctly ?
Yes.
> 2. It appears that Mesa driver needs adjustment. Shoul
On Sat, Apr 24, 2004 at 09:57:20PM +0100, Sérgio Monteiro Basto wrote:
> seems that I don't have any ~/.valgrindrc
>
> have someone one example of this file ?
You don't need a .valgrindrc. Just run
$ valgrind
To prove it, here's me excuting valgrind on the box in front of me:
$ ls -l ~/.valg
I tried hacking with R300 a little bit, so here are the results:
1. R300 microcode loads well (I am using Mobility M10)
2. The server starts up fine and displays "direct rendering enabled"
along the appropriate messages in XFree86.0.log
3. glxgears displays black windows
Ok valgrind have this
Available tools:
memcheck
addrcheck
cachegrind
corecheck
helgrind
massif
lackey
none
So I try
valgrind --tool=memcheck /usr/local/bin/foobillard >& debug2.txt
valgrind --tool=memcheck -v /usr/local/bin/foobil
Sérgio Monteiro Basto wrote:
On Sat, 2004-04-24 at 15:49, Brian Paul wrote:
When a program segfaults in free(), it's usually because of a memory
error (writing out of bounds, bouble-freeing a block, etc.).
valgrind will easily find such errors. Once you have it
built/installed, just run 'valgr
On Wed, Apr 21, 2004 at 01:45:44AM -0700, Andrew Morton wrote:
>...
> All 222 patches:
>...
> bk-drm.patch
>...
The drivers/char/drm/drm_irq.h in this patch contains a
#define __NO_VERSION__
which is useless since ages.
The patch below removes it.
Please apply
Adrian
--- linux-2.6.6-rc2-mm1-
13 matches
Mail list logo
