Been spending a lot of time lately split between reading tonnes of video hardware documentation, standards, and other technical documentation, as well as the usual XFree86 hacking.
I am considering lately releasing my own Radeon driver that is separate from the XFree86 project's driver. There is just way too much time that lapses between the time someone submits a patch to XFree86.org and the time that it gets reviewed by someone and applied to XFree86 source code base - a priveledge that only around 14 people have, and of which about 6-8 use on any regular or semi-regular basis.
ATI submitted open source patches for the Radeon 9500 hardware about the time it was released. That was many many months ago. That patch still hasn't been integrated into XFree86 CVS, and as time goes on, I am thinking it is very likely not going to get integrated into 4.3.0 either. Just yesterday, ATI sent me 2 or 3 more patches that build upon the last patch they submitted which wasn't applied. How long is ATI going to continue submitting patches to XFree86.org that take 9 months to get into CVS, and then perhaps another 4-6 months to be available in an OS distribution? Quite frankly, if I were ATI, and submitting patches as frequently as they do, and the patches just sat there, I might start thinking twice about bothering in the future.
So, where does this leave things? Well currently, it leaves the latest XFree86 CVS radeon driver missing Radeon 9500 support, and a few other bug fixes and enhancements from the first ATI patch. It also leaves it missing various other fixes, etc. from the newest 2-3 ATI patches that are supposed to apply on top of that. Also, I have written a patch to add support for some FireGL 8700/8800 hardware, and some Radeon 8500 hardware that was previously unsupported. I haven't sent my patch upstream yet, as it is obvious to me it won't get applied, at least not anytime soon, so why bother? Until they commit ATI's patches, there is no point submitting further patches. Also, there is a number of other Radeon driver features I would like to work on, and get them out into the hands of actual real users sooner rather than later. If you submit a patch though for something, and sit and wait 6-9 months before someone on the inner circle has time to volunteer to review it, commit it into the repository, or reject it with given reasons (or silently), you get discouraged rather easily.
After thinking about this for a while, and also thinking about our upcoming Red Hat Linux release, I decided that I don't NEED to wait for the various things to be incorporated into CVS. I receive a copy of ATI's patches as well, and am more than capable of integrating them myself into the driver base. And, as an added bonus, I *DO* have the time, or I will _make_ the time. I'll be doing this work this week hopefully, and will put up a new web page somewhere where people can download the driver source code and also binary drivers to try. I will do my best to support the drivers as well, and I plan on also trying to get the code into XFree86 sources upstream too over time, but that wont however be my priority.
When people bitch and whine on the XFree86 mailing lists, or email an XFree86 core team member to ask why some patch that was sent in has not gotten applied yet, the general response is that "There are only a certain number of developers available, of whom are working on XFree86 on a voluntary basis, and there is quite a bit of work to do. The patch will be reviewed in time, and probably applied before the next XFree86 release.", or something to that effect. In other words, there is a shortage of volunteer man hours in the project with which to get work done. However, on the same note, no new developers are ever given CVS write access to the CVS repository, not even a small portion, such as a single X driver. So basically patches sit there and rot until someone "gets around to it". XFree86 development is just not scalable.
What is worse (IMHO), is that recently, they have removed the link to their developer page from the website. At least I am unable to find the link to the developer page anywhere on their web site. If you type in the URL manually however, the page is still there. It can be seen at: http://www.xfree86.org/developer.html. You'll notice at the bottom of the page there is a section "How to become an XFree86 developer." and it says:
How to Become an XFree86 Developer
We are no longer accepting applications at this time.
I've no idea of their reasoning behind that decision, however it concerns me greatly. Granted, many people apply for XFree86.org membership, submit a simple patch, are accepted, and then do little or nothing after that, so from that angle, I can understand their position to not accept more developers. On the other hand, more developers are needed IMHO. Do people really need to be "accepted" as an X developer first in order to contribute? Well, it might help a bit, but it is not really necessary. Most of the NDA information available to member developers is largely out of date, and new NDA docs haven't been forthcoming for quite a while since companies that do give docs out, tend to do so on a person by person basis now rather than to a single entity like XFree86.org.
So, where does this leave everything? I really don't know. I would like nothing more than to see the XFree86 project thrive, and also to see more capable and willing people contributing to the code. I'd like to see a community of development around X11 like that of the Linux kernel, and I'd like to see people openly discussing developmental issues in an open forum not unlike the linux-kernel mailing list. That type of a developer community has just never formed around XFree86 however, and I have no idea why.
The XFree86 development team has a number of very talented people working on each release, mostly voluntarily, but like any developer, they can only accomplish so much work in a finite amount of time. XFree86 development doesn't really seem to scale to well. The more people who might try to contribute, might have to wait a long time for one of the core members to even look at their code, comment on it, accept/reject it, etc. I think most people just give up before getting too involved, simply due to the lack of close and open communication between all developers. I know many developers who have commented that to me at least.
I've talking a bit with a few other Linux and BSD distribution XFree86 maintainers lately, and they've shown an interest in collaborating on sharing patches more closely and directly, and on working closer together as well. I'm hoping we can form a closer development community that is very open and be able to help each other, and not duplicate efforts as much as is done now. XFree86 does NOT have a bugzilla or similar bug tracking database. Instead, bug reports are sent to an email address (email@example.com) which someone might or might not ever actually read. Many people think of this bug report address as a blackhole, or a /dev/null alias. In many cases, I believe they are right.
Since there is no way to "track" a bug through various stages, through resolution, many bugs, and likely many fixes also just fall through the cracks. Since XFree86.org doesn't really have any way for various distributions to share patches efficiently, or to keep track of the status of an issue, or to even find out if a bug has been fixed or not, and if so, if it is in CVS or not, distribution development tends to needlessly end up with each vendor/distro doing a lot of duplication.
I would like to bring all XFree86 package maintainers, and developers together collaboratively somehow in order to track issues, share patches, and reduce duplication of effort as much as possible, and also to feed things back to XFree86.org in a manner that is useful to them, and preferably also cuts down on the amount of work that they need to do in order to incorporate changes, bugfixes, etc.
Another thing that is a problem, is that once a new release of XFree86 comes out, the older releases are more or less completely abandoned after a short while. Even if you send in a bugfix patch for an older release, with patches for the various new releases as well, usually only the newest release or head of CVS gets the bug fix. In some cases someone will commit the fix to an older release as well, however that is not usually the case. It is understandable with a fixed number of vulunteer core developers, that maintaining code for several years for every release of the codebase is a huge task, however many distributions and vendors MUST support the XFree86 releases they've shipped for a certain amount of time, and in many cases can NOT upgrade the given distro release to a new XFree86 release on a whim, due to various customer commitments, or simply due to regression of certain features/drivers in newer releases. There needs to be a more long term way for others to get involved in the maintenance of XFree86 releases that the core team is not interested in maintaining any more, or simply do not have the volunteer time to spend doing so. I would like to discuss this issue with XFree86.org, and with other distribution maintainers also.
All in all, I would like to see XFree86 development increase rather than decrease, by helping other developers, and by getting more people interested in being developers in the first place. I'd also like to contribute a lot more to the project than I do now, and to help remove duplication of effort.
I also realize that XFree86.org does not have the manpower or volunteer time to necessarily contribute to these ideas as they already have their hands quite full. So by helping to organize external community projects that do not make demands upon XFree86.org members, I think many of us developers can accomplish a lot of work on our own, which we can then submit to XFree86.org at intervals that are more convenient for them, rather than things sitting in patch queues for months on end, awaiting volunteer time.
Anyhow, this is a rather long entry, comprised of various thoughts that have been on my mind for quite some time. Many thoughts of which people have ignored that I've mentioned things too, or have refused to comment on for whatever their reasons. Perhaps I should be more proactive with my ideas and see where it leads. I'll start with the Radeon driver and see where that goes...
I just got back from OLS a day or so ago. OLS was a blast. Don't be fooled! OLS is not a Linux Symposium, it is an alcoholic symposium! Sure, there were Linux presentations, BOF sessions, and other Linux related things going on, but that is just a front for the REAL reason OLS exists - to get piss drunk!
Alan and Telsa shared their hotel suite with me during the symposium, and we imbibed in many different spirits during the 6 day drink fest that endured. ;o) One thing that prevails in Ottawa, is bars and pubs. I've never seen a town anywhere that has street after street of fine drinking establishments. I now understand why the Symposium is held in Ottawa. ;o)
After Canada day, I visited an old drinking buddy Richard in Ottawa and partied for a few days with him and other friends. After Ottawa I went to Toronto for the remainder of the week. I walked around Toronto for several days until my feet fell off. I am still recovering from the blisters.
While in Ottawa and Toronto, I finally got a chance to work on my music collection of the bands "Annihilator", "Dream Theatre", "Symphony X", and "Rhapsody". I'm only missing one DT album now, one Annihilator, a few Symphony X CD's, and am just beginning my Rhapsody collection. $600 worth of music. I'm afraid to look at my VISA bill for the whole OLS/Ottawa/Toronto rendezvous as it will likely be quite scary. Oh well, I had a great vacation, so it was worth it. Might as well enjoy things while I'm here, as I can't take it with me when I go right? ;o)
I'll be posting my OLS pictures somewhere on http://people.redhat.com/mharris/ once I pick up a CF reader soon. Now that I'm back, it is time to catch up on email and bug reports.
You're in a twisty maze of deeply nested heirarchial directories. There are Imakefiles in all directions. Beware you do not become eaten by a grue.
Having now used various Intel ia64 machines, I am completely unsatisfied with the slow kludgyness, and personally am convinced that ia64 does not show much promise for the future at all, at least not in its current state. "Take three swings, then go sit down."
On the other hand, AMD's x86-64 Hammer processor I believe will be the next logical step in the evolution of the modern deskop PC, not to mention servers, and high end workstations as well.
The Hammer processor, being a clean 64bit extension to the existing Intel ia32 architecture, breathes new life into the aging legacy of Intel dominated computerland.
Being as interested in x86-64 as I am, I decided last night to finally download the Simnow Hammer processor simulator from the above URL, and give it a whirl. My goal was merely to get it to boot up a standard 32bit x86 kernel and get into userland. After a few bumps I had from misreading the fairly poor documentation, I got it up and going, and booted a boot disk I had laying around. While it was an interesting experience in a small sort of way, it was more of a computer-geek-with-a-new-toy thing than it turned out to be actually useful. My test system is a dual 1Ghz P-III Xeon with 1Gb of RAM. The simulator took about an hour just to post the BIOS, which was quite disappointing. It took another hour for it to get to the point of decompressing the kernel. Then it got to the Bogomips calculation and sat there for another hour or so. Finally it started initializing the kernel, and then eventually completely died with a kernel panic.
While the experience did fail, it was worthwhile enough to conclude one thing: Simnow is totally useless from any practical standpoint. I could watch the instruction pointer increasing, and almost count faster myself. So basically, dont expect simnow to be useable for any real usage other than watching the registers move, and experimenting with them.
The next logical step was to download the cross compilation utilities, and install them. I'd like to begin building rpm packages at some point, and you need to start somewhere. Ideally I would like to obtain a copy of the Simics simulator from AMD under license and/or real prototype hardware, but for now, I'll suffer with crosscompilers. ;o)
Why doesn't XFree86 3.3.6 just die? I mean really? If you've got a video card from 1993, er.. time for an upgrade. "But it works, and I shouldnt have to upgrade." Well, whatever. Developers splitting their work time between maintaining 80 different versions of XFree86, just so everyone can be happy, means that MUCH less time is spent working on the current technology, which means a longer time period of lag-behind-Microsoft in Linux land.
Sure, not all hardware supported by 3.3.6 is supported in 4.x, however, if distributions continue to ship 3.3.6 forever, there is zero incentive for any developers out there to port existing 3.3.6 drivers to 4.x infrastructure because "it works now already".
If anything, by distros dropping 3.3.6 support sooner, (which is no longer actively maintained upstream I might add), developers have more time to make 4.x better, and not have to worry about coexistance issues, upgrade issues, and many other complexities.
Hardware that isnt supported in 4.x will be much more voiced and known, and the statistics gathered from this process can be used to decide exactly what video drivers are still widely needed that are not part of 4.x yet.
I dunno about other X developers, but I would rather spend time porting a 3.3.6 driver to 4.x infrastructure than continuously have to deal with all of the issues that one must deal with to endlessly support XFree86 3.3.6, Mesa OpenGL software renderer being the primary major annoyance.
There. I feel better now getting that nugget off my chest.
Now, back to my regularly scheduled coredump analysis.
Today I hacked on Mesa fakeglx a fair bit, trying to backport it from Mesa 4.0.1 to Mesa 3.4.2, so that XFree86 4.2.0 libGL will work with XFree86 3.3.6 servers. Lots of fun.
FOAF updates: Trust rankings are now exported, making the data available to other users and websites. An external FOAF URI has been added, allowing users to link to an additional FOAF file.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!