Hello all
I have a small problem with the DRI on a acer 1314LC with a SavageDDR.
What I did is to install the DRI snapshot
savage-20040303-linux.i386.tar.bz2 (and the modified Xfree86 binary) on
a Fedora Core 1 ( kernel-2.4.22-1.2174.nptl) and it worked. I had DRI
enabled and everithing.
The p
On Tue, 20 Apr 2004 04:02:24 -0700
[EMAIL PROTECTED] wrote:
> diff -urN /tmp/wiki.1L952g/wiki/text/Building
> /home/groups/d/dr/dri/wiki/text/Building
> --- /tmp/wiki.1L952g/wiki/text/Building 2004-04-17 17:59:21.0 -0700
> +++ /home/groups/d/dr/dri/wiki/text/Building 2004-04-19 06:
--- Tom Vier <[EMAIL PROTECTED]> wrote:
> i finally got dri working, but... i'm using 2.6.5 on x86 (dual
> opteron
> mobo with a single cpu). i have an agp 9200 and i'm using xfree
> 4.3.0.
> whenever i scroll or sometimes when inputing text, i get these white
> horizontal lines that appear in ran
On Tuesday 20 April 2004 07:34, Felix Kühling wrote:
>
> Better yet, set
>
> #define BuildXFree86ConfigTools NO
>
> in xc/config/cf/host.def. This should probably be made the default
> setting.
>
Noted, thanks. I took a quick look for the relevant option when I first added
that text, but must
Dave Airlie wrote:
http://freedesktop.org/~airlied/drm_pci_ids.diff
Same as last patch except now it uses the Linux PCI structures in the DRM,
it still doesn't do any of the other stuff,
again I want to have this stuff in nice clean steps so breakage is
obvious,
I believe this is a good first step
Dave Airlie wrote:
simple behaviour is different, no idea if anyone relies on it ..
modprobe radeon
modprobe radeonfb
will not longer work the same with the new system, be it stupid/broken
etc,, there is potential difference in a stable kernel series, what
happens if I build both into the kernel?
On Llu, 2004-04-19 at 21:21, Jon Smirl wrote:
> Do you really want to teach FB about setting modes on multiple heads?
Yes and I know it needs to know about memory management too. Lots of
cards need memory management anyway either for textures or even AGP
drawn frame buffers.
A lot of the computat
The kernel provides symbols for all of the PCI ID constants via pci_ids.h. The
strings describing the hardware are duplicated against drivers/pci/pci.ids. How
do the kernel people feel about us not using their symbols and strings? We're
creating duplicate definitions for these items. I seem to reca
This is a post from the Cairo list. It benchmarks a Cairo program against image,
xrender, glx implementations of Cario. You can see that 2D drawing is a the
minimum 10x faster and sometimes 200x or more when using the 3D hardware. Data
like this is the driving force for bring up xserver on a standa
Keith Whitwell wrote:
Keith Whitwell wrote:
Ah, ok. I see the problem. Basically this has to do with the fact
that choosing the hw vertex format has gone from being something
(normally) done ahead of time, prior to actually running the tnl
pipeline, to something done after that, and based on
Jon Smirl wrote:
This is a post from the Cairo list. It benchmarks a Cairo program against image,
xrender, glx implementations of Cario. You can see that 2D drawing is a the
minimum 10x faster and sometimes 200x or more when using the 3D hardware. Data
like this is the driving force for bring up x
We need to build the open source version first in order to provide an API
standard for the closed source ones to develop too. Once we get xserver server
up on mesa-solo I wouldn't expect it to be too long until we have closed source
solo versions from ATI and NVidia for all of their hardware.
---
On Tue, 20 Apr 2004 10:46:36 -0700
Ian Romanick <[EMAIL PROTECTED]> wrote:
[snip]
>
> Right now both your latest patch and my patch seem to be totally hosed.
> I haven't changed any of my code since Friday (when it mostly worked),
> but there have been some changes since then in Mesa. Anythi
Felix Kühling wrote:
On Tue, 20 Apr 2004 10:46:36 -0700
Ian Romanick <[EMAIL PROTECTED]> wrote:
[snip]
Right now both your latest patch and my patch seem to be totally hosed.
I haven't changed any of my code since Friday (when it mostly worked),
but there have been some changes since then in Me
On Maw, 2004-04-20 at 18:35, Jon Smirl wrote:
> This is a post from the Cairo list. It benchmarks a Cairo program against image,
> xrender, glx implementations of Cario. You can see that 2D drawing is a the
> minimum 10x faster and sometimes 200x or more when using the 3D hardware. Data
For one be
On Maw, 2004-04-20 at 18:26, Jon Smirl wrote:
> The kernel provides symbols for all of the PCI ID constants via pci_ids.h. The
> strings describing the hardware are duplicated against drivers/pci/pci.ids. How
pci.ids isnt used by 2.6, its primarily used by lspci in user space, and
the name stuff h
The result of _tnl_CreateContext( ctx ) isn't checked anywhere.
and so you may get a sigsegv later in _tnl_install_attrs()
in this line:
vtx->emit = choose_emit_func;
because ctx->swtnl_context is NULL if CALLOC didnt work.
This occurs with some demos when trying to run them in wine (CVS),
for e
Andreas Stenglein wrote:
The result of _tnl_CreateContext( ctx ) isn't checked anywhere.
and so you may get a sigsegv later in _tnl_install_attrs()
in this line:
vtx->emit = choose_emit_func;
because ctx->swtnl_context is NULL if CALLOC didnt work.
This occurs with some demos when trying to run t
Am 2004.04.21 00:26:41 +0200 schrieb(en) Brian Paul:
[...]
> Do you mean glXCreateContext()? Are the function parameters the same
> for both calls?
>
yes its called twice, no with different parameters.
I tried to see what happens with the Mesa-Software-Renderer libGL with DEBUG on
and it doesnt
Nathanael Nerode wrote:
Yeesh. Attached are the patch and the new files. I couldn't find a good
way to abstract this any further than I already did without breaking
other abstractions; hence the extra files.)
Tell me what sort of changelog you'd like.
This appears to work for Linux 2.6; I haven'
Nathanael Nerode wrote:
Nathanael Nerode wrote:
Yeesh. Attached are the patch and the new files. I couldn't find a good
way to abstract this any further than I already did without breaking
other abstractions; hence the extra files.)
Tell me what sort of changelog you'd like.
This appears to wor
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> For one benchmark on a high end 3D card. For a lot of hardware the
> same will not be true - although it is likely to be for things like
> alpha blend which a lot of chips can't do in the 2D engine although some
> could.
It's going to be two years before x
Here's an updated version of the patch. It incorporates most of Keith's
code. It seems to mostly work with 2 exceptions.
- r200PointsBitmap is still broken. I'm not sure what the right way is
going to be to fix that.
- Colors are wrong. The cylinder in gloss is brownish instead of
purple,
>
> The patch looks good. However, doesn't drm_pci_id_list need to be updated for
> BSD to add the 2 new fields? Other than that, it looks good to me.
nope that's why there are two scripts, the bsd generates the info bsd
wants, the linux one generates the info linux wants..
so Linux no longer c
I wrote:
This appears to work for Linux 2.6; I haven't been able to test it
anywhere
else. However, it should be quite close to no change at all
everywhere else.
Oh, and as I've said before, I can't *really* test it, because I don't
have the cards in question. :-P It builds and the module a
* Andrea Arcangeli ([EMAIL PROTECTED]) wrote:
> On Fri, Apr 16, 2004 at 11:54:06AM -0700, Chris Wright wrote:
> > + if (mc.idx >= dma->buf_count)
> > + return -EINVAL;
> > +
> > i810_dma_dispatch_mc(dev, dma->buflist[mc.idx], mc.used,
> > mc.last_render );
>
> this is w
On Fri, Apr 16, 2004 at 11:54:06AM -0700, Chris Wright wrote:
> * Ken Ashcraft ([EMAIL PROTECTED]) wrote:
> > [BUG]
> > /home/kash/linux/linux-2.6.5/drivers/char/drm/i810_dma.c:1276:i810_dma_mc:
> > ERROR:TAINT: 1267:1276:Using user value "((mc).idx * 4)" without first performing
> > bounds check
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
> so Linux no longer carries the device name around with it, it uses the
> kernel to get if support is there if not you get blank string,
You could still generate a string to help with debug. Something like "Radeon QX"
by converting the PCI ID to ASCII. L
On Monday 19 April 2004 20:08, Michel DÃnzer wrote:
> On Tue, 2004-04-20 at 02:13, ajax wrote:
> > All drivers except savage emit the "Direct rendering disabled" message as
> > an informational message; savage makes it an error. Technically it's not
> > an error, since the server can continue, but
>
> You could still generate a string to help with debug. Something like "Radeon QX"
> by converting the PCI ID to ASCII. Later when you get the family you could
> generate "Radeon R250 QX" for the string.
well if someone builds their kernel with pci strings turned off I persume
they know what the
http://bugme.osdl.org/show_bug.cgi?id=2554
Summary: DRM fails to compile on i386
Kernel Version: 2.4.26
Status: NEW
Severity: normal
Owner: [EMAIL PROTECTED]
Submitter: [EMAIL PROTECTED]
Since http://bugzilla.kernel.org/show_bug.cgi?id=2
http://bugme.osdl.org/show_bug.cgi?id=2554
--- Additional Comments From [EMAIL PROTECTED] 2004-04-20 20:09 ---
The following patch removes the i386 cmpxchg from being defined again:
diff -Nur linux-2.4.26/drivers/char/drm/drmP.h linux-
2.4.26.patched/drivers/char/drm/drmP.h
--- linux
32 matches
Mail list logo