Vladimir Dergachev wrote:
On Wed, 27 Apr 2005, Keith Whitwell wrote:
Donnie Berkholz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir Dergachev wrote:
Can someone enlighten me as to what is the license of R200 Mesa
driver ? Also, what is the usual (accepted, preferred, etc..) licen
On Fri, 16 Jul 2004, Alex Deucher wrote:
>Date: Fri, 16 Jul 2004 09:06:26 -0400
>From: Alex Deucher <[EMAIL PROTECTED]>
>To: Dave Airlie <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=US-ASCII
>X-BeenThere: [EMAIL PROTECTED]
>Subject: Re: i830 driver status..
>
>On T
On Sun, 11 Jul 2004, Patrick McFarland wrote:
>Date: Sun, 11 Jul 2004 02:32:00 -0400
>From: Patrick McFarland <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=us-ascii
>X-BeenThere: [EMAIL PROTECTED]
>Subject: Re: [Bug 849] [PATCH] Fix DRI pagesize assumptions in radeo
On Fri, 26 Mar 2004, Mike A. Harris wrote:
>In XFree86 4.3.0, and also in current X.org X11, in the file:
>
> xc/lib/GL/mesa/src/drv/r200/r200_pixel.c
>
[SNIP]
>I'm unfamiliar with this particular code, however it seems that
>the same calculation being done in r200T
sk;
GLuint cpp = rmesa->r200Screen->cpp;
GLint size = width * pitch * cpp;
I'm unfamiliar with this particular code, however it seems that
the same calculation being done in r200TryDrawPixels() would be
valid for r200TryReadPixels().
Does the patch I've attached look correct?
On Fri, 5 Mar 2004, Felix [ISO-8859-1] Kühling wrote:
>Date: Fri, 5 Mar 2004 16:47:50 +0100
>From: "Felix [ISO-8859-1] Kühling" <[EMAIL PROTECTED]>
>To: Alex Deucher <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Content-Type: text/plain; charset=US-ASCII
>Subject: Re: Fw: Re: Sava
myself, or
other admins in realtime, and/or you can email
[EMAIL PROTECTED] for asynchronous admin requests,
and we'll try to fix up whatever is broke ASAP.
Hope this helps,
TTYL
--
Mike A. Harris
---
SF.Net is sponsored by: Speed Start Your
I think it would be infinitely
beneficial for both projects to have closer integration for
numerous reasons, and would foster closer collaboration,
between the DRI and the core, since the two owuld essentially
become one and the same.
It is probably a bit premature for now to make any solid
decisio
here isn't.
>
>Thats as far as I've gotten so far.
>
>Is there anything else I should be looking at?
oprofile perhaps might help.
--
Mike A. Harris
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and d
e into
>> the
>> trunk where it may get merged up to XFree86 is such a good idea :-)
>
>
>As I recall it's just a matter of changing a config option to a
>different default. should be trivial.
Just needs to be added to DevelDRIDrivers in xfree86.cf
--
Mike A. Harr
ts work out
of the box with one single unified driver set.
--
Mike A. Harris
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. Febru
;
>I think this is about the minimal fix needed. I'm not entirely happy
>with the limits picked, especially for spans, but maybe someone with
>an R128 can verify it is ok, or change the code to loop each chunk
>of pixels/span data.
If nobody objects to Alan's security patch, I&
uestions you might have about radeon hardware operation et al.
IMHO, it's best to approach this from a direct concrete angle of
a specific problem though, rather than a general problem of PCI
not working properly and wanting to go over every inch of t
i
>Subject: Re: Radeon PCI API
>
>Your best bet, if you can find one, is a fireGL 8800. It's basically
>an overclocked 8500. barring that the 8500's and 9100's are the next
>fastest.
The 8800 is a faster R200 based board. It's not overclocked
however.
--
abug".
Please use dri-users and/or dri-devel for such discussions, not
bugzilla.
--
Mike A. Harris
---
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apach
ng either of these, ensures rpm is happy, and that there
shouldn't be any libGL conflicts. I made Mesa-libGL a separate
subpackage to make replacing libGL easier for people to do.
Hope this helps people to avoid such libGL probs.
TTYL
--
Mike A. Harris
-
ed again later
depending on user feedback, etc.
TTYL
--
Mike A. Harris
---
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help u
sourceforge CVS
repository is completely obsolete. Don't use it.
The DRM doesn't create device nodes on the filesystem (that would
be totally insane). The X server itself creates /dev/dri/card*
as needed.
--
Mike A. Harris
---
Thi
elming majority of users out
there.
The proper fix is to fix both problems, not substitute one for
the other - although the latter is probably fine for homebrew
systems.
--
Mike A. Harris
---
This SF.net email sponsored by: Enterprise Linux Forum Co
te zlib
sources and link statically to their own copy. Bad juju.
--
Mike A. Harris
---
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US pro
ee people using
both AGPMode and AGPSize in their config files. If they're
having problems, I'll have them remove those lines at least
first. As long as the options aren't intended for end users,
this should be sufficient.
Thanks Michel.
--
Mike A. Harris
--
On Sun, 14 Sep 2003, Michel [ISO-8859-1] Dänzer wrote:
>Date: Sun, 14 Sep 2003 13:29:07 +0200
>From: "Michel [ISO-8859-1] Dänzer" <[EMAIL PROTECTED]>
>To: Mike A. Harris <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=UTF-8
>S
w they're aliases too, to avoid
>> confusion also. ;o)
>
>I'll gladly do so if you show me where it's documented.
radeon manpage
--
Mike A. Harris
---
This sf.net em
sending
>out yours. :)
I read/respond serially usually. Might want to update docs to
show they're aliases too, to avoid confusion also. ;o)
--
Mike A. Harris
---
This sf.net email is sponsored by:T
me by
default in a future X release, without knowing that it doesn't
work.
I think when things like this are changed, it is important to
both document it widely, and also provide a backward
compatibility mechanism. Otherwise it confuses users, and can
cause tech support problems.
I see t
Option "AGPMode" "4"
>> Option "AGPSize" "128"
>
>BTW, I renamed this to "GARTSize" in current DRI CVS.
Is AGPsize an alias? Or when people upgrade in the future will
their configuration break if it is using AGPSize?
--
Mi
Pv6 to not be unconditional, but
if it did get fixed, I must have missed seeing the checkin.
If the issue is still present however, then anyone compiling
XFree86 CVS and using it must have IPv6 on their system, even if
they don't use it.
Hope this helps.
TTYL
--
Mike A. Harris
-
think it probably will, there shouldn't really be any
problems. How many people out there use DRI anoncvs?
We can also set up cvsup, and recommend it to people instead of
CVS, which can help out significantly also. I'll install cvsupd
on the machine so it can be enabled when needed.
-
EMAIL PROTECTED] their ssh DSA keys,
and let us know what is needed. I can set up user accounts, and
provide admin access to those who need it as well.
rsync/cvsup/etc. are either installed already or can be ready to
go in short order also. I'll
My original send didn't have dri-devel on it. Oopsie.
--
Mike A. Harris
-- Forwarded message --
Date: Tue, 2 Sep 2003 14:35:54 -0400 (EDT)
From: Mike A. Harris <[EMAIL PROTECTED]>
To: Keith Whitwell <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTE
e it
is probably a DRM issue that needs a few pokes with a stick.
I'm going to try to reproduce it on ia64 also to see if it is
likely a 64bit issue or just an architectural oddity. Either is
possible. I haven't tried 4.3.0 on Alpha yet, but that might be
a good idea too.
Take car
only
permit subscriber posting, and while the spam load on those lists
is much less than dri-devel, I don't mind helping keep the admin
queue empty. My sourceforge name is "mharris", feel free to add
me to any/all of the DRI lists, just let me know which one's I'm
on
s present on AGP cards.
It is, and should work on AGP cards just like a PCI card, with
"ForcePCIMode".
--
Mike A. Harris
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the plane
s junk spam. There may be the opportunity for false positives,
but in practice over the years, I've yet to see any with my mail
load. Different people's mail usage may vary however...
Hope this helps.
--
Mike A. Harris
---
Th
if the decision stands to no longer field new bugs there, it would
>still be nice if someone cleaned out the bugs there that are no longer
>relevant.
Feel free.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engi
es up, and you
can enter a comment directly into bugzilla. Even pine can do
this easily.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This SF.net email is sponsored by: Does
strictly my own personal opinion, and particularly as
applies to large projects such as XFree86/DRI/etc.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This SF.net email is sponsored by:
7200, or bumped the chip
revision, then they might be able to be distinguished, however
I'm not sure it matters since programatically they're identical.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
-
sonally touched one. I do know however that all boards
containing the "Radeon QD" chip do in fact have a useable TCL
unit on them.
Hope this helps to clarify the R100 line a bit.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red H
is running in the 64bit mode, XFree86 uses
x86emu to power up the video BIOS. int10 works good enough that
you don't even know it's being done via CPU emulation. ;o)
Hope this helps.
TTYL
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintain
nction won't do anything to make the driver easier to navigate.
Agreed. Also, there are IMHO large enough portions of code that
are common to both the r128 and radeon driver at least, which
could be moved to a common shared file. Unless it's objected to,
I'll be investigat
RI-oriented name, and belongs in radeon_dri.c
With several people in disagreement with you though, I guess it
might be a decision perhaps that should fall more into the lap of
the driver maintainer or project lead or somesuch.
--
Mike A. Harris ftp://people.redhat.com/mharris
cation based on? Is it based on
performing a PreInit operation, or is it a DRI function that does
preinit? I see it as the former as it is called from
RadeonPreInit.
IMHO, the names of functions and the file they are located in
should be based on the functionality that they are providing
an a bug. I don't generally run tuxracer
ever, so I never really noticed it before. ;o) I think this can
be written off as a tuxracer bug now.
Thanks.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
--
this on 64bit archs
with tuxracer to help determine if it might be a bug in the game,
or a bug on the X side of things.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
to provide documentation that is technically accurate
as per ATI specifications, not bend them on a whim. Radeon VE,
is Radeon RV100, regardless of wether the chip works like a R100
as far as DRI is concerned or not.
Why make confusion?
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Syste
n 9200 Pro,
Radeon 9600 Pro, and Radeon 9800 Pro
Radeon 9200 Pro == RV280
Radeon 9600 Pro == R300
Radeon 9800 Pro == R300
Just thought I'd post this to help improve the accuracy and
completeness of that Radeon page.
Take care,
TTYL
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Syst
, {0}, FALSE },
The existing options seem to follow the naming pattern of having
the macro named the same thing as the config file option, only
uppercased with word breaks turned into underscores, so if you
choose the config file option "ZBufferFormat", then it would
be consist
add an entry like
>
> { OPTION_DEPTH_SIZE, "DepthBits", OPTV_INTEGER, {0}, FALSE },
One of the following would be more consistent with option naming:
{ OPTION_DEPTH_SIZE, "DepthSize", OPTV_INTEGER, {0}, FALSE },
{ OPTION_DEPTH_BUFFER_SIZE, "DepthBufferSize", O
On 4 Mar 2003, Tom Hosiawa wrote:
>People have been mentioning the Voodoo specs are available but I've
>googled for them and found nothing, anybody know where they are???
http://www.medex.hu/~danthe/tdfx
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Enginee
to discourage your effort. Just trying to provide
what I believe to be a realistic expectation right now all things
considered.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
lace the card(s) with newer hardware that is already
supported by DRI. Unless someone has 1000 of these cards in a
lab or somesuch perhaps.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
ers (including
core DRI members, which I think is critically important), or if
some company funded the development, that such docs would be
forthcoming. Again, just my assumption. Time will tell.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red
On Mon, 3 Mar 2003, Ian Molton wrote:
>> You can get
>> back now to your "dri-has-no-docs-and-developers/ihvs-are-elitists"
>> speech for all I care.
>
>No thanks. I'll just continue reverse engineering my e740.
e740, or i740? AFAIK, i740 has pu
case. It always seems to be the people who don't even
know how to write helloworld.c that are the ones who complain
about a vendor like ATI not providing them with hardware
documentation that they couldn't do anything but make paper
airplanes out of anyway.
$0.02
ir choosing, for
not providing them to the world, is more likely to dry up access
to specs for _EVERYONE_, and make binary only drivers the only
way of getting modern hardware to work.
In other words, I believe that whining about these certain
realities, is equivalent
I think it oculd be broken down much
finer than that. The benefits IMHO would be large.
>The DRI tree has close to 10,000 files in it right now
>and DRI isn't even a complete X tree. That's an awful
>lot of code to read and understand as a singl
r at least
under some form of NDA to developers willing, able, and capable
of working on support. If companies don't however, that is their
choice of course, and to some degree I can also respect that.
Their hardware may possibly however not be supported at all by
open source operating sys
as well. I dunno how far he got, but I've been
meaning to ask.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek he
t hardware vendors aren't even interested in this so it
would be pointless. I highly doubt that any unpaid volunteers
are anxious to contribute to making the project irrelevant, and I
highly doubt anyone is out there ready to pay to have something
like that done either.
--
Mike A. Harri
ietary solution. It neither helps nor hinders the DRI
project really.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This sf.net email is sponsored by:ThinkGeek
Welcome to ge
stand the various complex webs of legal
issues such vendors may face due to licensing of patents, cross
licensing agreements and other legal issues, and I respect their
positions even though it would please me greatly more than
anything to see all s
aten to
>death and is irrelevant to this thread.
>
>My point was/is that without NVIDIA or ATI using the DRI
>infrastructure it is doomed to fail.
Well... for starters ATI *is* using the DRI infrastructure.
Does that mean that you think DRI is doomed to success now?
--
Mike
em for what they do give us, and politely
request things of them that are realistically something they
might be willing to, and legally able to provide us in the
future, rather than a nonrealistic white card, which they're not
likely to be legally able to do.
Just my thoughts.
--
Mike
f eye
candy to the masses of computer users out there. If someone
wants to got ahead and implement those features, sobeit. None of
us have to use them if we don't want to. It at least provides
those who do want them, with the opportunity to have them.
--
Mike A. Harris
ike's
DRM".
>So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ?
I do not decide what DRM code is used in DRI-CVS, nor in
XFree86-CVS, nor in the Red Hat kernel, Linus' kernel, Alan's -ac
patches, or any other place.
I package up XFree86 itself, not th
The DRI meeting on #dri-devel on irc.freenode.net is underway.
This is a reminder in case y'all forgot. ;o)
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This sf.net
interested in reading it.
>> We'll keep the Subject line the same for your benefit.
>
>Really, it doesnt seem to be your list. I'd love to see the contract
>with sourceforge guaranteeing that.
Regardless, I speak my mind freely, and will continue to do so
like ever
ready been wasted ... on "spinning
>wheels".
My point, is that freedom of speech grants me, and anyone else on
this mailing list the right to discuss the issue we are
discussing. You have the right to use procmail to filter out the
discussion when you are no longer interested
Just my thoughts ...
As stated in my previous mail, I do use spamassassin, and as such
I do not have a problem with spam. If you're not interested in
the discussion on despamming, then simply hit DEL on the messages
that do not interest you, and you'll lose no time at all. If
other
list of addresses verfied "GOOD" would be
those who subscribed to the list in the first place.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This s
ok at it.
I do this on our xfree86-list, and it works well. I dunno if
that would be something one of the list maintainers would want to
do or not though. Just a suggestion nonetheless.
On the other side of things, spamassassin rocks. It nails almost
all of my spam. A good 93% to da
/Winex
usage, and the gs register is used by newer glibc for libpthread,
and in the latest glibc for thread local storage (TLS), for
threaded applications at least.
Anything else using these registers is going to have problems.
Nothing should be using fs or gs aside from the above.
I've
gt;pages nor in the XFree86 CVS 'changes.html' document.
>I _did_ expect XFree86-4.3 to be 'up to date' with GATOS and would like to
>see some sort of proof - _before_ downloading tons of source code,
No, GATOS wont be integrated into 4.3.0.
--
Mike A. Harris
ID
changes over from XFree86 CVS head and commit them to DRI-CVS.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition +
rtly, as well as to the trunk.
The cutoff date for XFree86 4.3.0 is today however, so if they do
not sync with Mesa, the changes may not get into 4.3.0.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
discussed with Alan now.
Gah.. typo.. my brain isn't with me today...
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This SF.NET email is sponsored by:
Sourc
sses probably have EV56 or higher in
usage, however I'd also guess most hobbiests have EV5 machines,
so choosing a default instruction scheduling that is
representative of the majority out there would be tricky.
I'm using EV67 here, so either will work for me. ;o)
It might be best to
hat someone should add as an architecture customization IMHO.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM +
better
>> solution.
>
>Well, I'd like to at least understand why *two* reads are necessary.
The first one to flush the ring buffer to the card prior to the
COMMIT_RING(), then the second one to flush the RADEON_WRITE()
inside COMMIT_RING() right away.
--
Mike A. Harris ftp
un on an R128 in Windows well
if at all. I doubt highly it would fare much better with DRI
IMHO.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This SF.NET email is sponsored by:
d prefer to not ship some specialized config format
at all than to ship one that wasn't well thought out, and also
keeps the principle of least surprise.
KISS principle. Also, a bit of open source philosophy - reuse
what exists already, don't reinvent.
$0.02
--
Mike A. Harris
hy bother when libxf86config exists now already and does all of
the above, and has 3 years of history behind it already, being
the backend of xf86cfg?
Seems like a lot of wasted effort to me to reimplement something
like this from scratch. When we wrote our new X config tool, we
just use
st a quick note.. If anyone is using XFree86 CVS trunk,
you should note that the Imake defines have had a s/Katmai/SSE/
done on them. Backward compat with Katmai is present however, so
using HasKatmai should still work, although it is deprecated.
Jus
ith releases back at least as far as
4.1.0 is critically important though.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This sf.net email is sponsored by:
With Great Power,
RM code, people will pull DRM from one of the three locations,
and people will send bug reports, fixes, etc. to 3 locations. If
each of those locations refuse to send patches on to the other
locations, and expect the submitter to do it, the whole thing
breaks down.
What solutions do people think w
to
check all DRM changes into xf-4_2-branch, and xf-4_1-branch as
soon as they're known to be stable and correct. This ensures
that DRM is updated in all releases.
The alternative is having people get a given X release, and then
use the DRM from the most recent X release. Or should they
to specify
something in those fields. Just thought I'd mention that.
My CVS XFree86 RPMs are also always avail at the URL in my sig
for updating from, or for those who want to use them.
HTH
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer
On 12 Dec 2002, Michel Dänzer wrote:
>> /proc/dri shows 0, 1 and 2.
>>
>> 0 -> tdfx 0xe200 (The Matrox)
^^
tdfx == 3Dfx Voodoo 3/4/5 or banshee, it is not Matrox
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFr
lems recur,
I'll try out Charl's patch again, and possibly do a debug session
with Charl and MrCooper again if they're game.
Has anyone else already tested it for hanging?
TTYL
--
Mike A. Harris
---
This sf.net
compiler is running
on. Not sure what that has to do with glibc.
I hope this clarifies any misunderstandings, and misconceptions
that people have about glibc 2.2.9x and glibc 2.3 which is now
officially released. If not, please feel free to discuss the
issu
There's a typo on the Radeon features webpage:
http://dri.sourceforge.net/other/radeon_dri_features.html
At the bottom it has "IcDT Gatos"
Should be iDCT
(Discreet Cosine Transform)
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer
XFree86
that they just need to be treated as if they did.
Note also that ATI has not produced Radeon LE boards. These
cards were produced aparently by a third party in the APAC region
as low cost solutions for that region. ATI has a page on this on
their website somewhere although I don't ha
o this list
every Monday, an hour or so before the meeting, that would
probably be a good idea.
--
Mike A. Harris Shipping/mailing address:
OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer Ontario, Canada
Please apply this to the DRI codebase. Also forwarding it to
XFree86.
--
Mike A. Harris Shipping/mailing address:
OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer Ontario, Canada, P6C 5B3
Red Hat Inc.
http
t i wanted to test the latest dri
>drivers for my ati radeon 8500 but they wont compile... Here are the
>messages i get:
There are no Radeon 8500 DRI drivers. Not until October-December
this year anyway (Q4/2002).
You'll have to wait until then.
--
Mike A. Harris S
ault AGP mode
>
> From: "Mike A. Harris" <[EMAIL PROTECTED]>
> Date: Thu, 13 Jun 2002 02:58:53 -0400 (EDT)
>
> Ben LaHaise suggested tonigth to me on IRC that perhaps we could
> read the AGP mode from the BIOS and set that by default, and also
> k
ementation problems IMHO, not X bugs. Kimball
Brown at ServerWorks was very helpful to me in getting AGP
working at all on this thing though despite the faulty
motherboard design and broken BIOS.
It'd be nice to pull the needed info out of other vendors also.
--
Mike A. Harris
re end users
lose out, and the more complicated the whole system becomes. The
more bug reports and problems, tech support, etc...
Someone suggested to me setting AGPmode in Cards for different
hardware, but I thought that was quite crack-rock'ish since you
have no idea what mobo chipset is
On Wed, 12 Jun 2002, David S. Miller wrote:
>Date: Wed, 12 Jun 2002 18:08:37 -0700 (PDT)
>From: David S. Miller <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Content-Type: Text/Plain; charset=us-ascii
>Subject: Re: [Dri-devel] Default AGP mode
>
1 - 100 of 209 matches
Mail list logo
