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
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
--- 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 random
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 have
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
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
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
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
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
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. Anything
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
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
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
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
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
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
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
--- 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
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
I wrote:
snip
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.
snip
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
* 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 wrong, idx is
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 checks
--- 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. Later
On Monday 19 April 2004 20:08, Michel Dnzer 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 it
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 they are
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
---
30 matches
Mail list logo
