[EMAIL PROTECTED] wrote:
I've put up a Guide to debugging DRI installations at
http://www.linuxvideo.org/gatos/dri-debug.html
I wonder if this is really necessary? Wouldn't it be better to point at the
DRI user guide and improve it if needed? We all know the bad aspects of
duplication...
Hello!
Will using the matrox framebuffer cause me problems trying to use DRI?
I have:
X410
Matrox G450
Have tried everything and still can't get any OpenGL-apps to run. (The apps are
linked to the correct libGL, libGLU; DRI is enabled according to the X-log and
Glxinfo). Gears hangs the
On Thu, 21 Jun 2001, Michel Dänzer wrote:
[EMAIL PROTECTED] wrote:
I've put up a Guide to debugging DRI installations at
http://www.linuxvideo.org/gatos/dri-debug.html
Excellent!
I wonder if this is really necessary? Wouldn't it be better to point at the
DRI user guide and improve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Today, Gareth Hughes wrote:
Brian Paul wrote:
I've looked into this a bit more. Looks like the token
RADEON_MAX_TEXTURE_LEVELS is incorrectly defined to be 11 in
the current driver. It should be 12 in order to support 2Kx2K
textures. It
Philip Willoughby wrote:
Just out of interest, does 2kx2k texture support mean 2048x2048 or 2050x2050
(for borders?).
I have never seen a graphics chip accelerate texture borders. All the
Mesa-based drivers fall back to software rendering if you have them.
-- Gareth
Gareth Hughes wrote:
Brian Paul wrote:
I've looked into this a bit more. Looks like the token
is incorrectly defined to be 11 in
the current driver. It should be 12 in order to support 2Kx2K
textures. It looks like this can safely be changed from 11 to 12
without a kernel module
Brian Paul wrote:
That's what I was worried about. Changing the SAREA layout would
require bumping the version number. However, I've grepped all the
Radeon sources and it doesn't appear that RADEON_MAX_TEXTURE_LEVELS
is used at all in the SAREA or kernel code. I'll have to do some
I've been banging my head on this for too long without much luck. Karl,
can you send me (and me only) a snapshot of Mesa/demos/texenv running
with your patch applied? I'm getting incorrect rendering no matter what
I do, and Tribes2 is still broken (the landscape is clearly being
textured
Geoff Reedy wrote:
On Wed, Jun 20, 2001 at 01:50:03PM -0400, Karl Lessard [EMAIL PROTECTED] said
There is a AGP-to-PCI bridge on a G450 PCI. The thing is that you have a
AGP chip on your PCI card , and the bridge is used to connect the chip
on a PCI bus. But I don't know why DRI only
From: Karl Lessard
Subject: Re: [Dri-devel] GL_DECAL and texture corruption fixes for MGA driver
Date: Mon, 18 Jun 2001 08:28:46 -0700
You're right, mgaConvertTexture needs to handle RGB5_A1 as a special
case. But there is no need to redefined MGAPACKCOLOR1555, check
MGAPACKCOLOR555.
So
Brian Paul wrote:
No need to bump version number as this value isn't used anywhere in
the kernel module.
Speaking of a version bump, it looks like the _major_ of the r128 driver in
the trunk needs to be bumped (see discussion on the Xpert list). I'm reluctant
to do it myself as I don't
On Thu, 21 Jun 2001, Jens Owen wrote:
Vladimir,
Your page looks very helpful. Thanks for putting it together. The only
comment I have is regarding your first miscellaneous comment:
While hardware 3d is active nothing except your Xserver should be
accessing your video card - or your
On Thursday 21 June 2001 14:55, Michel Dänzer mentioned:
Jordan Crouse wrote:
I am running Linux 2.4.5-ac16 and XFree86 4.1.0 with an ATI Rage Mobility
LF Rev 2 chipset (Renderer string: Mesa DRI Rage 128 20010405 M3 AGP 2x
x86/MMX/SSE) and I am getting the the old familiar black flicker
I have made the correction - please let me know if I missed anything.
Vladimir Dergachev
___
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
Brian Paul wrote:
Michel Dänzer wrote:
Brian Paul wrote:
No need to bump version number as this value isn't used anywhere in
the kernel module.
Speaking of a version bump, it looks like the _major_ of the r128 driver
in the trunk needs to be bumped (see discussion on the
On Thu, 21 Jun 2001, Frank Worsley wrote:
I put the page together after trying to walk thru several
people with buggy Redhat installs. For some reason things like ldd or
strace are not as well known to new users as they should be.
The problem here is not so much that people don't know
[EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2001, Jens Owen wrote:
Vladimir,
Your page looks very helpful. Thanks for putting it together. The only
comment I have is regarding your first miscellaneous comment:
While hardware 3d is active nothing except your Xserver should be
I got annoyed that radeon really didn't work too well for me so I
installed voodoo back to my conputer. UT seems to be working somewhat but
hangs on occasion. Here is what I get from running UT in gdb.
---
Possessed PlayerPawn: TMale1 Entry.TMale2
Initialized moving brush tracker for
At the moment I'm open for suggestions that my motherboard is like
seriously fucked up. :(
I'd like to remove previous comment from the book... ;)
played UT in w2k for 3hours without any problems. Hence I deduct it is
probably something with tdfx_dri.so I guess.
Not sure what has gone broken
Hello fellow Linux users!
I am a long time linux user (well long here is a relative term, I guess,
but I have been using linux since RH 5.2, so I guess that qualifies me as a
non-newbie at least :-), but I only recently got involved in 3d design and
programming (using primarily blender and
The r128 support worked fine for us (after the usual install
miseries) on an Inspiron with a Rage Mobility M3 AGP2x which we
acquired about 10 months ago.. don't know about the M4 though.
Mike
1) OK, I am still confused. Can someone please tell me is the DRI support
working for the
I can verify the unreal engine issues, though I have not had the time to
test mesa-3-5-branch, if needed I can also try to help pin down what
unreal is doing which nothing else does. (I'm seeing it in both the Rune
and DeusEx ports, other problems with the ports have kept me busy
debugging things
1) OK, I am still confused. Can someone please tell me is the DRI support
working for the above-mentioned video card or not?
I have had 2D flicker issues with the standard 4.1.0 binary build from the
XFree86 folks (see previous messages). However, I have heard from several
people who have
On Tue, 26 Jun 2001, Rahul Karnik wrote:
When 4.1.0 was released, the downloadable binary
package was discontinued. Now I understand the
rationale behind this, but would it be possible to
keep a 4.1.0 level snapshot available for download?
The reason I ask is that as of now, downloading and
Iain Thomas wrote:
The CVS command to get the os-support dir is something like:
cvs -z3 co -r xf-4_1_0 xc/programs/Xserver/hw/xfree86/os-support
Assuming CVSROOT already set as per the cvs instructions pages. For the
DRI tree, it starts xc/xc/programs... Not xc/programs.
Minor comment:
On Wed, 27 Jun 2001, Michel Dänzer wrote:
Date: Wed, 27 Jun 2001 09:34:50 +0200
From: Michel Dänzer [EMAIL PROTECTED]
To: Iain Thomas [EMAIL PROTECTED]
Cc: Rahul Karnik [EMAIL PROTECTED], [EMAIL PROTECTED]
Content-Type: text/plain; charset=iso-8859-1
List-Id: dri-devel.lists.sourceforge.net
Thanks for all the help. For some reason the DRI
module from 4.1.0 did not work with the DRM module I
compiled from CVS (I got a [drm]DRI version=4,
expected 3 message). With cable and my relatively
fast computer I just compiled X from DRI CVS and fixed
it.
Now my request is not for myself, but
Janne Pänkälä wrote:
At the moment I'm open for suggestions that my motherboard is like
seriously fucked up. :(
I'd like to remove previous comment from the book... ;)
played UT in w2k for 3hours without any problems. Hence I deduct it is
probably something with tdfx_dri.so I guess.
I found the problem. I just checked in a two-line fix for the tdfx driver
on the DRI trunk. UT's textures look fine to me now.
Yes this fixed the problem. Thanks you.
there was one hang but on second try it worked like a charm and I managed
to play even when new textures needed memory :).
Hello
I have a Matrox G450 card on a RH7.1 Linux PC, XFree 4.0.3, and the
latest driver from Matrox (v1.3.0)
When running a OpenGL app., some strange things happen : if you move the
OpenGL window, the application does not crash, but the GL context does
not move, the rendering happens as if the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SuSE have an RPM at
ftp://ftp.suse.com/pub/suse/i386/X/XFree86/XFree86-4.1.0-SuSE/suse71/DRI/km_drm-4.1.0-6.i386.rpm
which has the sources for the kernel modules in it. I am at work ATM so I
cannot be sure if it will compile and install them itself
I have finally been successful at getting X 4.1.0 and DRI working on my ATI
rage Mobilty 128 M3. It would appear that the current ATI DRM module being
distributed in 2.4.5-ac13+ (or maybe even older) is not working as well as it
should for 2D drawing (classic flash problems).
I rebuilt my
Hi,
First my config:
Slackware 7.0 with Kernel 2.4.4 and XFree 4.1.0 running at Matrox G450.
Some time ago I reported problems with Heretic2. Since some days I try to trace
down the problem using the x410-sources.
Heretic2 quits normally with this error message:
mga_get_buffer_ioctl: flush
I have recently upgraded my machine to a Athlon 1.2GHz+MSIK7Master (266DDR
FSB) from a K6-2 I have kept the same video card G400MAX which has been
working well in my old set up for some time.
I seem to have found a problem I have been unable to track down as yet and
was wondering if anyone
I have recently upgraded my machine to a Athlon 1.2GHz+MSIK7Master (266DDR
FSB) from a K6-2 I have kept the same video card G400MAX which has been
working well in my old set up for some time.
I seem to have found a problem I have been unable to track down as yet and
was wondering if anyone
I have recently upgraded my machine to a Athlon 1.2GHz+MSIK7Master (266DDR
FSB) from a K6-2 I have kept the same video card G400MAX which has been
working well in my old set up for some time.
I seem to have found a problem I have been unable to track down as yet and
was wondering if anyone
I have recently upgraded my machine to a Athlon 1.2GHz+MSIK7Master (266DDR
FSB) from a K6-2 I have kept the same video card G400MAX which has been
working well in my old set up for some time.
I seem to have found a problem I have been unable to track down as yet and
was wondering if anyone
Hi!
I have a Intel STL2 mainboard, with integrated Ati Rage 3D IIC video card.
Card is not AGP slotted, it is PCI (integrated) card.
The r128.o kernel modul shall to support PCI Ati cards in future ? I see
the code, and i look some PCIgart requests, but the code not run without
agpgart module.
[EMAIL PROTECTED] wrote:
I have a Intel STL2 mainboard, with integrated Ati Rage 3D IIC video card.
Card is not AGP slotted, it is PCI (integrated) card.
IIRC, PCI is not the problem, but the Rage IIC is so old that it's
not very useful as a 3D accelerator anyway and there never was and
Hi,
IIRC, PCI is not the problem, but the Rage IIC is so old that it's
not very useful as a 3D accelerator anyway and there never was and
probably never will be a driver for it (except if you write it). The
I dont want 3D acceleration support for may card, i enought for 2D
On Fri, 29 Jun 2001, Philip Willoughby wrote:
You can compile agpgart into a kernel with no agp slots just fine, this wil fix
the unresolved symbols. Whether it will make your card work is another matter,
but it's a start.
??? It shall be work ?
I try:
:~# modprobe agpgart
Linux agpgart
On Fri, 29 Jun 2001, Malte Cornils wrote:
[EMAIL PROTECTED] wrote:
I have a Intel STL2 mainboard, with integrated Ati Rage 3D IIC video card.
Card is not AGP slotted, it is PCI (integrated) card.
IIRC, PCI is not the problem, but the Rage IIC is so old that it's
not very useful as a 3D
On Fri, 29 Jun 2001 [EMAIL PROTECTED] wrote:
Date: Fri, 29 Jun 2001 17:00:31 +0200 (CEST)
From: [EMAIL PROTECTED]
To: Malte Cornils [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Id: dri-devel.lists.sourceforge.net
Subject: Re: Ati Rage 3D IIC with PCI
Jordan Crouse wrote:
I have finally been successful at getting X 4.1.0 and DRI working on my ATI
rage Mobilty 128 M3. It would appear that the current ATI DRM module being
distributed in 2.4.5-ac13+ (or maybe even older) is not working as well as
it should for 2D drawing (classic flash
On Sat, Jun 30, 2001 at 06:29:13AM -0500, [EMAIL PROTECTED] wrote:
1) is anyone still maintaining the Glide source/CVS ?
Not really.
2) anyone noticed problems while compiling Glide3 for Voodoo5 with debug
on?
I get this error with the GL apps i tried (gears, Quake3, mine), except
FROM: Daryll Strauss
DATE: 06/30/2001 07:25:41
SUBJECT: RE: [Dri-devel] couple of questions about Glide3 ...
On Sat, Jun 30, 2001 at 06:29:13AM -0500, EMAIL: PROTECTED wrote:
1) is anyone still maintaining the Glide source/CVS ?
Not really.
Too, sad ;-)
2) anyone noticed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just got done compiling a copy of the latest DRI CVS (from today,
around 5PM Central Time), and went to run glxinfo to make sure DRI was
still working, and I'm presented with this error message:
glxinfo: error in loading shared libraries:
Thilo,
You make it sound as though you propose an easy and obvious
solution with no adverse side-effects.
Such is not the case.
You are implicitly assuming a compatibility model in which
any newer version of r128.o is GUARANTEED to work with any
older version of the DRI. In ideal world that
On Sun, 8 Jul 2001, Mike Westall wrote:
Thilo,
You make it sound as though you propose an easy and obvious
solution with no adverse side-effects.
Such is not the case.
You are implicitly assuming a compatibility model in which
any newer version of r128.o is GUARANTEED to work with
In /opt/dri/build/xc/lib/GL/mesa/src/drv/radeon/Imakefile.inc
#if BuildXF86DRI
DRI_DEFINES = GlxDefines -DX_BYTE_ORDER=ByteOrder
DRI_INCLUDES = -I$(GLXLIBSRC)/dri \
-I$(GLXLIBSRC)/glx \
-I$(INCLUDESRC) \
-I$(INCLUDESRC)/GL \
Well that's for mesa-3.5 branch in CVS.
On Sun, Jul 08, 2001 at 06:34:07PM -0400, Zilvinas Valinskas wrote:
In /opt/dri/build/xc/lib/GL/mesa/src/drv/radeon/Imakefile.inc
#if BuildXF86DRI
DRI_DEFINES = GlxDefines -DX_BYTE_ORDER=ByteOrder
DRI_INCLUDES = -I$(GLXLIBSRC)/dri \
Imakefile.inc fixes ...
--
Zilvinas Valinskas
Index: xc/xc/lib/GL/mesa/src/drv/ffb/Imakefile.inc
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/ffb/Imakefile.inc,v
retrieving revision 1.2.6.2
diff -u -r1.2.6.2 Imakefile.inc
Zilvinas Valinskas wrote:
just compiled installed XFree 4.1 + mesa 3.5 (mesa-3-5 trunk from CVS).
swoop@tweakster:~$ ./gears
5544 frames in 5 seconds = 1108.8 FPS
5600 frames in 5 seconds = 1120 FPS
5602 frames in 5 seconds = 1120.4 FPS
5606 frames in 5 seconds = 1121.2 FPS
5599 frames
Zilvinas Valinskas wrote:
swoop@tweakster:~$ ./isosurf
7179 vertices, 7177 triangles
:\ that's all I get :) Looks neat ...
Hit 'b' to run the benchmark. Use the source, Luke...
-- Gareth
___
Dri-devel mailing list
[EMAIL PROTECTED]
Hi all,
I just recently subscribed to this listserv (about 24 hours ago!), and I
think that I have just found a bug - I hope that this is the correct
forum for this! If not, please direct me to where I can post this.
I ran the isosurf program that someone else mentioned earlier today and
it
The configuration is following:
i810 + 2.4.3 + agpgart + 4.1.0 + kmod from 4.1.0
I have the following problem:
when drm loads (from /var/log/XFree86.0.log) it reports that
it can't register IRQ handler due to another device that have taken it.
it's true that lspci shows that both my video
Hi guys!
I've had lot of other things to do in the past weeks so I couldn't work
on mach64. I've still problems to compile the trunk with Manuel's
patches. I haven't had time to track this down, so I decided to post my
changes of mach64_dma.c which I have made in my copy of the
El Sáb 22 Sep 2001 14:54, escribiste:
Hi guys!
I've had lot of other things to do in the past weeks so I couldn't work
on mach64. I've still problems to compile the trunk with Manuel's
patches. I haven't had time to track this down, so I decided to post my
changes of mach64_dma.c which I
Manuel Teira wrote:
It's nice to hear about you again. I'll test the changes you've made on my
machine ASAP. BTW, I've take a fast look about the way you are allocating the
memory for the test:
struct pci_pool *pool;
void *cpu_addr_table, *cpu_addr_data;
void *cpu_addr_table,
El Sáb 22 Sep 2001 17:03, escribiste:
Manuel Teira wrote:
have a look at kernel-source-dir/Documentation/DMA-mapping.txt
OK. Thanks for the help.
there's the explaination about this API. I think we should use this if
anybody hasn't any objections.
pci_pool_create is specified:
pool =
Michael Zayats wrote:
The configuration is following:
i810 + 2.4.3 + agpgart + 4.1.0 + kmod from 4.1.0
I have the following problem:
when drm loads (from /var/log/XFree86.0.log) it reports that
it can't register IRQ handler due to another device that have taken it.
it's true that
El Sáb 22 Sep 2001 18:12, escribiste:
Manuel Teira wrote:
Then, I closed my eyes and fired 'gears'. Well, it didn't lock my
machine, the gears window only contained garbage, but the program was
running, and saying:
1786 frames in 5.002 seconds = 357.057 FPS
1736 frames in 5 seconds =
Hi,
This is re Andreas Karrenbauer's prob.. perhaps it's a bit off topic, but
it might help...
Have you tried logging in via SSH and killing off and starting X via that?
I have had a fair degree of success restoring graphics mode that way
(though text mode stays hosed).
As I said, I don't know
El Sáb 22 Sep 2001 19:08, escribiste:
Manuel Teira wrote:
El Sáb 22 Sep 2001 18:30, escribiste:
You can pass an argument to isosurf to tell it to render only 100
triangles (isosurf -100) - another good option, and you can get it to
render more by moving with the arrow keys.
On Sat, 22 Sep 2001, Manuel Teira wrote:
El Sáb 22 Sep 2001 19:08, escribiste:
Manuel Teira wrote:
El Sáb 22 Sep 2001 18:30, escribiste:
You can pass an argument to isosurf to tell it to render only 100
triangles (isosurf -100) - another good option, and you can get it to
Hi all,
I've looked at the documentation, and it's odd, it seems like nobody is
mentioning the Mach64 GB. It might be this is simply named wrong in my
bios, and it seems to run the same as other cards.
Here's my PCI entry: pci bus 0x1 cardnum 0x00 function 0x: vendor
0x1002 device 0x4742
1) theoretic: Why at all drm needs IRQ i.e. does AGP sends info back to
the driver?
The irq is removed in the mesa-3-5 branch. If you feel ok about
downloading,
compiling and installing a cvs branch, you might be able rid of the
problem
that way. However, I don't know if Jeff has left
1) theoretic: Why at all drm needs IRQ i.e. does AGP sends info back
to
the driver?
The irq is removed in the mesa-3-5 branch. If you feel ok about
downloading,
compiling and installing a cvs branch, you might be able rid of the
problem
that way. However, I don't know if Jeff
El Dom 23 Sep 2001 04:50, escribiste:
According to the register ref. (p.4-26), GB means BGA package, AGP:
both 1x and 2x). I have an LT Pro, which has LB in the device ID.
This is in the CFG_CHIP_TYPE in CONFIG_CHIP_ID. There's also a class,
foundry ID, and major/minor numbers in
TAU wrote:
Can you direct me on what should I do to get a cvs version working:
Where cvs is
what X11 parts should I compile and where to install
should I compile anything except i810 kmod for the kernel?
I can't find any ready RPMs for Mesa 3.5, should I take it directly from
Mesa site
Michael Zayats wrote:
1) theoretic: Why at all drm needs IRQ i.e. does AGP sends info back
to
the driver?
The irq is removed in the mesa-3-5 branch. If you feel ok about
downloading,
compiling and installing a cvs branch, you might be able rid of the
problem
that way.
Turning off the irq in hardware won't help you, you need to have a kernel
module that doesn't rely on the irq. The i810 kernel module *will* share
irqs
with other devices, but it sounds like your network card won't.
The message I get is:
(II) I810(0): [drm] failure adding irq handler, there
So I thought that I'd finally try the DRI under FreeBSD (I recently
upgraded an old installation to 4.4rc4). Well, it seems that I've hit a
rough spot. Though it isn't a huge deal, it'd be nice to get it working.
Anyway, from the xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel
Are you using the bsd-2-0-0 branch ?
If not, then you should be.
Alan.
On Tue, Sep 11, 2001 at 08:52:54AM -0400, Adam K Kirchhoff wrote:
So I thought that I'd finally try the DRI under FreeBSD (I recently
upgraded an old installation to 4.4rc4). Well, it seems that I've hit a
rough spot.
Well, trunk kernel modules won't compile, but bsd-2-0-0-branch will usually
compile and run most of the cards (rage128 is really slow, and i810 is not
supported). I have patches for compiling the kernel modules, and a port of
them, up at my webpage: http://gladstone.uoregon.edu/~eanholt/dri/
On Tue, Sep 11, 2001 at 09:19:42AM -0700, Eric Anholt wrote:
Well, trunk kernel modules won't compile, but bsd-2-0-0-branch will usually
compile and run most of the cards (rage128 is really slow, and i810 is not
supported). I have patches for compiling the kernel modules, and a port of
Do you need new leads for your business?
Do you need increased Internet Exposure?
Thousands join the Internet daily..and there are MILLIONS!
Have you reached the THOUSANDS of NEW internet users?
Search Engines: work IF you're in the TOP 20 among MILLIONS
On Tuesday 11 September 2001 11:03 am, A Fricking Spammer wrote:
Do you need new leads for your business?
Do you need increased Internet Exposure?
No, I need fscking spammers like you to *go* *AWAY*!!!
Grumble grumble...
--
Matthew Cline| Suppose you were an idiot. And suppose
Can someone send a copy of the white papers/references for the 3dfx
VSA-100/Napalm my way? Were they even ever released openly? I know
that the said document for Avenger (Voodoo3) were, and they used to be
availible on 3dfx's website. Unfortunately, though, this website is no
longer up, so I
On Tuesday 11 September 2001 11:03 am, A Fricking Spammer wrote:
Do you need new leads for your business?
Do you need increased Internet Exposure?
Isn't Internet Exposure a Micro$oft product? Go expose to their mailing
list.
___
Dri-devel
On Tue, Sep 11, 2001 at 10:04:14PM -0500, Steven Walter wrote:
Can someone send a copy of the white papers/references for the 3dfx
VSA-100/Napalm my way? Were they even ever released openly? I know
that the said document for Avenger (Voodoo3) were, and they used to be
availible on 3dfx's
On Wednesday 12 September 2001 10:48, you wrote:
Anybody (Brian, Keith?) working on the Mesa-3.5-tree?
I've didn't see any activity for some days/weeks, now.
It would be very nice to see the Mesa-4.0/OpenGL 1.3 stuff comming, soon.
The current Mesa-3.5 stuff crash under UT (all versions)
Hi,
I am developing a linux dri driver for my company.
I get some question about kernel module. Would you
like give me some instruction about dri ?
The following is the question.
1. Before the kernel deal with a ioctl, Can the kernel receive another
ioctl and deal with it?
For
when i am testing new code, which branch ought i to be messing with?
head, mesa-3-5, ???
-jwb
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Fri, Sep 14, 2001 at 10:08:01AM +0200, Gerd Knorr wrote:
Hi,
I've figured why the Rage 128 crashes if the bttv overlay is active (see
http://sourceforge.net/tracker/index.php?func=detailaid=210239group_id=387atid=100387).
Because the r128 driver does 2D acceleration using MMIO
Greetings,
I know this may sound Newbie so im sorry I tired to compile DRI on RH 7.1
and it compiles for around 2
hours the at the very end it says it done and the hangs I have to press ctrl+c to kill
the process. I go back to look at
the log file and no errors are made during
9/14/2001 8:31:46 AM, Nick Hudson [EMAIL PROTECTED] wrote:
gah,
Sorry ignore this I sent the wrong email out . sorry if anyone is bothered :O)
Nick
Greetings,
I know this may sound Newbie so im sorry I tired to compile DRI on RH 7.1
and it compiles for around 2
hours the
Dieter Nützel wrote:
Anybody (Brian, Keith?) working on the Mesa-3.5-tree?
I've didn't see any activity for some days/weeks, now.
Here's the deal. The DRI developers, including myself, have been laid-off
from VA Linux. Today (Friday) is my last day.
There's an effort to relocate us to a
Andrew James Richardson wrote:
I'm sure that everybody has their say on this but would you think of a
company set up so that people donated money in exchange of binary drivers
(source was free of course) for DRI, more like ordered donation than
business really. I for one would be
Gareth Hughes wrote:
I think people need to take a step back and have a think about how much
money it costs to support top-class developers like those work/have worked
on the DRI. We're talking hundreds of thousands of dollars a year. Unless
the IHVs (or other companies) want to support it,
Mark Allan wrote:
So do we give up on open source drivers completely? I'm willing to bet
that there is some way to generate sufficient revenue to fund the DRI. I
don't know what it is, but it would be worth throwing some ideas around
rather than throwing our hands up and saying oh, well.
I'd be willing to donate to support DRI development.
I'd even be willing to donate a substantial amount
assuming it would guarantee some results. Maybe a
project like this would catch the eye of the HW
vendors and prompt them to put more effort into
opensource drivers.
Alex
-
Dear
It would be extremely unfortunate if we have to rely upon in-house
developers writing binary-only drivers for Linux. With a company like
NVIDIA, it really isn't that big of a deal, as they have excellent
drivers under both Windows and Linux. But ATI and Matrox both have poor
Windows
Benjamin Herrenschmidt wrote:
Another point is that binary drivers like NVIDIA are x86 only, which is
a problem for me (PPC) as Apple now bundles their cards with recent
Mac G4s.
Also, despite beeing pretty complete, the r128 driver is experiencing
all sorts of lockups (depending on the
On Friday 14 Sep 2001 11:22 pm, you wrote:
Indeed, this is a problem... Mind you, in the days of the GeForce3 (and it
successors) and Radeon 8500 (or whatever they're calling the R200), who
wants to be stuck maintaining a driver for the r128? Not me...
It's like any other open source
On Friday 14 September 2001 17:06, Gareth Hughes wrote:
Some are saying that Linux on the desktop is already dead...
Really? Somehow, I find that hard to believe with places like Largo, FL
using it on the desktop- I'm of the belief that it's still in its infancy.
Oh, congrats on scoring
On Friday 14 Sep 2001 9:25 pm, you wrote:
Is open source absolutely essential? Personally, I would rather have
binary-only drivers written by the likes of Brian, Gareth, Keith, et.
al. than binary-only drivers written by some faceless unknown.
Binary only drivers, ups and downs.
Ups:
The
Frank Earl wrote:
Some are saying that Linux on the desktop is already dead...
Really? Somehow, I find that hard to believe with places like Largo, FL
using it on the desktop- I'm of the belief that it's still in its infancy.
Again, I don't actually agree with the statement. However,
Frank Earl wrote:
How about all those people without the luxury of upgrading- say laptops
and things like iMacs? Go buy a whole new computer- not an option, when
you think about it. This is not to say you have to be doing it- but
someone ought to be doing something about it. I'm not
On Friday 14 September 2001 21:08, you wrote:
That's fine -- I wasn't suggesting that. But, for the people who can
actually do this job, the r128/G400 isn't terribly interesting anymore.
Isn't the whole open source thing about developers scratching an itch?
Cool. It just came across
501 - 600 of 46322 matches
Mail list logo
