Hinweis: Dieser Artikel ist veraltet. Ein neuer Artikel befindet sich hier: openSUSE 11.3 – proprietären Grafik-Treiber ATI Catalyst 10.8 als RPM installieren

ATI Catalyst 10.7 unterstützt jetzt offiziell openSUSE 11.3. Da hat AMD/ATI richtig auf die Tube gedrückt. Eine tolle Neuigkeit: der neue 2D-Treiber scheint jetzt zu funktionieren.

[UPDATE 07.08.2010]
*** Achtung! *** Wichtige Meldung! ***
Mittlerweile wurde das ATI-Repo für openSUSE 11.3 aktualisiert bzw. freigegeben. Jedoch muss ich eindringlich warnen, dass es sich um den ältere ATI Catalyst 10.6 bzw. fglrx 8.741 handelt. Diese Version unterstützt nicht offiziell openSUSE 11.3 und kann sehr wahrscheinlich nach der Installation (ohne X-Konfiguration oder bei aktiviertem Kernel-Mode-Setting) zu einem Ausfall des Desktopsystem kommen. Die genannte ATI-Version aus dem ATI-Repo sollte man nach meiner Empfehlung besser NICHT installieren, sondern man nimmt stattdessen die neuere ATI Catalyst 10.7 (fglrx 8.753) mit der offiziellen Unterstützung für openSUSE 11.3.
[/UPDATE 07.08.2010]

Es gibt 2 Wege den Bau des RPM-Packages durchzuführen.

1. das RPM mit dem Skript makerpm-ati-10.7.sh bauen (empfohlen)
2. das RPM manuell bauen (für Fortgeschrittene)

Der Vorteil zu Punkt 1: man muss sich nicht um die nötigen Packages für den Bau kümmern und man spart sich die Tipparbeit, die Zeit und die Nerven.

Die Anleitung funktioniert mit geringer Abweichung auch unter openSUSE 11.2.

Wichtig: Bevor ihr irgendwelche Fragen an mich richtet, lest euch bitte sorgfältig diesen Artikel durch und achtet auch auf eure Eingaben in der Konsole wegen mögliche Tippfehler. Falls es Probleme geben sollte, schaut bitte unter Troubleshooting nach, ob euer Problem dort schon dokumentiert wurde.

Alle genannten Schritte müssen in der Konsole im Root-Modus ausgeführt werden. Die Installation des RPM-Package „fglrx“ kann im Runlevel 3 oder auch im Runlevel 5 durchgeführt werden. Danach ist ein Neustart des Computers auf jeden Fall erforderlich.

Vorhandene fremde fglrx-Treiber sind auf jedenfall zu deinstallieren, sonst kommt es zu Konflikten bei der Installation dieses selbstgebauten RPM-Package.

Mit fremde fglrx-Treiber sind z.B. folgende gemeint:
– ati-fglrxG01-kmp-{default,desktop,pae,…}
– ati-fglrxG02-kmp-{default,desktop,pae,…}
– x11-video-fglrxG02

Vorhandene fremde fglrx-Treiber auflisten lassen:

rpm -qa | grep -E 'fglrxG01|fglrxG02'

Wenn hier von RPM eine Ausgabe erscheint, müssen diese Package deinstalliert werden:

zypper rm (packagename)

Alternativ kann man auch in YaST nach fglrxG01 bzw. fglrxG02 suchen und entfernen lassen.

RPM mit dem Skript bauen

Das Skript makerpm-ati-10.7.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf dem System werden nach den nötigen Entwicklungspaketen geprüft und ggfs. installiert. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:
-b – Nur das RPM-Package bauen (Standard)
-c <type> – Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d – Nur den ATI-Installer downloaden
-i – Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no> – Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-old2ddriver <yes|no> – den alten 2D-Treiber aktivieren oder deaktivieren
-ux – Nur den gepatchten X-Server installieren. Verbessert die Zusammenarbeit mit dem fglrx-Treiber. (dringend zu empfehlen)
-h – Die Hilfe anzeigen lassen
-V – Version des Skript anzeigen

Downloads:

• Skript: makerpm-ati-10.7.sh
• SHA1: makerpm-ati-10.7.sh.sha1

Empfohlene Vorgehensweise:

Optional: Das System im Runlevel 3 starten oder wechseln:
Beim Booten: Im Bootmenü den Eintrag von openSUSE 11.3 selektieren und auf der Tastatur die Zahl „3“ und Enter drücken und als „root“ einloggen
Im laufenden System: STRG+ALT+F1 drücken und sich als „root“ einloggen. Danach mit folgendem Befehl in den Runlevel 3 wechseln:

init 3

1. Das Skript herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.7.sh

2. Die Prüfsummendatei herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.7.sh.sha1

3. Die Prüfsummendatei gegen das Skript prüfen:

sha1sum -c makerpm-ati-10.7.sh.sha1

Idealerweise sollte folgende Ausgabe erscheinen, andernfalls stimmt etwas mit dem heruntergeladenen Skript nicht:

makerpm-ati-10.7.sh: OK

4. Die Rechte des Skriptes ändern und ausführbar machen:

chown root:root makerpm-ati-10.7.sh && chmod 744 makerpm-ati-10.7.sh

5. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert.

./makerpm-ati-10.7.sh -i

6. Den Rechner neustarten:

reboot

Troubleshooting (RPM mit dem Skript bauen):

• Sollte man nach dem Booten in der Konsole landen, dann erstellt man besser eine Konfigurationsdatei des X-Servers. In diesem Fall bitte als „root“ in die Konsole einloggen und das Skript mit folgendem Parameter ausführen lassen.

  Vorher noch in den Runlevel 3 wechseln:

  init 3

  Bei einem Monitor (Single-Modus):

  ./makerpm-ati-10.7.sh -c single

  Bei zwei Monitore (Dual-Modus):

  ./makerpm-ati-10.7.sh -c dual

  Danach den Rechner neustarten.

• Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4.4 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.7 fehlschlägt. Hierzu gibt es eine einfache Lösung:
  1. Im KDE-Menü auf Systemeinstellungen klicken
  2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
  3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
  4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
  5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
  6. Abschließend auf Anwenden klicken

  Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

• Einige User haben mir berichtet, dass sie Probleme mit dem Kernel-Mode-Setting (KMS) haben. Das Problem läßt sich durch Deaktivierung des KMS-Modus teilweise beheben.

  ./makerpm-ati-10.7.sh -kms no

• Falls unter Firefox oder Thunderbird schwarze Flächen erscheinen, dann liegt es in erster Linie an den neuen 2D-Treiber. Um den alten 2D-Treiber zu verwenden, führt man folgende Kommando aus.

  ./makerpm-ati-10.7.sh -old2ddriver yes

  Hinweis: Falls das Problem mit den schwarzen Flächen in 2D-Anwendungen in der nächsten Version behoben wurde, kann man es wieder deaktivieren:

  ./makerpm-ati-10.7.sh -old2ddriver no

• Wenn das Compositing im OpenGL-Modus in KDE 4.5.0 nicht mehr aktivierbar sein sollte, dann wurde möglicherweise von KWin das Compositing komplett deaktiviert. Schuld ist die Einstellung OpenGLIsUnsafe=true in der Konfiguration /home/USERNAME/.kde4/share/config/kwinrc. Leider gibt es noch keine Möglichkeit diese Option in den Systemeinstellungen von KDE zu ändern.

  Man kann in der Konsole schnell und komfortabel für jeden User im Home überprüfen, ob man von dem Problem betroffen ist. Wenn bei dem nachfolgenden Befehl eine oder mehrere Dateien aufgelistet werden, so ist die Option von KWin bei dem jeweiligen User scharf geschaltet worden:

  grep -l "OpenGLIsUnsafe=true" /home/*/.kde4/share/config/kwinrc

  Es ist wichtig, dass der folgende Befehl im Runlevel 3 ausgeführt wird, sonst werden die Einstellungen von KWin wieder überschrieben. Wie man in den Runlevel 3 kommt, wird oben im Artikel beschrieben. Um das Problem mit „OpenGLIsUnsafe“ für alle User im Home-Verzeichnis zu beheben, gibt man folgenden Befehl als root in der Konsole ein:

  sed -i '/OpenGLIsUnsafe=.*/d' /home/*/.kde4/share/config/kwinrc

  Hintergrundinfo:
  Die Option OpenGLIsUnsafe kam mit der Revision 1079919 und wurde vom Autor Lucas Murray (lmurray) geschrieben. Allerdings ist ein Recheck-Button in der KDE-Einstellung laut einer TODO-Anmerkung im Quellcode in Zeile 156 geplant, um ggfs. die Option OpenGLIsUnsafe zurückzusetzen, was leider bisher noch nicht umgesetzt wurde.
  Quellcode von kwincompositing
  der Diff vom Quellcode zur Revision 1079919

RPM manuell bauen

Das ist der etwas schwierigere Teil. Aber es ist nicht unmöglich.

Für den Bau des RPM-Packages werden folgende Entwicklungswerkzeuge bzw. -packages benötigt

• gcc
• make
• patch
• kernel-devel (openSUSE 11.2: linux-kernel-headers)
• kernel-source
• kernel-{default,desktop,pae,rt,vanilla,xen}-devel

Beim Kernel-Entwicklungspackage ist zu beachten, dass man die richtige installiert hat. Welchen Kernel zur Zeit auf dem System läuft, kann man in der Konsole abfragen:

uname -r

Bei mir ergibt beispielsweise diese Ausgabe:

2.6.34-12-desktop

Also muss im o.g. Fall der Kernel-Entwicklungspackage kernel-desktop-devel installiert sein.

Folgende Schritte werden auf einem 32bit openSUSE-System durchgeführt:
(64bit openSUSE-System weiter unten)

1. Den Installer des proprietären Treiber von ATI herunterladen:
https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-7-x86.x86_64.run

Optional: Das System im Runlevel 3 starten und als „root“ einloggen oder per init 3 wechseln.

2. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-7-x86.x86_64.run --buildpkg SuSE/SUSE113-IA32

3a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx_7_5_0_SUSE113-8.753*.rpm

3b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx_7_5_0_SUSE113-8.753*.rpm

4. Den Rechner neustarten:

reboot

Folgende Schritte werden auf einem 64bit openSUSE-System durchgeführt:

1. Den Installer des proprietären Treiber von ATI herunterladen:
https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-7-x86.x86_64.run

Optional: Das System im Runlevel 3 starten und als „root“ einloggen oder per init 3 wechseln.

2. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-7-x86.x86_64.run --buildpkg SuSE/SUSE113-AMD64

3a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx64_7_5_0_SUSE113-8.753*.rpm

3b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx64_7_5_0_SUSE113-8.753*.rpm

4. Den Rechner neustarten:

reboot

Troubleshooting (RPM manuell bauen):

• Sollte man nach dem Booten in der Konsole landen, dann erstellt man besser eine Konfigurationsdatei des X-Servers. In diesem Fall bitte als „root“ in die Konsole einloggen und folgende Schritte durchführen.

  1. X-Server-Konfiguration verschieben, falls vorhanden:

  mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

  2. Von aticonfig eine neue Konfigurationsdatei erzeugen lassen: (Das Tool aticonfig kann mittlerweile auch eine X-Server-Konfiguration from Scratch erzeugen, jedoch speziell auf den fglrx-Treiber zugeschnitten. Die restliche Hardware wird vom X-Server automatisch erkannt und geladen. Dies sollte in Zukunft vorgezogen werden, falls die Autoerkennung für den fglrx-Treiber oder X -configure nicht funktioniert):

  Bei einem Monitor (Single-Modus):

  aticonfig --initial

  oder bei zwei Monitore (Dual-Modus):

  aticonfig --initial=dual-head

  Hinweis: Falls man bereits in diesem Schritt das Tool aticonfig für die Erzeugung einer X-Server-Konfiguration verwendet hat, so entfallen die nachfolgenden Schritte 3, 3a, 3b.

  3. Die Konfigurationsdatei von aticonfig für die Nutzung des fglrx-Treibers modifizieren lassen.

  3a. Bei einem Monitor (Single-Modus):

  aticonfig --initial --input=/etc/X11/xorg.conf

  3b. Bei zwei Monitore (Dual-Modus):

  aticonfig --initial=dual-head --input=/etc/X11/xorg.conf

• Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4.4 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.7 fehlschlägt. Hierzu gibt es eine einfache Lösung:
  1. Im KDE-Menü auf Systemeinstellungen klicken
  2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
  3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
  4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
  5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
  6. Abschließend auf Anwenden klicken

  Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

• Einige User haben mir berichtet, dass sie Probleme mit dem Kernel-Mode-Setting (KMS) haben. Das Problem läßt sich durch Deaktivierung des KMS-Modus teilweise beheben.

  Es gibt 2 Möglichkeiten KMS zu deaktivieren:

  1. Als Bootparameter: nomodeset
  2. KMS-Modus im Initial Ramdisk grundsätzlich deaktivieren. Einfach die Datei /etc/sysconfig/kernel zur Bearbeitung öffnen und die Zeile mit NO_KMS_IN_INITRD in NO_KMS_IN_INITRD=“yes“ ändern. Anschließend die Initial Ramdisk neubauen lassen:

     mkinitrd

• Falls unter Firefox oder Thunderbird schwarze Flächen erscheinen, dann liegt es in erster Linie an den neuen 2D-Treiber. Um den alten 2D-Treiber zu verwenden, führt man folgende Kommando aus.

  aticonfig --set-pcs-str=DDX,ForceXAA,TRUE

  Hinweis: Falls das Problem mit den schwarzen Flächen in 2D-Anwendungen in der nächsten Version behoben wurde, kann man es wieder deaktivieren:

  aticonfig --del-pcs=DDX,ForceXAA

• Wenn das Compositing im OpenGL-Modus in KDE 4.5.0 nicht mehr aktivierbar sein sollte, dann wurde möglicherweise von KWin das Compositing komplett deaktiviert. Schuld ist die Einstellung OpenGLIsUnsafe=true in der Konfiguration /home/USERNAME/.kde4/share/config/kwinrc. Leider gibt es noch keine Möglichkeit diese Option in den Systemeinstellungen von KDE zu ändern.

  Man kann in der Konsole schnell und komfortabel für jeden User im Home überprüfen, ob man von dem Problem betroffen ist. Wenn bei dem nachfolgenden Befehl eine oder mehrere Dateien aufgelistet werden, so ist die Option von KWin bei dem jeweiligen User scharf geschaltet worden:

  grep -l "OpenGLIsUnsafe=true" /home/*/.kde4/share/config/kwinrc

  Es ist wichtig, dass der folgende Befehl im Runlevel 3 ausgeführt wird, sonst werden die Einstellungen von KWin wieder überschrieben. Wie man in den Runlevel 3 kommt, wird oben im Artikel beschrieben. Um das Problem mit „OpenGLIsUnsafe“ für alle User im Home-Verzeichnis zu beheben, gibt man folgenden Befehl als root in der Konsole ein:

  sed -i '/OpenGLIsUnsafe=.*/d' /home/*/.kde4/share/config/kwinrc

  Hintergrundinfo:
  Die Option OpenGLIsUnsafe kam mit der Revision 1079919 und wurde vom Autor Lucas Murray (lmurray) geschrieben. Allerdings ist ein Recheck-Button in der KDE-Einstellung laut einer TODO-Anmerkung im Quellcode in Zeile 156 geplant, um ggfs. die Option OpenGLIsUnsafe zurückzusetzen, was leider bisher noch nicht umgesetzt wurde.
  Quellcode von kwincompositing
  der Diff vom Quellcode zur Revision 1079919

Feedbacks sind wie immer willkommen.

Sax2 wird in openSUSE 11.3 nicht mehr zur Verfügung stehen, wie bereits auf Heise.de berichtet wurde. Erste Umsetzungen gibt es bereits in openSUSE 11.2, hier fällt die Konfigurationsdatei /etc/X11/xorg.conf im Vorfeld schon weg, als Fallback kann diese Datei jedoch wieder angelegt werden.

Es gibt zusätzlich noch die Möglichkeit per X -configure eine Konfigurationsdatei anlegen zu lassen. Jedoch treten in dieser Konstellation wie auch das automatische Laden des fglrx-Treiber Konflikte auf, in der nicht selten der X-Server nicht mehr startet und man wieder in der Konsole landet. Bei diesem beschriebenen Konflikt wird fälschlicherweise versucht den fglrx-Treiber mit einer niedrigeren Farbtiefe von 8 bit oder auch 16 bit zu initialisieren, woraufhin der Treiber und der X-Server ihre Dienste quittieren. Laut der FAQ auf der AMD/ATI-Webseite wird zur Zeit nur die Farbtiefe von 24 bit unterstützt.

Aus diesem Anlass habe ich mich mit diesem Problem beschäftigt und einen gepatchten X-Servers wegen dem Konflikt mit der Farbtiefe des fglrx-Treibers bereitgestellt. Der X-Server wird gezwungen die Farbtiefe beim fglrx-Treiber auf 24 bit fest zu legen. Danach startet der X-Server mit dem fglrx-Treiber ohne Probleme.

[UPDATE 07.04.2010]
Gute Nachricht für openSUSE-User! Der von mir erstellte Patch für den X-Server wurde für die kommenden openSUSE-Version 11.3 eingepflegt. Nicht desto trotz ist AMD/ATI jetzt am Zug, die Kompatibilität zwischen dem fglrx-Treiber und dem X-Server weiter auszubauen. (Siehe Heise.de) Die Aufnahme des Patches wurde von mir mit einer ausführlichen Begründung für eine Aufnahme beantragt (Nachzulesen im Bugreport https://bugzilla.novell.com/show_bug.cgi?id=593878). Somit dürfte der X-Server in der kommende openSUSE 11.3 mit dem fglrx-Treiber etwas besser zusammenarbeiten.

Es gibt 2 Möglichkeiten den gepatchten X-Server für openSUSE 11.2 zu installieren:

• 1. Installationsanleitung in YaST2
• 2. Installationsanleitung über die Konsole

Installationsanleitung in YaST2

1. YaST2-Kontrollzentrum starten

2. auf Software-Repositories klicken

3. im Dialogfenster „Konfigurierte Software-Repositorys“ unten auf Hinzufügen klicken

4. „URL angeben“ markieren

5. folgenden Repository-Name eingeben: X-Server

6. folgende URL eingeben: http://download.opensuse.org/repositories/home:/Freespacer:/X11:/XOrg/openSUSE_11.2/

7. die Einrichtung mit Okay schließen

8. auf den Repo-Namen X-Server klicken und die Priorität auf 90 setzen

9. mit OK die Konfiguration abschließen

10. im YaST2-Kontrollzentrum auf „Software installieren und löschen“ klicken

11. folgendes im Suchfeld eingeben: xorg-x11-server

12. unten auf den Tab „Versionen“ klicken

13. auf X-Server Repository wechseln (Bitte auf die richtige Systemarchitektur achten!)

14. nun auf Akzeptieren klicken und der gepatchte X-Server wird installiert.

15. Falls eine Konfigurationsdatei /etc/X11/xorg.conf existiert, kann diese für die automatische Konfiguration umbenannt, verschoben oder gelöscht werden.

16. nun den Rechner neustarten

Installationsanleitung über die Konsole

1. zu root werden:

su - root

2. Repository hinzufügen:

zypper ar -f "http://download.opensuse.org/repositories/home:/Freespacer:/X11:/XOrg/openSUSE_11.2/" "X-Server"

Ausgabe von zypper:

Adding repository 'X-Server' [done]
Repository 'X-Server' successfully added
Enabled: Yes
Autorefresh: Yes
URI: http://download.opensuse.org/repositories/home:/Freespacer:/X11:/XOrg/openSUSE_11.2/

3. Priorität des X-Server-Repository erhöhen:

zypper mr -p 90 "X-Server"

Ausgabe von zypper:

Repository 'X-Server' priority has been set to 90.

4. Repository-Cache erneuern lassen. Ggfs. den GPG-Schlüssel vom Repository mit immer (i) akzeptieren:

zypper ref

5. gepatchten X-Server installieren. Downgrade bitte bestätigen (Anmerkung: Es ist kein richtiger Downgrade, lediglich die Patch-Level-Version hat sich geändert):

zypper in -r "X-Server" xorg-x11-server-7.4-61.1

6. Falls eine Konfigurationsdatei /etc/X11/xorg.conf existiert, kann diese für die automatische Konfiguration umbenannt, verschoben oder gelöscht werden.

7. den Rechner neustarten

Nun, dürften die Probleme mit dem X-Server und dem fglrx-Treiber der Vergangenheit angehören.

Falls man doch eine Konfigurationsdatei benötigt, kann man sie sich entweder mittels

X -configure

oder per

sax2 -a

erstellen lassen.