Package Details: catalyst-test 15.12-8

Git Clone URL: (read-only)
Package Base: catalyst-test
Description: AMD/ATI Catalyst drivers for linux AKA Crimson. catalyst-dkms + catalyst-utils + lib32-catalyst-utils + experimental powerXpress suppport. PRE-GCN Radeons ARE NOT SUPPORTED
Upstream URL:
Licenses: custom
Conflicts: catalyst, catalyst-daemon, catalyst-dkms, catalyst-generator, catalyst-hook, catalyst-utils, libcl, libgl, mesa-libgl, mesa-libgl-git
Provides: catalyst=15.12, catalyst-hook=15.12, catalyst-libgl=15.12, catalyst-utils=15.12, dri, libatical=15.12, libcl, libgl, libtxc_dxtn, mesa-libgl, mesa-libgl-git, opencl-catalyst=15.12
Submitter: Vi0L0
Maintainer: Vi0L0
Last Packager: Vi0L0
Votes: 167
Popularity: 0.140559
First Submitted: 2010-02-17 20:49
Last Updated: 2016-07-25 20:37

Dependencies (22)

Required by (700)

Sources (26)

  • 4.3-gentoo-mtrr.patch
  • 4.3-kolasa-seq_printf.patch
  • 4.4-manjaro-xstate.patch
  • 4.6-arch-get_user_pages-page_cache_release.patch
  • 4.7-arch-cpu_has_pge.patch
  • arch-fglrx-authatieventsd_new.patch
  • atieventsd.service
  • catalyst.conf
  • crimson_i686_xg.patch
  • dkms.conf
  • fglrx_gpl_symbol.patch
  • grsec_arch.patch
  • lano1106_fglrx_intel_iommu.patch
  • lano1106_kcl_agp_13_4.patch
  • makefile_compat.patch
  • makesh-dont-check-gcc-version.patch
  • pxp_switch_catalyst
  • switchlibGL
  • switchlibglx
  • temp-links-catalyst.service
  • temp_links_catalyst

Latest Comments

mangnome commented on 2016-09-03 16:21

When I try to install catalyst-test on manjaro-gnome 16.06.1 x64 using pamac, near the end of the installation there are conflicts with mhwd, linux310-catalyst, catalyst-utils, and ocl-icd. If I choose y for them to be removed by pamac, it eventually fails because of a break in dependency for mhwd. A few weeks ago I tried to manually remove these packages and reinstall them which broke my manjaro installation badly. Is there a simple fix to this? I have an amd 7950 boost gpu.

Vi0L0 commented on 2016-09-03 07:26

atm im packing myself for short, weekly, vacations so won't be able to test it, but what game exactly you are talking about? I had no problems with ie. Dota 2

If in console you are catching "libGL error: unable to load driver:" errors you can use this tips:

herycp commented on 2016-09-03 04:21

why i cant play new game unity base???

Vi0L0 commented on 2016-07-29 07:08

In amdcccle I'm always disabling v-sync as well, it's not needed when using tear free.
There's also simple tear free switcher which allows switching via console (it comes with desktop entry):

Also keep in mind that working composite has negative impact on performance of fullscreen rendering apps. I'm always disabling this as well before running app/game - in KDE its easy with Alt+Shift+F12 shortcut

Vi0L0 commented on 2016-07-25 20:45

@irton: ah yes, will fix it later silently, thanks

for now I added 4.7 kernel support, it seems to work fine with my amateur patch.

errors that were generated without 4.7 patch were like (could be useful for searchers):
/var/lib/dkms/fglrx/15.12/build/2.6.x/firegl_public.c: In function ?kcl_mem_pat_setup?:
./arch/x86/include/asm/bitops.h:337:29: error: passing argument 2 of ?constant_test_bit? from incompatible pointer type [-Werror=incompatible-pointer-types]
? constant_test_bit((nr), (addr)) \
/var/lib/dkms/fglrx/15.12/build/2.6.x/firegl_public.h:654:21: note: in expansion of macro ?test_bit?
#define cpu_has_pge test_bit(X86_FEATURE_PGE, &boot_cpu_data.x86_capability)
/var/lib/dkms/fglrx/15.12/build/2.6.x/firegl_public.c:4547:9: note: in expansion of macro ?cpu_has_pge?
if (cpu_has_pge)
./arch/x86/include/asm/bitops.h:308:28: note: expected ?const volatile long unsigned int *? but argument is of type ?__u32 (*)[19] {aka unsigned int (*)[19]}?
static __always_inline int constant_test_bit(long nr, const volatile unsigned long *addr)
./arch/x86/include/asm/bitops.h:338:29: error: passing argument 2 of ?variable_test_bit? from incompatible pointer type [-Werror=incompatible-pointer-types]
: variable_test_bit((nr), (addr)))
/var/lib/dkms/fglrx/15.12/build/2.6.x/firegl_public.h:654:21: note: in expansion of macro ?test_bit?
#define cpu_has_pge test_bit(X86_FEATURE_PGE, &boot_cpu_data.x86_capability)

irton commented on 2016-07-04 05:29

script may be with execute permission? eq. 755

Vi0L0 commented on 2016-05-30 18:42

15.12-7: fixed dkms versioning
Also noticed:
- no more wh problems on cs:go on 4.5 and 4.6 kernels - probably valve fixed it;
- for some reason glxgears32 segfaults on my pc (no matter of what catalyst version, didnt check oss amdgpu/radeon):
'glxgears32' terminated by signal SIGSEGV (Address boundary error)
will check it later;
- tomorrow I should be able to update repos, at least [catalyst]

Vi0L0 commented on 2016-05-13 20:55

thanks again :) so it stores modules in two different places... oukaaaay 8)
Arch/dkms wiki should definitelly have more details

runnytu commented on 2016-05-13 20:26

@Vi0L0, no problem we are all humans after all ;P, the best way to clean is 'rm -fr /var/lib/dkms/fglrx' and to install the module for all the installed kernels with 'dkms autoinstall -m fglrx-15.12 -v 6' later with 'dkms status' should see a output like this for all installed kernels, 2 in my case:
fglrx-15.12, 6, 4.5.4-1-ARCH, x86_64: installed
fglrx-15.12, 6, 4.5.4-1-zen, x86_64: installed

Vi0L0 commented on 2016-05-13 19:48

you got the point runnytu, nice finding

I have removed dkms commands from install script, should be fine now.
Previous version was taken from original catalyst-dkms version and it didn't fit arch's newer dkms.
It was creating fglrx.ko module for booted kernel (with "dkms -v fglrx"), then it was overwritten (because defined module name is the same) by dkms itself (with "dkms -m fglrx-15.12").

I'm just not sure how is dkms going to find out about overwritten module (as it was generated using different version, could generate some trash from it that will have to be removed manually. Sorry for the inconvinience.
Possibly the best way to clean after -5 version is to:
1. use `dkms remove -m fglrx-15.12 -v 5 --all` or `dkms remove -m fglrx-15.12 -v 6 --all` after update to -6
2. use `find /usr/lib/modules/ -iname '*fglrx*'` to trace trash and use rm to remove it manually
3. use `dkms install -m fglrx-15.12 -v 6` to build module for booted kernel or reinstall catalyst-test if you got more kernels - I don't know simple way to build modules for all kernels. One can use some loop like `for` for it, but there should be some easier way available.
But even without cleaning it should work fine, eventually there will be some fglrx module trash left after kernel's version bump ;P.

Thanks again runnytu.
And sorry for missing it.

All comments