Re: [Dri-devel] Website update needed...

> Someone should really fix this so it no longer refers to the > sourceforge CVS server: > > http://dri.sourceforge.net/doc/cvs.html - dri.sourceforge.net + dri.freedesktop.org I assume that is correct. Liam --- This sf.net email is sponsore

[Dri-devel] Website Wiki

Good day José First off I am using http://dri.sourceforge.net/wiki which resolves to: http://dri.sourceforge.net/cgi-bin/moin.cgi/ I assume this is correct, if not ignore me. First off looking good, looking useful. There does seems to be some recursive linking going on ie pages linking to them

Re: [Dri-devel] Website

On Fri, 19 Sep 2003 12:20:53 +0100 José Fonseca <[EMAIL PROTECTED]> wrote: > On Thu, Sep 18, 2003 at 06:52:23PM +0200, Alexander Stohr wrote: > > i want to propose to integrate a link > > to the new WIKI pages to the Help & FAQ > > section of the DRI homepage. > > I've added a link to the Wiki n

Re: [Dri-devel] the relationship between Local Graphics Memory and Frame buffer?

> Now I am reading intel northbridge 440BX spec(look page 88:Memory > System Address Space) And i have a box with 440BX > I look /proc/iomem,i find that Framebuffer's size is 16MB(i open vesa > before kernel using vga=788) And the local Graphics Memory's size is > 64MB(through PMBASE Reg (24h) ;De

Re: [Dri-devel] Updated configuration design doc

> I updated the configuration design document to reflect the current > state of the implementation. The new document is available at > http://user.cs.tu-berlin.de/~felixyz/dri/dri_config_design_rev4.txt if > anyone is still interested given a mostly complete implementation. ;-) > Maybe someone wan

[Dri-devel] Website

Been real busy lately, so I'm going to unsubscribe from dri-users, and filter out bugzilla-daemon to delete without reading. Otherwise I just won't be able to read all the posts, this makes it a third less emails I have to read. Although now that I look at it, while dri-devel seems to be abused

Re: [Dri-devel] TAKE MY NAME OFF YOUR LIST

On Wed, 16 Jul 2003 15:52:41 -0500 "linsblues" <[EMAIL PROTECTED]> wrote: > > REMOVE MY NAME FROM YOUR LIST Chill out man. Allow me quote 2 lines from teeh email you just sent to the list: > List-Unsubscribe: , >

Re: [Dri-devel] SiS news

> I just saw this on extremetech today: > > http://www.extremetech.com/article2/0,3973,1101038,00.asp > > Looks like SiS is spinning off it's graphics chip division. perhaps > this could mean better access to databooks! Now might be a good time to ask if they've considered it, get the idea out

Re: [Dri-devel] Weekly IRC meeting reminder -> Now

Pretty much now... > This is just a friendly reminder that the weekly dri-devel IRC meeting > will be starting in the #dri-devel channel on irc.freenode.net at 2100 > UTC (or 5:00PM EDT or 2:00PM PDT, if you prefer). > > Time zone conversion available at: > > http://www.timezoneconverter.com/cgi

Re: [Dri-devel] known issues w/Tualatin?

On Thu, 5 Jun 2003 14:21:53 -0600 Nicholas Leippe <[EMAIL PROTECTED]> wrote: > On Thursday 05 June 2003 01:25 pm, [EMAIL PROTECTED] wrote: > > On Thursday 05 June 2003 11:18 am, Michel Dänzer wrote: > > > On Thu, 2003-06-05 at 11:24, [EMAIL PROTECTED] wrote: > > > > I just upgraded my 2x933 p3 to

Re: [Dri-devel] known issues w/Tualatin?

> I just upgraded my 2x933 p3 to 2x1400 p3-tualatin, and now whenever I > start up Q3A the machine hangs hard. > > On one occasion, Q3A started, but the sound was all screwy, and on > exit q3a segfaulted. xmms, however, still played sound just fine. > > The other few times I tried, it instantly

Re: [Dri-devel] web page on CVS

> on the web page, titled "CVS fro the DRI", > linked via "CVS Web Page" on the documentation page > there is a comment for the mesa-4-0-4-branch > with states: > "A Stable branch to be included in XFree86 4.3" > > XF86 4.3.0 is already out a few months, > so that line obviousely needs an updat

[Dri-devel] Re: VA Releases DRI Docs under MIT License

> Did anyone else notice this? No. >http://sourceforge.net/forum/forum.php?forum_id=217795 I'll read it. > Maybe I've been hiding under a rock...but I think this was done 6 > months ago and none of us noticed because the only notification was > given to the news column of the DRI projects

[Dri-devel] Re: XFree86 bugzilla available

> > > > > > Also, what's the general mailing list one can subscribe to > > > > > > receive notifications everytime a bug is open? > > > > > > > > > > Currently [EMAIL PROTECTED] gets them all. > > > > > > > > [EMAIL PROTECTED] gets notification when a bug is filed on > > > > sourceforge against

[Dri-devel] Re: XFree86 bugzilla available

Hi Philip Are you going to put your time where your mouth is? I'm sure that having someone who looks after the admin of the DRI project is a good idea. If only for the reason as having someone to fiddle with the website, ie leaving the dri developers more time to code drivers. Heck I might eve

[Dri-devel] DRI website in CVS & driver_naming / features.

> > http://g7-mac3.fy.chalmers.se/cgi-bin/twiki/view/Forte/WebHome > I haven't looked at it That was supposed to read: I haven't looked at it *yet*. > That's because the video drivers have had the PCI ID to name > mappings changed from "Radeon xxx SDR/DDR" to "Radeon 7200". To > my knowledge, i

Re: [Dri-devel] dri driver features page -> website in CVS

> You could set up a dummy database for testing? Yes I could, for teh meomnt I installed apache and php, apache works, php doesn't, if I get php working then I'll see about a database. > So, which files in doc/ should go into CVS? At a quick glance, only the > files in the doc/ directory itsel

Re: [Dri-devel] dri driver features page -> website in CVS

> I'm not sure what you mean here. If you cvs commit on the webserver, the > only bandwidth you need is for the I/O on your terminal. The CVS > protocol traffic is only between the machine you are logged in on and > the machine the CVS repository is on, both sf.net. And even if you > commit direct

Re: [Dri-devel] dri driver features page -> website in CVS

> Maybe this is a radical proposal, but it's a thing I've made good > experience with, over the last few months. > > http://twiki.org > > It is probably not the right thing if you want a perfectly styled > corporate web site. But it is an easy way for everybody to keep > documentation up-to-date

[Dri-devel] Re: dri driver features page -> radeon_naming

> > > 7200" aka "Radeon 64 DDR", is the type and speed of the memory, > > > and that the TCL unit is somehow disabled via software. > > 7200 is SDR. > > You sure about that? Reasonably sure. > My Radeon DDR VIVO identified itself (under windows) as a 7200... My Radeon 32MB SDR identifies itsel

Re: [Dri-devel] dri driver features page -> website in CVS

> We don't need to put everything into CVS right away, but the way several > people are editing the same files right now is dangerous. Somewhat, at least it makes life interesting. > > I'd rather not use CVS myself just for the website, when I mess up a > > single character I just ssh onto the

[Dri-devel] dri driver features page -> website in CVS

> > PS: Editing files like this makes me kind of nervous, we should really > > work out a way to handle the website in CVS. > > What's the difficulty in having it in CVS? it's extremely trivial to set > up, you just tell the web server to cvs up from the repository every few > hours or so. The we

[Dri-devel] Re: dri driver features page -> radeon_naming

> The DRI website contains a few other inaccuracies about ATI's > Radeon video hardware. Nothing mission critical, but it is > incorrect: > > http://dri.sourceforge.net/doc/radeon_naming.html > > Radeon VE a.k.a Radeon 7000, is not R100, it is RV100. So what does this mean for users of DRI?

[Dri-devel] Re: dri_driver_features.phtml & dri_radeon_features.html

On Tue, 11 Mar 2003 18:34:16 -0700 Brian Paul <[EMAIL PROTECTED]> wrote: > Smitty wrote: > > Hi Brian > > > > In light of your well maintained: > > http://dri.sourceforge.net/doc/dri_driver_features.phtml > > > > I think it's a

[Dri-devel] Re: future of DRI? -> why no one plays with Glide3. -> documentation.

> >> I'd love to see more vendors providing specs, and doing so more > >> openly, and preferably without NDAs. Ragging on vendors who do > >> permit access to docs under NDA to people of their choosing, for > >> not providing them to the world, is more likely to dry up access > >> to specs for _E

[Dri-devel] Re: future of DRI? -> why no one plays with Glide3. -> documentation.

On Sun, 2 Mar 2003 19:34:27 -0500 (EST) "Mike A. Harris" <[EMAIL PROTECTED]> wrote: > On Sun, 2 Mar 2003, Smitty wrote: > > >OK but here is my take on it, people will work on what they are > >interested in, so if someone wants to work on R128 and ATI does > &

[Dri-devel] Re: future of DRI? -> why no one plays with Glide3.

> (oh, and please, I prefer being referred to by my first name.) one Molton many Ian's From: "Daniel Vogel" <[EMAIL PROTECTED]> To: "Smitty" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Subject: RE: [Dri-devel] Re: future of DRI? -> why no one plays

[Dri-devel] Re: future of DRI? -> why no one plays with Glide3. -> documentation.

bad eg and explanation thereof People aren't stupid they know Intel is trying to play in the graphics arena and is willing to do their own drivers, so they let tehm and do something else. OK but here is my take on it, people will work on what they are interested in, so if someone wants to wor

[Dri-devel] Re: future of DRI? -> why no one plays with Glide3.

> The 3Dfx Voodoo 3 and Banshee specs are available, as are docs > for other 3D hardware. Who is working on that right now? 3Dfx > released the source code of Glide3 for example. I dont think a > single line of code has been written for Glide3 for 2 years now. Probably because, 3DFX is dead,

Re: [Dri-devel] S3TC (again)

> > Can we add this to the FAQ, please? > > The FAQ is editable by anyone isn't it? No, but anyone can add a FAQ, if they could edit / delete them that would be none too wise, which is why I advise not to mess it up (because then I have to fix it). Liam it depends

Re: [Dri-devel] S3TC (again) -> FAQ

> > OK, I don't exactly want to stir up this hornets nest *again*, but a > > couple of things aren't entirely clear to me and I'd appreciate any > > clarifications. > > > > As I understand it, the situation is as follows: > > > > The S3TC algorithm is patented and therefore no-one can distribute

[Dri-devel] Re: DRI Mailing list maintanence / maintaner

> > >> I think spam filtering for dri-devel and dri-users would be a good > > >> solution -- IMO, that would be better than moderation. For > > >dri-patches,> the Reply-To is dri-devel. I'd rather have just commit > > >messages and> nothing else on dri-patches. Any comments/replies to > > >spec

Re: [Dri-devel] DRI Mailing list maintanence / maintaner

> > >>>Is there anything that can be done to cut down the spam on > > >dri-devel? >>Several other mailing lists I'm on hold submissions by > > >non-subscribers>>for approval. I'd even be willing to sort the > > >non-subscribed emails,>>so that everyone else could avoid them... > > > > > >That woul

[Dri-devel] DRI Mailing list maintanence / maintaner

Hi Rich > > Is there anything that can be done to cut down the spam on dri-devel? > > Several other mailing lists I'm on hold submissions by non-subscribers > > for approval. I'd even be willing to sort the non-subscribed emails, > > so that everyone else could avoid them... That would be great,

[Dri-devel] Re: Configuration File Example.

> 1) Requires special parser which is too syntax sensitive > 2) Users editing the file could hose it rather easily compared to >existing formats. Ja I know I was teasing the "We want XML" crowd by going to the extreme in the opposite direction, trying to pull them back to the centre. > Fo

[Dri-devel] Configuration File Example.

Howzit? How about this for something which can be edited by a GUI program which can change the settings, and which I / you / world+dog can read, understand and edit easily in a text editor? GUI *and* CLI editable without having to squint at it. Anyone see any problems if so feel free to educate

[Dri-devel] Configuration file format survey

Hallo > We've been discussing general issues regarding the new DRI configuration > system recently on IRC. The most user-visible issue is the configuration > file format (until there is a GUI tool ;-). > In any case we need a more structured (nested) format than win.ini since > we want to be abl

[Dri-devel] Re: 64-bit kernel, 32-bit user. Possible? Painful?

> Subject: [Dri-devel] 64-bit kernel, 32-bit user. Possible? Painful? I recall reading somewhere of a Linux (?SuSE?) box based on AMD's forthcoming 64bit x86 cpu, runing both a 32bit and a 64 bit program at the same time, so I'd say its possible. I've no idea how this was being done ie was the

[Dri-devel] Re: [Dri-users] Re: SUCCESS! Radeon 8500 DRI under RH 7.3! -> documentation

I think this needs to go to dri-devel. That's where the busy person lurks, and it seems to be a good start. > > Actually there has been some work to create a script which will > > identify the card and advise which driver to download, but holiday > > season plus busy people does not make these thi

[Dri-devel] Re: [Dri-users] Slackware -> kernel modules situation

Does the quotation below accurately reflect the situation eith kernel modules or not? If not please spell out the correct situation. > > > The information on the web site is wrong in that place, and cause me > > > a great deal of confusion. The kernel modules are now included as > > > part of th

[Dri-devel] AGP modes

http://grassomusic.de/english/luefter.htm: > AGPx2 can use lower signal levels if the graphics card asks for it, > 1.5V instead of 3.3V (AGPx4 uses 1.5V high state always) Wonder if this has anything to do with why some cards on some motherboards work at some AGP multipliers but not others. Li

[Dri-devel] Re: DRI/DRM/stuff overview?

Hi Samium >There is one hopefully nice idea to help DRI developement. > The first and best thing to make a project successful is a good and > clean codebase. The second is a comprehensible set of docs in order to > attract more developers. > > Not that i have paid enough time to find

[Dri-devel] Re: Joining development

> Hello! > My name if Rudnev Alexey, I have been developing Linux OpenGL-based = > (and also writing my own graphics engines,independent of Mesa) = > applications for quite a long time .I also have some expirience in = > developing(adapting existing to my configuration) video drivers for = > Lin

Re: [Dri-devel] DRI & Red Hat Kernel 2.4.18 -> Adding FAQ's

> > > I recently upgraded the kernel on my laptop to latest for Red Hat > > > 7.2, called 2.4.18-18.7.x. I then tried to reinstall DRI from the > > > latest dripkg (dated 12/4/2002). The laptop has a Mach64 Rage > > > Mobility graphics chip. After all these upgrades, I can no longer > > > get har

[Dri-devel] Do we have a 3DNow!/SSE switch so that I can test without SSE?

> Seams to me that SSE support in Mesa-5.0/5.1 brakes several things on > Athlon > systems. On Athlon MMX and 3DNow! are shared. Even SSE is "mixed" in. > But "more" parallel...;-) When did this happen I was under the impression state changes were required to get between the various instruction e

[Dri-devel] Re: Ati Radeon 8500 - DRI howto.

Hello Bache Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. > I've made a small howto for ati radeon 8500 with direct render support. > I want opinions and suggestions, changes that can make the

[Dri-devel] Re: DRI site overhaul: What about the "DRI Beginner's Guide" etc. sections?

Howzit Dieter? Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. > Any progress? With what excatly the guide in the subject line - I've never touched that. With the website see below. > When will

[Dri-devel] Re: non-NDA documentation.

Howzit? Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. > Heres a suggestion. > > Can people holding non-NDA chipset documentation please all send it to > smitty and he can put

[Dri-devel] Re: how to build

> Liam, perhaps this could be put on the website? I'm happy to put up anything that is deemed useful. But I'm not going to write it. > Can someone do a brief explanation of how to build a CVS DRI on a system > with NO X-windows installation at all, including CVS commands ? > > (I'd like to kn

Re: [Dri-devel] dri_data_flow and control_flow diagrams + explanations & website

> > btw is the DDX Driver what causes the XServer to be single threaded? > > I think there are more fundamental reasons. Better change that back then. > > Also sticking up dri_driver_features table by Brian Paul, it may not > > be complete but it is full of info already. > > Yes, looks good. I'

Re: [Dri-devel] dri_data_flow and control_flow diagrams + explanations & website

> > This has been sitting around for a long time, since I got pulled into > > the website side of things. > > I wish to put this up as high level design documentation. > > Any comments? > The two documents look great! Up they go. > They match many of my personal notes about architecture :) OK the

[Dri-devel] dri_data_flow and control_flow diagrams + explanations

This has been sitting around for a long time, since I got pulled into the website side of things. I wish to put this up as high level design documentation. Any comments? and yes n2s is note to self. Liam it depends dri_flow.tar.gz Description: Binary data

[Dri-devel] Re: driver feature table

Hi Brian > Attached is an updated table. Good work, when everyone stops pointing out typos etc please email (cc) me a copy, and I'll put it up sometime (wee bit busy atm). Liam it depends --- This sf.net email is sponsored by:ThinkGeek W

[Dri-devel] Re: http://penguinppc.org/~daenzer/debian/dri-trunk/

> > > Why don't you just use > > > > > > deb http://penguinppc.org/~daenzer/debian/dri-trunk/./ > > > > This is new to me, > > I guess it wouldn't be a bad idea to mention them somewhere on > dri.sf.net. Who is them? > DRI CVS snapshot packages, so based on 4.2.0. What is it it?

Re: [Dri-devel] Re: Typo on DRI website -> archives

> > otherwise alphbetically eg Manufacturers & Distros (I'll fix distro's now) > > Then you only have to fix status.phtml (Supported Cards) to make it equally to > links.phtml (Graphics Card Manufacturers). Well spotted, I'll make the status.phtml alphabetical. cheers Liam --

Re: [Dri-devel] Re: Typo on DRI website -> archives

Op Saterdag, 28 September 2002 20:27:01 Dieter Nützel het geskryf: > Am Samstag, 28. September 2002 19:57 schrieb Smitty: > > > > What about the main central archive? > > > http://marc.theaimsgroup.com/?l=3Ddri-devel&r=3D1&w=3D2 > > > > > > It

[Dri-devel] Spam on this list, list email addresses are out in the open.

Howzit? Having noticed the spam on this list, when I was working on the Mailing list page ( subscribe / unsubscribe / preferences ) this struck me as odd: "To send mail to the list send to [EMAIL PROTECTED]" Now is this not vulnerable to email harvesting web bots which makes the list more likel

[Dri-devel] Re: Typo on DRI website -> archives

> > 1. For the mailing list info, there is a link to the old Geocrawler > > archives. I think that should probably be removed because SF.net has th= > eir > > own archives now and they also include the content from the old Geocraw= > ler > > archives. You can already get to the SF.net archives by

[Dri-devel] Re: Typo on DRI website

> > btw what about now? > > Much, much better. I have a few more comments though . ;) Refer to my email about a certain cycle. > 1. For the mailing list info, there is a link to the old Geocrawler > archives. I think that should probably be removed because SF.net has their > own archives

[Dri-devel] Re: Typo on DRI website.

> > I would also recommend that you work together with Nick Leippe. > > Just a quick note to say that I'm still here and happy to help. > My modified version is up for grabs to pick and choose from still at > http://lfm.sourceforge.net/dritest/ Sorry I managed to miss a whole bunch of posts, read

[Dri-devel] Re: Typo on DRI website

> > I think it is much too early for this kind of criticism. While the > > updated website is far from perfect and finished, I definetely think it > > is a clear improvement with respect to the former version. > > I don't see how it is too early for criticism. Liam has indicated > several time

[Dri-devel] Re: Typo on DRI website

> > I would say that Effecting a full scale 'all in one go' transition is > > VERY hard. I would suggest letting Liam make the poage official, and > > continue refining the layout. > > I don't see how a transition in one go is very hard at all. The DRI > website is fairly small, all you have to

Re: [Dri-devel] Re: Typo on DRI website -> XFree86 NDA's

> > Speaking of the new web site, could someone please remove the section > > in the FAQ that says that various NDA'd documentation can be obtained > > by becoming an XFree86 Project member. > > I'm sure someone could do that, could you point out where this is, > I'm certainly not about to read

Re: [Dri-devel] Re: Typo on DRI website -> XFree86 NDA's

> > Speaking of the new web site, could someone please remove the section > > in the FAQ that says that various NDA'd documentation can be obtained > > by becoming an XFree86 Project member. > > I'm sure someone could do that, could you point out where this is, > I'm certainly not about to read

Re: [Dri-devel] Re: Typo on DRI website -> XFree86 NDA's

> Speaking of the new web site, could someone please remove the section > in the FAQ that says that various NDA'd documentation can be obtained > by becoming an XFree86 Project member. I'm sure someone could do that, could you point out where this is, I'm certainly not about to read all the FAQ

Re: [Dri-devel] Re: Typo on DRI website.

> > > Ok, I would remove CVS and IRC Logs from that page. They should > > > re-appear on the "Contribute" page. > > IRC is already gone, I'm leaving CVS there (for now at least) because > > is working on scripts to pull CVs, compile etc > > Why do you need to leave the CVS information there? >

[Dri-devel] Re: Typo on DRI website.

Howzit Frank? > > Quite frankly (no pun intended) IRC logs are about the only thing out of > > place, and when I look at that page I wonder if I should remove them, > > however your idea to split documentation back out of help will draw > > attention back to them on that page meaning they can be

[Dri-devel] Re: Typo on DRI website.

On Sun, 22 Sep 2002 21:24:37 -0700 Frank Worsley <[EMAIL PROTECTED]> wrote: > > That hasn't happened (accepted and moved) so I haven't asked. > > I think there is two problems here ... > > 1. Since this is an open-source project there is no single person to > approve the website. Basically I d

[Dri-devel] DRI meeting now! #dri-devel

Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/li

Re: [Dri-devel] Re: Typo on DRI website.

> > > > Which reminds me /dri/htdocs/ is a real mess and I can't clean it up because > > I don't have rights to delete things (I think) because the permisions set are > > for the dri / sourceforge *login* not the *group* dri. > > I don't understand. As it is now: > > % ls -l > > drwxrwsr-x

[Dri-devel] Re: Typo on DRI website.

Mike A. Harris wrote: > 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) IIRC I wasn't worried how I spelled it originally as it was RFC s

[Dri-devel] DRI Website update - URL

Howzit? Thanks to all those who have been helping me, this has got done a lot quicker than it otherwise would have, and the DRI site is still standing ;-). Anyhow: http://dri.sourceforge.net/site_update/ All comments, suggestions, requests are welcome. Liam it depends ---

[Dri-devel] Have a sneak peak at the new DRI website and give your opinions.

email me and I will email you the updated version, it is currently less than 70K uncompressed (it uses the existing site) this version may be up to double that -I'll try to keep it down in size. Liam it depends --- This sf.net email is

Re: [Dri-devel] Re: Fast Writes

> > Which makes perfect sense for Michal Kozlowski problem, old chipset > > (no / buggy fast write support) and new graphics card (with fast > > write support). > > > > > This issue is also present for me, I get the same behaviour (X-server > crashes, and blanks the screen) on my box, even t

[Dri-devel] Website updates

Howzit? Busy going over the website doing some updating, and have a few requests. 1. have a look at the radeon features list, I think the status of a few of those features has changed. 2. Anything else on the website that you can spot that needs updating. Liam it depends --

[Dri-devel] Re: Fast Writes

> This worked for me, but my Radeon 7500 QL is ok with Fast Writes. > What dose this do, just curious? IIRC an AGP feature which must be supported by both the chipset and the graphics card, just makes things faster, like side band addressing. > > Thanks to the help of Stefan and others I got m

[Dri-devel] 1. SSE on Athlons (and FreeBSD) (Eric Anholt)

> A while ago I added the stuff to the config/cf/* to enable USE_SSE_ASM > on FreeBSD, but today found that it wasn't enabled on my athlon. I > added the proper sysctl check for it, but it still wasn't enabled. It > turns out the Athlon's extended CPUID function has most of the same > feature b

[Dri-devel] Radeon 8500 binary snapshots now available -> Status page.

Great work Keith. > What I've done so far is to extend the existing radeon interfaces to accept > & validate the new state required for the r200, and a couple of other minor > changes. This is probably the minimal set of changes to get a working r200 > driver. It would seem that driver developm

[Dri-devel] Re: The Radeon LE? (Mike Mestnik) aka Radeon naming scheme

> # > # List of PCI ID's > # > # Maintained by Martin Mares <[EMAIL PROTECTED]> and other volunteers from the > # Linux PCI ID's Project at http://pciids.sf.net/. New data are always > # welcome (if they are accurate), we're eagerly expecting new entries, > # so if y

[Dri-devel] Re: what is hyper-z?

Howzit? > what is hyper-z? a proprietary texture-compression function of the r200? > well, as you expected, performance is exactly the same after the > checkout as before HyperZ has 3 components: Hierarchical Z Discards hidden pixels instead of sending them to be rendered. Z-Compression Perfor

[Dri-devel] Radeon scratch register writeback patch -> Which radeon is which?

Sorry that this is late but I am behind in my reading of the list. Original Radeons: Radeon VE (no TCl) Radeon SDR Radeon DDR / LE Rereleased Radeons: Radeon 7000 (no TCl) Radeon 7200 (SDR) Radeon 7500 (DDR) The only differences are more RAM and higher clock speeds (possible because of a manuf

[Dri-devel] Re: Re: Radeon SourceForge d/l binaries (the ones everyones bitching about)

Hei > some my friends reported that this method still not work for Radeon cards > (Xserver starting but dri not work). Testing in progress... :) Me neither (I have a radeon) however it works as root / su (even in a virtual terminal under X logged in as a normal user where it wont work) which ma

[Dri-devel] Website comments

From: Keith Whitwell <[EMAIL PROTECTED]> > - There's no easy link to the sourceforge projects page. yes and add the hosted by SF pic below (with some space) redline2 (finishes off the menu frame nicely) - The 'status' page has disappeared > change Hardware to Status in the menu frame. (makes

RE: [Dri-devel] Website [update!] -> frames colour

Also, the frames need a bgcolor in the body. This is a pet peeve of mine, since I have my default background set to gray. Well if I can see them then I can grab them and resize them. I can also see this line in the old / original site? Liam it depends ---

[Dri-devel] Radeon SourceForge d/l binaries (the ones everyones bitching about)

Well after beeing told to upgrade to XF4.2 from XF4.1 I did so: So XF4.2 Indirect rendering install the latest / last binary package from TG XF4.2 with direct rendering (no TCL) compile (not install) the latest binary package (20020623) from SF copy every file to its proper location except radeon

Re: [Dri-devel] Re: Re: website. (Jens Owen)

On Sun, 23 Jun 2002 22:52:09 +0100 Keith Whitwell <[EMAIL PROTECTED]> wrote: > Smitty wrote: > >>>I want to get started putting up the new site, but no-one has told me > >>>how to access the webspace... > >>> > >>>I've given my sour

Re: [Dri-devel] Re: agpgart, nFORCE (Al Tobey)

On Sun, 23 Jun 2002 20:15:35 +0200 Dieter Nützel <[EMAIL PROTECTED]> wrote: > On Thursday 01 January 1970 00:59, Smitty wrote: > > Hallo Dieter > > > > > > > It's just a guess on the agp gart; the IDE and sound both are clones > > > > > o

Re: [Dri-devel] Re: agpgart, nFORCE (Al Tobey)

Hallo Dieter > > > It's just a guess on the agp gart; the IDE and sound both are clones of > > > the AMD chip, so why not the gart?. The big whiz-bang feature of the > > > nFORCE chipset is the crossbar memory controller that supposedly doubles > > > the bandwidth of DDR (double double data rate

[Dri-devel] Difference betwwen the packaging of the Radeon TCL binaries (TG) and the Linux Intel x86 Packages:

Howzit? Having a bit of an issue with the packages from: http://dri.sourceforge.net/snapshots/radeon-20020615-linux.i386.tar.bz2 On a clean install of Linux Mandrake 8.1 XFree 4.1 Kernel 2.4.8 etc Radeon SDR 32MB / AMD 756/758 Linux Intel x86 Packages: radeon-20020615-linux.i386.tar.bz2 Using

[Dri-devel] Re: radeon cvs problem ([email protected]) - binary packages

> Just upgraded to the latest radeon dri-cvs (using the binary packages > on SF) and now the X server won't start. This used to work fine with > the 20 May TCL snapshot. > > The kernel module seems to load OK: > > Jun 19 16:30:36 localhost kernel: [drm] AGP 0.99 on Unknown @ 0xec00 64MB > J

[Dri-devel] Re: agpgart, nFORCE (Al Tobey)

> It's just a guess on the agp gart; the IDE and sound both are clones of > the AMD chip, so why not the gart?. The big whiz-bang feature of the > nFORCE chipset is the crossbar memory controller that supposedly doubles > the bandwidth of DDR (double double data rate). Why would they bother > c

[Dri-devel] Re: Re: website. (Jens Owen)

> > I want to get started putting up the new site, but no-one has told me > > how to access the webspace... > > > > I've given my sourceforge details and been added to the project... > > Ian, > > I can't help you with access details, but I'd like you to stage this > below the current main site

Re: [Dri-devel] Understanding the internals of a X11/OpenGL Based Program (Using 3D Direct Rendering)

> > 1.) MK II: > > _ > > \ > > +-+ | > > | X11/OpenGL Based Application | | > > | (Using 3D Direct Rendering) | | > > +--

Re: [Dri-devel] tuxkart, and bug reports.. (David Willmore)

Howzit? > I see that there is a very active development community and three big projects > in the works (radeon, radeon T&L, and mach64). Yes I've slowly realise that this is what goes on in the DRI project, a thought has been rattling around in my head of late of a simple list of who is workin

Re: [Dri-devel] Understanding the internals of a X11/OpenGL Based Program (Using 3D Direct Rendering)

Howzit Jens? 3 Parts to this email. 1.) MK II: _ \ +-+ | | X11/OpenGL Based Application | | | (Using 3D Direct Rendering) | | +-

[Dri-devel] missing file - cntrl_flow.png

I've attached the latest WIP of cntrl_flow.png to help show this. Wasn't paying enough attention. Liam it depends cntrl_flow.png Description: Binary data

[Dri-devel] Understanding the internals of a X11/OpenGL Based Program (Using 3D Direct Rendering)

Hei Jens Remember this? +---+ | X11/OpenGL Based Application| | (Using 3D Direct Rendering) | +--++ | OpenGL Library | XLib | | +++ | | | GLXLib | | +-

Re: [Dri-devel] Understanding the flow of data to the Graphics hardware. -> DRI Awareness

Howzit? First off I really should change my Subject line more often. > > I've been thinking, dangerous yes I know, but DRI (desperately) > > needs people willing to program C for the drivers or look for > > bugs etc -right? > > We do need people...we're not desperate. It's amazing what a few *

[Dri-devel] DRI Links Page Submissions

Howzit? A links page was requested and this is what I have so far, have I missed anything, is anything unneccessary? If so I think you know what to do about it. Links to Projects & Companies related to DRI: Chromium Project (The) http://chromium.sourceforge.net FbDri http://fbdri.sourcefo

Re: Re: [Dri-devel] Understanding the flow of data to the Graphics hardware.

Howzit Jens? > Did you see the flow chart at > http://dri.sourceforge.net/doc/control_flow_poster.jpg Yes, and I've worked through it. I am referring to: http://dri.sourceforge.net/doc/data_flow.jpg IMHO it doesnt make it any clearer what happens once the 2D & 3D data arrives at the X Serv

  1   2   >