I, however, wanted Compiz, and openGL etc..
This requires me to use a binary blob.
I wasn't comparing radeonHD to nvidia, I was comparing catalyst to nvidia, and I believe nvidia has less problems
I find it very strange that radeonhd is being recommended, not radeon. Surely the Arch maintainers haven't forgotten that radeon supports *all* Radeons and not just the new ones, and that it's also the one that's actually build-tested?
As to the query near the beginning of the topic regarding GLSL, the state of it is that GLSL will probably show up in classic Mesa when somebody actually cares enough to write it, and in Gallium when I start supporting programmable shaders.
The problem is, even when you begin to ignore fglrx, then users will still demand it because of better 3d performane (or they have to tell em to buy a game console instead). So they have to use the ati installer directly, if thats better or not depends on point of view.
I have no problems fixing mistakes when they are discovered.
First of all, let's state that I'm a bit disappointed that a discussion on an open development list hits Phoronix as a news article without asking anyone from the distribution about comments.
Second, when this discussion started, Andy was already pissed off for some months with the way packagers are supported and how the driver works. He has been telling me "I'm giving AMD two more months and then I won't maintain this driver anymore if things don't improve" a while ago. Two months have passed and Andy decided to post on the public development mailinglist that he doesn't like to maintain the AMD Catalyst driver anymore and that we should look for community people to invest their time in this driver.
Note that the situation is not just AMD-specific. Nvidia also has this problem more or less, but they have the advantage that 50% of our developers have an Nvidia card and their drivers are in a better state and are not limited to X.Org architecture.
Remember that none of us gets paid to do Archlinux development. We're all spending spare time in this distribution. We maintain this distribution because we like to do so. When we lose interest in a package and don't want to maintain it anymore, it's better to drop the package to a group of people who are forced to use it, or who do want to maintain it.
As for xorg-server-1.6: This is a side-effect of the problems we face when packaging AMD's catalyst for our distribution. When our catalyst maintainer posts something on the AMD secret beta list, all he gets is silence. There's no information about what's coming up, when what will be supported and when what improvements will be made to the driver.
As it looks now, we're dropping the driver completely now because of compatibility issues with server-1.6, but won't add it back to the main distribution when it receives server-1.6 support. The community can pick up this task if they really want this driver, as there's no maintainer willing to maintain this driver anymore.
As for the radeonhd driver mentioned on the mailinglist as alternative: these people don't maintain the drivers related to X.Org and don't know which driver belongs to which chip exactly. For some newer chips the radeonhd driver works, but for most others the ati driver is the driver they need. Making fun out of someone on a public news site because he inofficially states that the radeonhd driver is an alternative is not a nice thing to do.
Then again, arch-dev-public is a development discussion list, which is public readable. It's not an announcement mailinglist. Articles like these really make me think whether I want to post something to arch-dev-public or just the private arch-dev list.
For your information, my draft for the xorg-server-1.6 announcement went to the private list and won't show up on the public list until all work on xorg-server-1.6 and its drivers are done.
i think this sums up what i wanted to write anyway.My reason for it to go to community is so a TU can dedicate attention to it, Andreas does not want to waste time on fixing this drivers as they are of no particular interest to him. Maybe a TU in community can apply patches to make the x86_64 9.2 release to work. But well, I'm fine with moving them to AUR, there are some distributions that do not provide catalyst at all in any form, comes to mind paldo GNU/Linux.
i haven't been using fglrx somewhere since 8.35. i tried it few times after it improved opengl performance, but i didn't like it.
Also, this is quite relevant information for some Arch Linux users and I'm not sure everyone of them reads that list, so that news item is certainly in order.