Based on a comment on my last blog entry, I thought I'd elaborate a bit more specifically about -ati in Intrepid.
Thanks for the update! There seem to be quite a few regressions with the ati driver on intrepid... will these receive any special attention in the next few weeks? This is especially needed I think because fglrx will probably not be available at release time.
Hmm, I'd need to know more specifically what you're seeing as regressions - overall to me it feels like a lot of issues have been laid to rest. Compared to the -ati in Hardy, I'd rate the Intrepid -ati to be considerably more stable. It's not perfect, but it's a lot better.
Of course, many times bugs aren't in the X driver, but rather are in mesa, and I think some of the changes in it have introduced problems. However, we've just recently moved to the (hopefully much more stable) mesa 7.2 release. But let's ignore mesa for this blog post.
One thing you might check though. In Hardy, because -ati was so buggy we blacklisted it from compiz for a lot of cases (such as laptops). In Intrepid, due to the improvements, we've been able to drop all the blacklisting. However, that doesn't mean 100% of those issues are fixed. So it's possible (esp. if you're using an ati laptop), that it *seems* like there are more regressions, when really it's just that you didn't have compiz by default before, but do now.
Also, I suspect a lot more people are using -ati now, that may have used -fglrx in the past. The AMD/ATI documentation release stimulated a lot of development work to add longstanding missing features (like 3D capabilities), and to enable support for 5xx/6xx series cards. The lack of these things would have forced people to use the proprietary driver in the past, but with these improvements -ati has become "good enough" for more people. So I could imagine some people are "seeing regressions" whereas in reality maybe they're just remembering -fglrx.
Anyway, those are just guesses without knowing specifics.
Now, historically if you look back to Feisty, that was released right before the AMD/ATI docs were put out, and the 6.6.3 -ati driver included there was considered quite stable, but much more constrained in its functionality. For people with older ATI cards that only care about 2D functionality and don't need xrandr, that 6.6.3 driver was actually quite good, and -ati users still make use of that version when the current one is just too buggy. In Gutsy, we moved to the 6.7 series, which included xrandr and some 3D functionality that made compiz work for many people (but break horribly for others...) We gave -ati a lot of focus during Gutsy, pulling in patches from git, giving Alex ample feedback, and working hard to stabilize it. For Hardy, we pulled back a bit in the interest of stability; compiz blacklisted -ati on laptops, since our testing found there was just way too many random crashers. I'd wanted to put more time into stabilizing -ati, but decided to mostly focus on -intel; I think the -ati in Hardy may have been better overall than the one in Gutsy, but it didn't reach the level of stability that I would have liked for Hardy.
In Intrepid, I've switched gears and focused more of my time on -ati than other drivers. We've been able to remove the -ati blacklisting as discussed above. I've added a quirk system and put in a variety of hardware-specific fixes. So I really think the driver is more stable and more functional than in Hardy, but I'm open to discussion.
One of the major tasks I completed for -ati during Intrepid is reading through every single xserver-xorg-video-ati bug report, and upstreaming all the reports that were reported adequately. Sadly, this amounted to a fairly small number - it's crazy how often people fail to include basic info like Xorg.0.log, lspci, or backtraces and/or haven't re-checked against Intrepid; unless I can reproduce the bug myself, without this basic info we can't troubleshoot or upstream the bug - just plead the user attach the info.
So, for those who are seeing issues, the ball's sort of in your court at this point to make sure the problem is adequately reported (see http://wiki.ubuntu.com/X for a bunch of troubleshooting resources I've written that will be of value.) I've been keeping an eye out for responses to bugs; there probably isn't enough time to fully troubleshoot the bugs at this point, but if an upstream-approved patch comes to light I can certainly look at bringing it.
One new thing I've added in Intrepid are apport hooks for the major X packages. So now you can run `ubuntu-bug xserver-xorg-video-ati`, and it'll take care of attaching all the necessary files and stuff for reporting -ati bugs.
Meanwhile, my plan going forward is to shift focus from specific -ati bug work, to instead set up a driver build system, to build older and newer debs from the -intel and -ati git trees. This is something that's been on my todo list for a long while, but other stuff has kept taking precedence; since we're in freeze now, this seems like a good point to turn attention to this. I made a static prototype a while back to test out the concept just for -intel, and it proved itself nicely for analyzing driver regressions; there's a lot of issues I need to sort out in order to automate the builds and to expand it to cover -ati and maybe other packages, but I'm hoping with a few week's solid focus to make it quite useful.
Thanks for looking into all of those!