Okay, sorry, I just had to laugh. Not your fault, I admit that. You are as innocent as I used to be.
Here's the deal bro: [RANT MODE ON] Sometimes it seems that the DRI project is for a "special" group of people who are (either,or,and,not,etc,etc): 1) special, either because they designed it, or because they already had 18+ years of X11 + graphics industry experience 2) they came from 3DFX, SGI, HP and other big names who had lots of personel working on grafix 3) they design it themselves and don't need to make docs for others 4) or if they do make docs, they do it because else it won't be regarded as official or it won't "sell" (contracts for making drivers) to big names like ATI or Matrox who will hire these people to make DRI drivers for them 5) and after the first bunch of docs which are more like pre-design docs, the design changes radically leaving these docs in the dust and making a new comer even more confused, because some people still claim their are uptodate: what a bunch of horseshit. 6) (these people) don't think back to the times when they needed a helpful start, and think that everyone is just gonna jump on the X11+DRI+Kernel gorilla and start hacking. Yeah, right! I was speaking assembly at age 2 and X11 calls at age 4. NOT !!!!! I _read a lot_ (like most of us? i hear agreement) before I learned the things I know. Anyways, the above things are sometimes true, othertimes not, for others partial, for others full. Take it as you will. With a grain of salt or none at all. That has been my experience at times. I have tried time after time to elicit from the DRI project any kind of useful info so that I could actually help the busy DRI developers (they are only a handful), by creating some devel. docs myself and of course working on 3D drivers. All I got was 2-3 replies (on the most "official" attempt to present a structured/formatted FAQ-style document asking some fundamental questions for beginners ; apart from that various questions were asked randomly and most did get answered, but they were a tiny portion of what was needed for a good devel doc). That was it. What docs are there: There isn't even an existing "shell" or "skeleton" driver (typical for most types of projects where they allow "third parties" to develop for them), with the inards thrown out, so that one can at least get a clue of what components a driver is built of. Heck, not even a list of files (and their locations and the necessary/needed inter-dependence). Heck, I know how to bang registers, but DRI is _not_ designed by me, and it's _not_ clear as daylight even to an experience (non-DRI experience) programmer. Even after reading all the outdated PI documents multiple times, the actual implementation details (not the overall idea) was still unclear or fuzzy at best. Oh yeah, there are the infamous "design/devel" documents. They are known as the PI docs. PI = Precision Insight, the company formed by the core DRI developers who developed the DRI initially based on these documents (their documents). The documents were good for the first couple of months of the DRI developement I imagine. Quickly after, things started to diverge and the docs were full of "this is not implemented" or "will be in the future" or "incomplete; today we will use bubble sort for this, quicksort later". That's fine by me, but as long as you tell me _when_ you decide to switch over to "quicksort" !!! Or even better, when the DRI never switches to "quicksort" but to something totally undocumented in the PI docs, like "radix sort". (PS. when I say bubble/quick/radix sort, I am just interchanging these well known algorithms for DRI/grafix specific algorithms, which don't have such formal names, or well known names. I personally have not seen any of the above sorting methods in the DRI :) So, letme continue with how I saw the progression of things. So the PI docs diverged to holly hell from the implementation on many issues. Stuck out of date. By that time the DRI had already started taking shape, companies like ATI and Matrox (I might be wrong on all this company stuff as it was of course never public info, since the contracts were between company and the DRI group/PI/VAlinux later) came into view, and wanted to contract the PI people to write drivers for Linux. Anyways, so the contracts came in. The docs served their purpose to start things up, so who cares about updating them? Nobody. At least that was the view from this side of the project, because the dates nor the docs changed. Then VALinux buys PI and all/some? the core DRI developers and the story goes on. Point: PI docs are _behemouthly out of date_. Like Mister Iceman found in the Alps ? Like since 1999 ? or 2000 ? Compare this with almost any other "Open Source" projects/initiative. Okay, fine. So the answer on the DRI list is always: read the source. Notice how easy answer it is: 1) it's there (the source) duh! 2) if you can't read it, then you must be pretty lame, coz we can What can you possibly answer to that? Almost no-one dares (at least not without some thinking) to say: well I can't make sense of it! Thank god some people are actualy self-actualized, not overcome by unfounded notions of incompetence, but rather realistic and very normal learning curve issues, and can and do say so: code ain't enough! Well obviously the very well seasoned X11/GL/3D/grafix gurus (read: all the core DRI developers) know how to read these sources, especially the DRI sources (guess what? they wrote them). So here come new hackers who really want to get more than 5-6 ( read: 1) 3DFX*, 2) Matrox*, 3) ATI R128+Radeon*, 4) Intel i8xx, 5) 3DLabs*, forgot any? I am sure not more than 1-2, at least not during the early 2001 period ) 3D cards working on DRI (Note: many cards don't work: S3* cards, PowerVR, Kyro*, SiS, a few ATI's, NVidia cards, and others, this again during the early 2001 period). Some developers-wanna-be's had docs, others didn't, others hoped that XFree86 would help out (DRI not joined with XFree86, no sharing of common resources like docs, unless u are buddies with those guys, u know, part of the "X-files" :) ), and all they found in front of them were big walls to climb. To me, this was very reminiscent of the "old" DOS and Windows days of "closed information" everywhere. Oh blimey, I am wrong: the source was open!!!! (like in the DOS days we had disassemblers, how much help they were when working with API's .. Not! ) Well, this situation didn't help much those who wanted to take a first step (don't look at only me, look at yourself, what are u asking? same things I was) in the 3D/DRI world. Somehow some people managed to overcome some issues, some with help from some DRI developers, but _never_ with devel. docs. At least I never heard anyone praise such a thing! Of course overcoming doesn't necessarily mean doing it the proper way. Fixing bugs or patching almost-working drivers (half-working because the proper DRI maintainter/coder moved over to a more important job: contracted company drivers). The proper way being to be able to fully code from start to finish a complete and fully compliant and working driver. (AKA: I can go fix a couple driver bugs (usually easily identifiable: ex: ARGB textured triangle drawing doesn't work) that are laying around 1-2 DRI files, but that's not comparable in my opinion to writing a full driver). Continuing on, I wanted to write drivers from scratch, not fix non-working drivers (mach64). I learned the hardware. Programmed it, made a user-space mini-driver so I can develop the code for the hardware, but when it came to doing it in the DRI I was stuck. I of course read and re-read the PI docs, asked many times what was outdated and grepped sources looking for the needle in the haystack, but soon realized that if I was to ask about 10,000 (literally) questions before the driver was complete, then what the f**k? drop the card, grab a NVidia and f**k the DRI. Basically that was my final decision: I disagree with the implicit DRI ideology. I say implicit because I never heard anyone preach it, but it sure as hell seems alive around the DRI: When I want to help everyone with my effort (provide free 3D drivers for yet-unsupported hardware), why _should_ I re-invent the wheel (re-learn how a piece of supposedly VERY important and documented (such as very important projects _SHOULD_BE) software project), when the wheel should be already well defined and documented. No. I refuse to waste my time. Not only is my time wasted, but the time of the whole OSS world!! Because when I could be pumping useful code for them, I am _reinventing the wheel_. What a waste. So that's why I stopped frankly. It wasn't that I didn't want to code; It's what I do. It wasn't that I didn't want to put the time; I spent tons of hours working on the hardware, and I was planning to put many hours into the X11/DRI, but for GOD'S SAKE, I am not blind-stupid: I will do it with a reasonable scientific approach: NOT REINVENTING THE WHEEL (unless absolutely necessary of course). So, there's my take on things. I am sorry if it sounded disappointing or malicious. I am _really_ disappointed myself from the whole DRI project due to the way things have turned out. Perhaps I am wrong on somethings, I will accept that, but the majority of issues I mentioned, I have seen over and over in the mailing lists, through personal emails with people, and the #dri channel on IRC. I am not alone. Finally, I of course do not hate the DRI developers, and I realize what an ambitious project it is, and do appreciate just like any other user of 3D the efforts they put into it, BUT, once again I am not blind-stupid: there is money involved, so not everyone does it for "free", there is of course love of the job invovled and I especially appreciate it, but come-on: don't be one-sided. A well rounded person, project, whatever, has to be optimal or as optimal as _can_ be (can=lazyness subtracted from the equation), on ALL fronts. And in the case of Open Source projects, because the development is by default a decentralized model [ DRI seems like an exception at times :( ], documentation and guidence is very important. Especially on a project as complex as X11+DRI+kernel. We are talking about 3 major subsystems of an OS (OS in the generic, non-kernel sense). Once again, we recognize the difficulties of the combo (X11+DRI+kernel), but come-on, I didn't decide to write a 3D driver because I just managed to kick out a 5-liner Perl script and got a sugar-geek-high. I, as many other prospecting DRI developers (note: DRI developers, because many of us are developers in many other projects) do have some solid C, assembly and (grafix) hardware experience. Oh well. Enough of this. The more I recall issues the more disappointed I get.. [RANT MODE OFF] Finale: Anyone: please think about it before (if) you respond to this email. If I am wrong in something of course I would like to hear it, but my overall feeling of disappointment in the DRI project is not gonna change easily. If you want to respond, only do it with DRI devel. docs. Otherwise you are probably wasting your and my time. Thanks and good luck to you! _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
