I would like to give another perspective on this conversation, but let me first say that I am speaking for my personal views and not representing the company I work for.
It is easy for people to discount complaints when they come in such a passionate manner. Everyone should keep in mind that rarely do people get all worked-up over nothing. Obviously there are things about this project that could be improved, and taking the problems discussed in this thread with a grain of salt will probably lead to a better project in the end. I was working with PI pretty early in the game on the DRI. I think the i810 was one of the first working designs after the reference implementation, so I've been familiar with the developers here and the DRI project for some time. Unfortunately at the time that the i810 driver was being developed I didn't have the requisite background to really understand the complexities of the code. I was an experienced Unix/Linux systems programmer but I had no understanding of the XFree codebase nor did I have any background with graphics hardware. I suspect that many of the developers on the "outside" are in much the same situation. They have programming skills and would like to apply them to this project, hoping to learn the complexities as they go. This is, after all, how most software engineers learn, by actually getting their hands dirty. Clearly, from looking at the number of active developers who were not part of the original PI team, you can see that developers from the outside are having trouble getting up to speed. This is more clear now than ever, due to the declining free time of the originals. So I see three problems with the DRI project, mostly the same problems seen by others, but one more "Me too" couldn't hurt. 1) Lack of communication/information on design. The beginnings of the DRI were designed behind closed doors. The first glimpse the world had was really after most of the design basics were already in place. I don't think that there was really a conscious effort to keep the information away from others, but certainly there was not enough effort put into getting feedback on the design in a public manner. Even today there are lots of design decisions for which there seems to be no public paper trail. I recall seeing something along the lines of "Context private SAREAS", but I don't recall any public design discussion on it. I am sure there are lots of other changes that just "appear" without seeking input in a public manner. Paper trails are important. If the design discussions were preserved for public reading there would be less pressure on those "in-the-know" to write documents. Given that documents are not the favorite thing to write for most engineers, we can hardly expect every engineer to put in the effort in their spare time. Nobody has any right to expect anything from a developer who is contributing their own time, they will most likely do the things _they_ want to do. Take it or leave it. However, given a paper trail there _will_ be someone willing to compile the information into a useable document. I know there are lots of things that happen under NDA. That should not preclude you from discussion general design in public, you just have to be careful about what you disclose. That is the price to pay for using an open source framework in contract work. You have to walk the line carefully. In this light I would like to say that when doing XvMC I spent entirely too much time coming up to speed on the i810's DRM driver. The information was not available, even to me, in a useful form. I went down many wrong roads figuring out where things had diverged from the DRI design docs, and there was no documentation what-so-ever on the implementation of individual drivers. Solution: I would suggest that great effort be taken to keep all design communications on this list. Even if nothing comes of it, we will have the paper trail for another day. When drivers are written, a design document should be written too that covers the driver design. The information needs to be preserved because the details will fade from even the developers mind in far too short a time. To correct the lack of current documentation I suggest the IRC meetings as discussed earlier. We could keep a good agenda for the meetings where time is allotted to explanation of specific parts of the DRI. A moderator could help to direct conversation. This means that after a few weeks we will at least have some "Brain dump" information about the DRI. When someone asks for help on "Drm Maps" we could at least direct them to a 15 minute IRC log with related discussion. Perhaps someone would be kind enough to format some of these into real documents at a later date. 2) Limited "core" members. The quantity of developers and their backgrounds is very limited. Pretty much the design come from people who have been doing X for a very long time. While this makes you abundantly qualified to do the work, it also makes your design suffer from limited diversity. As it stands the only people with direct input have serious ties to single company, public acceptance is going to be hard to achieve without a more diverse offering. In hindsight it is amazing to me how close the DRI gets to being able to do general direct draw framework without getting there. XvMC had to do far too much general surface and security setup that might have been easier if more input was taken from the public. A public that might have included people with different needs for direct rendering other than 3d. Another interesting point is that you have your own fork of the XFree tree. This further limits the input into the design by eliminating all the qualified X developers without direct rendering interest from the discussion. They all live/work on the XFree lists and don't watch this list. I know the reason for the separate tree was historical, but that reason hasn't existed for perhaps two years now and still you maintain a different tree. Solution: Be more inviting. Give serious consideration to merging your tree back into XFree. At the very least you could put your tree on a branch in their CVS. Then at least there would be more eyes on the design. I would also suggest giving serious consideration to reaching out to the fb and directfb developers. There is a LOT of overlap in design goals going on. By discounting designs you don't like you are limiting your audience. Keep in mind that you can't have _everything_ your way, but certainly you can help to make the designs more supportive of each other... and perhaps share kernel modules. 3) Too much Focus on engineering. This is a problem that comes from having such gifted developers, and only gifted developers. All your focus has been on what is "Possible" and not what is "Practical". How many times have you seen problems with not knowing what magical host.def options someone needs. Or how many times have people not been able to get the bleeding edge tree to compile due to needing some undocumented Mesa/DRI/Kernel setup. Just getting the tree to compile and install is hard, too hard in fact to get any real world input. Basically the only eyes the project has are people who are far more capable than 99.9% of the target audience. Solution: Give a little more though toward making the build easy. There has been some great discussion on the Linux kernel mailing list about kernel building for "Aunt Tillie" (sp?). The more effort that can be put into making things "just work" the more eyes you will have on the project. More eyes leads to more developers, more developers leads to more progress. This is something that could benefit the general XFree code too. Hopefully everyone can dust off any bruised egos and really give some thought toward making things better. I look forward to weekly IRC meetings with you all. -Matt _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
