Talk:AMD Catalyst

From ArchWiki
Revision as of 00:16, 19 April 2013 by Fengchao (Talk | contribs) (Kernel development speed)

Jump to: navigation, search

Notes on major overhaul

Hm, I didn't know there was a behind-the-scene page we could discuss this. I had already mentioned some points on the forums I wasn't sure about when I did the major overhaul and update. I will also list them here so other people that don't use the forum can see it (plus my post it already amongst dozens of older ones in the ATI Grill)

  • Xorg example file; is it needed? And if it is, most entries are uncommented and I think we should at least provide some information on the options if we decide to keep it.
  • Installing from AMD. Should we even instruct this? It's absolutely unrecommended and I for one don't know if the instructions are correct.

Thanks for working on this article everyone!

Unia 00:29, 14 October 2012 (Amsterdam)

  • xorg.conf: It exists here for reference to those who need it as a starting point. When I started with Catalyst back in the 8.xx series, there was sporadic (if any) documentation anywhere. As for explaining the options: there are man pages and also maintains a wiki. Make links if you have to.
  • Installing from AMD: Yes, it needs to be here for those who aren't dependent on *more* layers of scripts that obfuscate everything. I for one, value the ability of seeing what is happening on a lower level and troubleshooting it myself. Otherwise I'd still be using Mandriva. As far as being "unrecommended", that is merely a point of view for the reader to consider. If X breaks, would you know how to fix it?

T1nk3r3r (talk) 23:32, 11 January 2013 (UTC)


Successfully merged section from ATI article. Cleaned it up as best I knew how. However, I do not use the packages suggested here (or fglrx anymore for that matter). So we just need someone to update/verify the instructions to what the current packages require for a clean removal. Then the outdated tag can be removed.

Props to User:Unia for your dilligence on this subject. T1nk3r3r (talk) 17:24, 21 January 2013 (UTC)

HD 6870

I think the problems with Radeon HD 6870 are outdated, I use that graphics card and I didn't have any problems at all, even OpenCL works fine. -- Lykos42 14:04, 14 March 2012 (EDT)

Added Template:Accuracy, please next time don't be afraid of adding status templates by yourself :) -- Kynikos 07:59, 15 March 2012 (EDT)

I cannot speak for speak for the HD 6870 but I can confirm that the problem still exists for the E-350 (APU with a HD 6310), and that the posted solution works if the device name is changed (and perhaps without changing it, I didn't test). I have therfore removed the disputed banner and generalized the answer. (As is suspect the fix works for virtually any "unsupported" device). If someone could confirm the naming scheme for the Xorg identifier I would appreciate it. --Eric Vuhl (talk) 12:19, 21 July 2012 (UTC)

Compatibility table

I've been thinking for a while it might be nice to have a compatibility table or something to see which version of Catalyst works with which versions of X and the Linux kernel. Would this be totally off? Is there a better place to see this information? Would there be a better place to store this information? --Freso (talk) 11:01, 22 October 2012 (UTC)


I'm not sure for the need of this, why would people want to use an older version? AFAIK there are no major problems with Catalyst 12.9 nor with Catalyst-legacy. For those two, the information is already there:

1. Users with Radeon HD {2,3,4}xxx can only use catalyst-legacy which supports Xorg <= 1.12 (use [xorg112] repo) 2. Users with Radeon HD => 5xxx should use catalyst which supports Xorg 1.13

Of course, the more info the better, so if you want to add this feel free to do so! ==Unia

vaapi with smplayer

I found smplayer config to use mplayer-vaapi not right. If you set Video output Driver to vaapi or vaapi:gl, you'll not need to add extra options -vo vaapi to mplayer options Mplayer won't work if both -lavadopts and -vo vaapi are set. So we need to turn off -lavadopts option (useful when decode by CPU, but usesless with GPU) by set "Threads for decoding" to 1 in Performance section. Therefore I decided to edit wiki section about using smplayer. Hope this will be useful for someone!


Is catalyst-dkms working fine without the additional mkinitcpio-dkms package?

By working fine i mean will it compile fglrx module for freshly installed kernel in the background?

Building module while system start is not safe. You system will probably start X before module will be build and so X will fail terribly. AFAIK last related post on the forums in telling that the additional mkinitcpio-dkms package is needed.

If it's needed then such information should be added to the wiki.

Even more - if it's needed then i would say that mkinitcpio-dkms package should be added to the community and catalyst-dkms should depend on it, otherwise it's hard to consider catalyst-dkms as "safe". --Vi0L0 (talk) 10:22, 22 March 2013 (UTC)

What's more of an issue for now, is if catalyst-dkms will remain available in the repositories now that xorg-server 1.14 became available. Do you have contact with its maintainer?Unia (talk) 15:07, 22 March 2013 (UTC)

There was a threat on arch-dev-public: [1]. Looks like it will stay.--Vi0L0 (talk) 19:28, 22 March 2013 (UTC)

Kernel development speed

In the page it says: Recently, development and updates of the Linux kernel have speed up, which is causing that incompatibilities between the Linux kernel and the Catalyst package are showing more often.

It is not true from my experience, the Kernel graphic stack is calming down after KMS change. True, catalyst is always lacking behind cutting edge. But the incompatible is usually happen between Catalyst and Xorg/XServer, not between Catalyst and Kernel. See the this section. If I am wrong, please give out evidence. Or I have to remove the wrong excuse. -- Fengchao (talk) 00:12, 19 April 2013 (UTC)