Arch Linux Revolts Against ATI Catalyst Driver

[phoronix]

Phoronix: Arch Linux Revolts Against ATI Catalyst Driver

While AMD continues to improve the ATI Catalyst Linux driver from where they were at years ago by introducing new features like CrossFire and OpenGL 3.0 support while addressing outstanding bugs, no Linux graphics driver is yet in a perfect state. As a result from our post yesterday we have read many driver complaints for both ATI and NVIDIA on Linux...

http://www.phoronix.com/vr.php?view=NzEwMg

[JGC_]

Some explanation about the state of Catalyst in Archlinux

I would like to give some more explanation about the situation with Archlinux and Catalyst.
First of all, our current maintainer, Andreas Radke, is subscribed to AMDs beta mailinglist. He receives information and updates to the drivers before they go public. The mailinglist is very low traffic and almost no useful information is given. The driver updates that are announced on this list lately don't show much improvements in the driver itself, but rather "packaging improvements".
Without ugly workarounds that involves symlinking or editing a binary blob using perl or sed, it's not possible to make the current catalyst drivers working on a non-multilib distribution that doesn't ship /usr/lib64. Symlinking /usr/lib to /usr/lib64 is ugly, while the other solution involving editing the binary driver, violates the license agreement we have with AMD (we're not allowed to redistribute modified drivers). Setting LIBGL_DRIVERS_PATH or LIBGL_DRIVERS_DIR environment variables as we did before no longer works with these drivers somehow, the DRI drivers are always loaded from a path where they shouldn't be installed.

Another point is the upcoming release of xorg-server-1.6. As X.Org maintainer on our distribution, I'm preparing the new release today, which means all previous drivers will stop working. All opensource drivers can be rebuilt, Nvidia's drivers can be updated to the latest versions for xorg-server 1.6 support, but AMDs catalyst has no support. There's also no word on upcoming support for xorg-server 1.6, so I guess we'll have to wait for Ubuntu's release again to get a leaked driver that has xorg-server 1.6 support just like when the previous version of Ubuntu was released.

These issues make maintaining a binary, non-free driver a task nobody wants to pick up. Andreas maintains this driver because nobody else in the development team wants to do it, or has the hardware to do it. Now that he's not willing to maintain it anymore, we want to hand it over to the people who have to use it: the community. This can be trusted users who can put binary packages in the community repository, or regular community users who can place this package in AUR as PKGBUILD.

We don't complain about the quality of the driver itself. As your article says, this driver has improved a lot over time. We're complaining about the information given to us as distribution.

[atldpk]

I think this is a difficult decision to take: it is good to make a statement against AMD, but then again, Arch isn't the biggest distro at all (although I have to admit they're certainly growing). And in the end, some user in the community will post packages for the binary driver anyway.

Let's see if AMD will respond to this.

[Redeeman]

I think this is a difficult decision to take: it is good to make a statement against AMD, but then again, Arch isn't the biggest distro at all (although I have to admit they're certainly growing). And in the end, some user in the community will post packages for the binary driver anyway.

Let's see if AMD will respond to this.

they might respond, but will they DO anything? i hardly think so... they cant even take the time to alter some broken text on the driver download site, despite requests for them to do so...

AMD/ATI hardware is simply useless until the free drivers supports what you need, simple as that.

[Vadi]

Gooooood jooooob.

Making the already pitiful driver even harder to use (less quality maintenance). Clearly, they aren't quite caring to the compositing and gaming users.

Only shooting themselves in the foot imho.

[susikala]

they might respond, but will they DO anything? i hardly think so... they cant even take the time to alter some broken text on the driver download site, despite requests for them to do so...

AMD/ATI hardware is simply useless until the free drivers supports what you need, simple as that.

It would be nice if people just stopped using every opportunity to take a bash at AMD/ATI; this shows of a really Windows-user mindset, i.e. "it should just work", regardless of how ugly or buggy the solution is. If you want to things to "just work" and that is your main or only concern, you are advised to use Windows -- most Linux users, I think, would (albeit reluctantly) admit that on this point, Windows excels. Everything works. And what doesn't work you _can_ usually get to operate using some messy solution. It's this monotonic, puerile view that makes Windows (for me at least) so boring to use. Everything works, and every other aspect is pure shit.

But if you're interested in those other aspects too, like performance, security, portability (eg KMS in FreeBSD?), the ability to read and learn every last line of source code that runs on your computer, and change it or fix it to fit your needs, then you would show great appreciation for AMD/ATI's work in the field of graphics. The FOSS drivers are getting better astoundingly fast, and the new Linux graphics infrastructure will allow us to run our systems even more securely and get rid of lots of bugs and slowdowns.

So I think, in general, while Arch Linux's decision to drop Catalyst is, as appears from JGC's post, quite justified and in place, this doesn't subtract from the fact AMD/ATI is currently one of the companies investing the most in open source graphics.

So again, big kudos to AMD/ATI for the hard work -- and sorry for relatively offtopicing.

[muep]

I really think the Arch devs made a good decision while handling this.
Especially considering that they made a public statement that clearly explains
the reasons, and maybe also makes another request for better drivers to AMD.

As a Fedora user, I have been having the same kind of problems as Arch users
lately. When Fedora 9 shipped Xorg-server 1.5 (an RC version, but still one
that had a stable and published ABI, identical to the final 1.5), it took over
half a year to get working drivers for it. Only the release of
Ubuntu 8.10 which had the same Xserver version seemed to make Catalyst support
Xserver 1.5, and even then it took a couple of months (The special beta driver
for Ubuntu didn't either work for everyone).

I know Fedora and Arch Linux aren't officially supported distros for the driver
as Ubuntu is, but I'd really want AMD to start supporting at least the latest
stable releases of X.org, Linux and other key components of the Linux
graphis stack which they depend on, and release their driver in a form that can
easily be packaged for any distribution. The issues which Arch Linux, Fedora,
and probably many other smaller distributions are facing are completely
unnecessary, and they make many distribution developers very busy fixing stuff
at their distribution, when the work could be done just once at AMD's end.

Even after fixing the packaging and component version support issues, there are
some issues in the actual driver that would be very nice to have fixed.
However, they are completely moot, if one can't actually use the driver at all
due to incompatibilities.

Please, AMD, now hurry with Xserver 1.6 support already! I'd like to keep using
your products with Fedora 11, as I currently happen to be able to with Fedora
10.

[sundown]

It's not something new. For instance you can't install the driver on a sidux kernel, although for a differnet reason

[Lattyware]

I would like to give some more explanation about the situation with Archlinux and Catalyst.
First of all, our current maintainer, Andreas Radke, is subscribed to AMDs beta mailinglist. He receives information and updates to the drivers before they go public. The mailinglist is very low traffic and almost no useful information is given. The driver updates that are announced on this list lately don't show much improvements in the driver itself, but rather "packaging improvements".
Without ugly workarounds that involves symlinking or editing a binary blob using perl or sed, it's not possible to make the current catalyst drivers working on a non-multilib distribution that doesn't ship /usr/lib64. Symlinking /usr/lib to /usr/lib64 is ugly, while the other solution involving editing the binary driver, violates the license agreement we have with AMD (we're not allowed to redistribute modified drivers). Setting LIBGL_DRIVERS_PATH or LIBGL_DRIVERS_DIR environment variables as we did before no longer works with these drivers somehow, the DRI drivers are always loaded from a path where they shouldn't be installed.

Another point is the upcoming release of xorg-server-1.6. As X.Org maintainer on our distribution, I'm preparing the new release today, which means all previous drivers will stop working. All opensource drivers can be rebuilt, Nvidia's drivers can be updated to the latest versions for xorg-server 1.6 support, but AMDs catalyst has no support. There's also no word on upcoming support for xorg-server 1.6, so I guess we'll have to wait for Ubuntu's release again to get a leaked driver that has xorg-server 1.6 support just like when the previous version of Ubuntu was released.

These issues make maintaining a binary, non-free driver a task nobody wants to pick up. Andreas maintains this driver because nobody else in the development team wants to do it, or has the hardware to do it. Now that he's not willing to maintain it anymore, we want to hand it over to the people who have to use it: the community. This can be trusted users who can put binary packages in the community repository, or regular community users who can place this package in AUR as PKGBUILD.

We don't complain about the quality of the driver itself. As your article says, this driver has improved a lot over time. We're complaining about the information given to us as distribution.

Until I read this post, I thought this seemed like a rash move at best, but I think this is Phoronix's writeup. The writeup appears to imply this was done as the quality of the driver is bad, which seems odd considering how much ATI have put into the driver recently (it would seem odd to remove it *after* they start improving it, not to mention when nVidia don't do much better).

Shame they apparently have been keeping it in bad shape. That said, any closed software is never going to gel perfectly with any Linux distro, really.

Disclaimer: I am an Arch x64 user with an nVidia card.

[mutlu_inek]

Please add Arch response to Phoronix news item

It would be nice if JGC's official statement in this thread would be elevated to an addendum of the official news item to make the situation more clear. It is great that phoronix uses its visibility to give these issues a platform that might be heard by companies and commercial developers. Thus, I think it is important that the position of Arch Linux is made as clear as possible.