>
> As some of you know already, I have a fulltime job at ATI's Linux team
> now. I'll continue being active in the DRI and X communities as time
> permits. If you have any development related questions or suggestions
> about the proprietary ATI drivers, please don't hesitate to contact my
> manage
On Sun, 2004-08-29 at 11:41 +0100, Keith Whitwell wrote:
> Dave Airlie wrote:
> >>Why do you feel it will break their code? If it does, they have the option to
> >>either update their driver to match the new code or fork off the old code &
> >>continue to use that. I wouldn't be suprised if they'
Is mga_do_engine_reset being used by anything?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
---
This SF.Net email is sponsored by BEA Webl
Anyone tested it on SMP yet? I think the mga driver is dodgy the others
seem okay but until someone with an MGA/SMP/preempt does it ... I'm not
sure about it..
Dave.
On Sun, 29 Aug 2004, Jon Smirl wrote:
> This change is not going to break a non-SMP system but it may break an
> SMP one. This n
On Tue, 31 Aug 2004, Lee Revell wrote:
> On Tue, 2004-08-31 at 07:25, David M wrote:
> > Hello
> >
> > I believe some bugs have been fixed in the mga drm code that is part of the
> > 2.6 lowlat P8 patch set. Most of my audio qt apps now work (eg qjackctl muse
> > rosegarden etc) however there st
Yeah pacthing into the tree isn't really working, I do a small bit of
divergence between the CVS and the kernel, there is some backwards compat
that isn't wanted or needed in the real kernel I've been isolating
this stuff more and more of late though...
Dave.
On Thu, 2 Sep 2004, Tony Murray
I will have a deeper look into when I get home later. Basically I just
wanted to point out to you guys that it wasn't compiling when patched
into the tree.
I'll dig into the code and see if I can come up with a proper fix,
unless someone beats me ;)
Tony
>--- Jon Smirl [EMAIL PROTECTED] wrote:
>
Where are you getting your DRM source from? The source in
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri co drm
builds on current Linus bk (and 2.6.8.1) without problem.
--- Tony Murray <[EMAIL PROTECTED]> wrote:
> I am using drm from cvs and I fixed a few compile errors when the drm
> drivers
Tony Murray wrote:
I am using drm from cvs and I fixed a few compile errors when the drm
drivers are used with 2.6.8.1 (all trivial api changes). I don't have
the hardware to test all of the drivers, but it should be fine.
Tony
diff -urN linux-2.6.8.1-drm2/drivers/char/drm/ati_pcigart.h
linux-2.6.
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Here's the problem that I want to avoid. Imagine a case where a user
> has 2 graphics cards. Say, an integrated i915 and a PCI R200. The
> installed versions both use drm_core version N. Now the user wants
> to upgrade the R200 driver, but the new
Alan Cox wrote:
On Iau, 2004-09-02 at 15:04, Thomas HellstrÃm wrote:
Could this be acceptable security-wise?
I'd add an upper limit to the kmalloc buffer size of say 32K
(realistically thats as big as will be reliable anyway).
OK, then we might perhaps skip the kmalloc
I am using drm from cvs and I fixed a few compile errors when the drm
drivers are used with 2.6.8.1 (all trivial api changes). I don't have
the hardware to test all of the drivers, but it should be fine.
Tony
diff -urN linux-2.6.8.1-drm2/drivers/char/drm/ati_pcigart.h
linux-2.6.8.1-drm/drivers/cha
Dieter Nützel schrieb:
Philipp Klaus Krause schrieb:
gcc-3.5 -O2 -march=athlon-mp -msse -DMP
Just saw that the it seems to take the options from the Makefile,
I just set them in options (included by Makefile, but the CFLAGS
defined there is overwrittem)
;-)
That's why I 'included' my changed Env
Philipp Klaus Krause schrieb:
gcc-3.5 -O2 -march=athlon-mp -msse -DMP
Just saw that the it seems to take the options from the Makefile,
I just set them in options (included by Makefile, but the CFLAGS
defined there is overwrittem)
;-)
That's why I 'included' my changed EnvLINUX.c (taken from EnvS
gcc-3.5 -O2 -march=athlon-mp -msse -DMP
Just saw that the it seems to take the options from the Makefile,
I just set them in options (included by Makefile, but the CFLAGS
defined there is overwrittem)
Philipp
---
This SF.Net email is sponsored b
I did use a slightly older cvs version with only my vertex
program patch applied and built in the Mes tree without
optimizations.
Strange, I just ran Viewperf 8
8.0.1?
Yes.
I've downloaded it in the morning. ;-)
on my r200 and didn't notice
any problems
SMP-system (EnvLINUX.c reports num=2)
-DMP
On Iau, 2004-09-02 at 15:04, Thomas HellstrÃm wrote:
> Could this be acceptable security-wise?
I'd add an upper limit to the kmalloc buffer size of say 32K
(realistically thats as big as will be reliable anyway). Otherwise looks
ok. It does do the offset maths twice once without need and loads val
Philipp Klaus Krause schrieb:
Dieter NÃtzel schrieb:
Argh,
what a regression.
most tests show mostly empty and/or black and/or white windows...
Strange, I just ran Viewperf 8
8.0.1?
I've downloaded it in the morning. ;-)
on my r200 and didn't notice
any problems
SMP-system (EnvLINUX.c reports num=2
Hi!
Just verified that latest CVS works.
Thanks.
/Thomas
> I finally found this problem and fixed it in CVS. When using
> pci_get_subsys() with the last parameter NULL, you have to do
> pci_dev_put() manually. When I changed the loop to detect multiple
> indentical cards I started using the las
Dieter NÃtzel schrieb:
Argh,
what a regression.
most tests show mostly empty and/or black and/or white windows...
Strange, I just ran Viewperf 8 on my r200 and didn't notice
any problems (expect ensight-01 that didn't even run, but it
seems that's a problem with a Viewperf script).
Philipp Klaus Kr
Hi!
In order to be able for dri clients to write to certain registers when
direct write-access to the MMIO area of the unichrome is shut down, I've
added an IOCTL to Erdi's dma interface.
It has a very simple "parser" that denies access to register areas that
might be dangerous. The 2d blitter ca
21 matches
Mail list logo
