Installing ATI FGLRX drivers on 13.2 x64... fail

I have a Toshiba P55 with a Radeon card running OpenSUSE 13.2 and KDE:

$ inxi -GGraphics:  Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller
           Card-2: Advanced Micro Devices [AMD/ATI] Venus PRO [Radeon HD 8850M / R9 M265X]
           Display Server: X.Org 1.16.1 driver: intel Resolution: 1920x1080@60.02hz, 1920x1080@60.00hz
           GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 10.3.7

I tried installing the FGLRX drivers using the one-click method detailed here](https://en.opensuse.org/SDB:AMD_fglrx). I rebooted, logged in and there was no change. I then ran

aticonfig --initial

as suggested here](https://en.opensuse.org/SDB:ATI_troubleshooting), rebooted and ended up with the infamous black terminal screen. My xorg.conf checked out fine, apparently – the BUS ID was right and all that. But I was getting a segmentation fault. So I had no choice but to uninstalling the FGLRX drivers and go back to the old ones, since I need to be able to use my computer.

I’d really like to use the best drivers, though, as the open source ones produce a lot of minor visual artifacts when moving windows and such.

Unfortunately, the instructions here](https://en.opensuse.org/SDB:AMD_fglrx) are ancient – and they seem to be the most up-to-date that exist. They only cover up to 12.3 for the zypper method, for example. I’ve searched this forum, but I’ve only found the odd post about specific problems.

To use these drivers, if the 1-click method fails, what do you guys recommend?

Thanks!

Well, if Xorg cannot load the fglrx driver (it will prefer it if it is installed), then forcing it won’t help either most of the time.

I’d really like to use the best drivers, though, as the open source ones produce a lot of minor visual artifacts when moving windows and such.

But in this case you are not using the radeon chip, but intel.

Unfortunately, the instructions here](https://en.opensuse.org/SDB:AMD_fglrx) are ancient

No, they are not. They are fully up-to-date, and are “tested on 13.2” as you can see at the top.
The “Building the rpm yourself” even mentions version 15.9 already, which only exists since a few days…

– and they seem to be the most up-to-date that exist. They only cover up to 12.3 for the zypper method, for example.

But that’s the only place. And only the part about changing the boot loader options is “outdated”, the rest fully applies.

To use these drivers, if the 1-click method fails, what do you guys recommend?

In my experience, if the 1-click method fails, there’s no way to get the driver working.

You could try the makerpm-amd script (see the “Building the rpm yourself” section) to install the latest version of the driver, but that version seems to be in the repo anyway (and the exact same script is used to build the packages in the repo).

Unfortunately, there are some intel/AMD combinations where the fglrx driver doesn’t seem to work at all.
I don’t know a fix for that, except bugging AMD to fix it.

If it is possible, try to disable the intel graphics in your BIOS, maybe fglrx is working then, or you have better results with radeon anyway.

Another option would probably be to install the latest kernel and intel driver.
You might try a Tumbleweed LiveCD to see whether your glitches are fixed.

Thanks for trying to help. It’s a pity that I have this rather good graphics card and can’t use it. It’s the first AMD chip I’ve had in ages, and it’ll probably be the last one, too.

As to the age of the instructions, I was referring to this mainly:

**Warning **Since openSUSE switched from grub legacy to grub2 as bootloader, this procedure below is outdated. someone need to write a new chapter for 12.3 and above, in which kernel boot line is not exposed to end user on the GUI. Newbies will not know what to follow at that case.
I’ll do the job unless someone finish this before me. – marguerite 08:56, 7 May 2014 (UTC)

Would you recommend trying Sebastian Siebert’s script? I’m pretty new to OpenSUSE (I’ve used Debian-based distros for pretty much forever), and I don’t know the implications of this kind of method (for example, if a kernel update will render the system unbootable or kill the ability to get a GUI).

Thanks for your time!

If gaming is the main purpose of your computer than go with Mesa/Gallium, they’re pretty much on-pair with Catalyst on most cards, and always support the latest and greates Xorg and Kernels. For that you can use Tumbleweed. The only reason I can see one using Catalyst is for OpenGL work which is my case.

The OP has a lap top no choice in the “card”

This appears to be one of the hybrid frankanvideo mesh ups. You may be able to turn off the Intel in the BIOS or there may be a setting in the settings program.

Yes, I know.
But you shouldn’t need this, and the rest is fully uptodate.
(not that there were changes in the installation process anyway…)

Would you recommend trying Sebastian Siebert’s script? I’m pretty new to OpenSUSE (I’ve used Debian-based distros for pretty much forever), and I don’t know the implications of this kind of method (for example, if a kernel update will render the system unbootable or kill the ability to get a GUI).

Sebastian Siebert’s script downloads the driver, patches it to work with the latest kernels (not relevant on a standard 13.2 system any more as fglrx does support Kernel 3.16 since some months), creates RPM packages with an added service to recompile the kernel module if necessary, and installs them.
Actually the RPM packages in the repo are created using that script, so there is no difference.

It would be worth a try if the packages in the repo would lag behind, but the repos do contain the latest version at the moment.
So I don’t think this would help.

But again, to say anything, we’d need your Xorg log.
Install the driver again (with the script if you like), and boot normally. If it still crashes, reboot to “Recovery Mode” (2nd entry in “Advanced Options” in the boot menu), and post the file /var/log/Xorg.0.log.old.

Unfortunately, as mentioned, there are some specific chipsets/combinations the fglrx driver doesn’t seem to like. (normally it does support hybrid intel/AMD systems)
In that case you can only wait for a new fglrx version that maybe works and/or complain to AMD.

OTOH, the open source radeon driver is constantly improving, and according to some tests even has a better performance than fglrx on some cards.
I cannot tell you how you would switch between the cards using the open source drivers, but I know it is possible.