AMD hat einen neuen openSUSE Packaging Script Maintainer für den ATI Installer

Heute fällt für die openSUSE-Community Weihnachten und Ostern auf einen Tag. 8) Stefan Dirsch von Novell hat mich als neuen openSUSE Packaging Script Maintainer bei AMD vorgeschlagen. Daraufhin wurde ich in das „Linux Graphic Driver Beta“-Programm von AMD aufgenommen und erhalte somit Zugang zum Beta Linux Treiber für individuelle Tests und kann so zum openSUSE Paketbau-Skript für den ATI Installer beitragen. Das ging ganz schnell über die Bühne. 8-O Damit bin ich ab jetzt für die Pflege des openSUSE-Packaging-Skripts im ATI-Installer zuständig. *hände reib* Ein einziger Wermutstropfen gibt es leider doch. Das Git Repository vom Upstream, in der ich den überarbeiteten Code hochladen kann, ist defekt. :cry: Bevor ich da eine Änderung hochladen kann, muss ich erst eine Arbeitskopie herunterladen, was leider auch nicht möglich war. Ich hoffe, dass es schnell behoben wird. :-|

Welche Features erwarten wir im nächsten ATI Installer (ATI Catalyst 10.12) für openSUSE?

Zur Zeit überarbeite ich die Skripte und Spec-Dateien für openSUSE lokal (ohne Git Repository), um die Installation und die Wartung des Packaging-Skripts zu vereinfachen. Das ist die erste Priorität. Später werde ich einige nützliche Gimmicks integrieren. 8) Leider wurde in der Vergangenheit am openSUSE Packaging-Skript nur das Nötigste gemacht, weil der ursprüngliche Maintainer urplötzlich verschollen ist. :-?

In der Vergangenheit haben wir den ATI-Installer bemängelt, dass er bis zum heutigen Release nicht so gesprächig war. :evil: Leider sind die einfachen Linux-Anwender früher wie auch heute an der Installation des ATI-Treibers gescheitert, weil er eben nicht viel gesagt hat, wo der Schuh drückt und hat dann gleich die Tür (Löschung des Buildlogs) zugeschlagen. Die Idee eines makerpm-ati-Skript wurde vor fast einem Jahr geboren, um einfach und schnell einen ATI-Treiber zu installieren und dabei möglichst viele Fehlerquellen auszuschalten. Da kommen Nostalgie-Gedanken auf. ;-) Das Skript damals war noch sehr sehr rudimentär und erreicht erst Dank der vielen Rückmeldungen seine heutige Größe und Stärke. 8) Ich habe dem ATI-Installer bzw. Packaging-Skript beigebracht, was richtig reden bedeutet und hat von mir ein Verbose-Schalter spendiert bekommen. Falls ihr es später testet, bekommt ihr garantiert ein Déjà-vu vom makerpm-ati-Skript. ;-)

Das ist der Was-machst-du-gerade-Modus:

VERBOSE="1" ./ati-driver-installer-10-12-x86.x86_64.run --buildpkg SuSE/SUSE113-AMD64

Das ist der Erzähl-mir-alles-Modus:

VERBOSE="2" ./ati-driver-installer-10-12-x86.x86_64.run --buildpkg SuSE/SUSE113-AMD64

Ein Teil vom makerpm-ati-Skript habe ich in den Packaging Skript schon implementiert. Zum Beispiel: Die automatische Erkennung der openSUSE-Version habe ich bereits integriert. Die Angabe der openSUSE-Version und der Architektur kann in Zukunft darauf verzichtet werden:

./ati-driver-installer-10-12-x86.x86_64.run --buildpkg SuSE/SUSE-autodetection

Und jetzt das besondere Highlight. Es gibt die Möglichkeit den Bau eines Treibers für openSUSE 11.4 bzw. openSUSE Factory freizuschalten. Das geht später einfach mit dieser Befehlszeile z.B. für die AMD64-Architektur:

UNSUPPORTED="yes" ./ati-driver-installer-10-12-x86.x86_64.run --buildpkg SuSE/SUSE114-AMD64

Der openSUSE-Packaging-Skript im ATI-Installer ist auf der Überholspur und das alles in gewohnt hoher Qualität direkt aus einer Hand. Ich werde versuchen, so viele Feature wie möglich vom makerpm-ati-Skript zu implementieren. Das ist einer meiner Beiträge an die openSUSE-Community. ;-)

Jetzt muss nur das Git Repository wieder funktionieren und zwar noch vor dem Code-Freeze. Dann habt ihr spätestens am Weihnachten einen ATI-Installer, in dem der openSUSE-Packaging-Skript von mir komplett neu geschrieben wurde. Made by Sebastian Siebert, um es so auszudrücken. Ein kleines Weihnachtsgeschenk für euch. ;-)

Mal sehen wie lange die Nachfrage nach dem makerpm-ati-Skript noch andauert. Irgendwann muss ja mal der ATI-Installer alleine stehen können. :mrgreen:

Attachmate Corporation übernimmt Novell. Was bedeutet das für das openSUSE-Projekt?

In der openSUSE-Mailingliste wie auch in den Foren wird darüber schon diskutiert. Einige openSUSE-User haben mich gefragt, wie es nach der Übernahme von Novell weitergeht. Man fragt sich zurecht, ob es irgendwelche Auswirkungen auf openSUSE hat. Ich will hierzu Aufklärungsarbeit leisten und die offiziellen Pressemeldungen von Attachmate und die daraus resultierenden Folgen einfach und verständlich darlegen.

In der 1. Pressemeldung von Attachmate übernimmt Attachmate die Firma Novell für 2,2 Milliarden Dollar und hält weiter an Novell und SUSE fest. Es werden jedoch die Patente (man spricht vom geistigen Eigentum in bestimmten Teilen der Linux-Software, hierzu später mehr) im Wert von 450 Millionen Dollar an ein Konsortium names CPTN Holdings, in der Microsoft maßgeblich vertreten ist, abgetreten. Jedoch ist man in dieser Pressemeldung noch nicht auf das openSUSE-Projekt eingegangen, um auf die Frage des weiteren Verlauf des openSUSE-Projektes zu beantworten.

In der 2. Pressemeldung von Attachmate gibt die Firma eine Erklärung zum openSUSE-Projekt ab. Zitat: „Das openSUSE-Projekt ist ein wichtiger Bestandteil des SUSE-Geschäft. Wie in der heute bekannt gegebenen Vereinbarung plant Attachmate nach Abschluß der Übernahme SUSE als einen eigenständigen Geschäftsbereich zu betreiben. Wenn diese Transaktion abgeschlossen wurde, rechnet Attachmate Corporation damit, dass nach der abgeschlossenen Transaktion die Beziehung zwischen dem SUSE-Geschäft und dem openSUSE-Projekt sich nicht ändert.“

Was bedeutet das jetzt konkret?

Die Geschäftsbereiche SUSE und Novell werden aufgeteilt. SUSE wird (wieder) zu einer eigenständigen Firma, dass sich ausschließlich auf das Linux-Betriebssystem (SLED und SLES) konzentriert bzw. vertreibt. Die neue (alte) Firma SUSE wird das openSUSE-Projekt (wie bisher auch von Novell) unterstützen. Also bleibt alles beim Alten. Neu ist nur der Name der Firma. :-)

Bei dem Novell/Microsoft-Deal vor 4 Jahren sieht die Sache hier wieder anders aus. Sobald die Übernahme abgeschlossen wurde, ist der Deal zwischen Novell und Microsoft hinfällig. Bei dem Deal ging es darum, dass mögliche Patentverletzungen geduldet werden, um die Interoperabilität zwischen Windows und Linux zu verbessern und so beide Seiten von einer Patentklage absehen. Im Allgemeinen kann es passieren, dass die Unterstützung zu Windows-Systemen in bestimmten Bereichen von Linux komplett oder teilweise wegfallen wird. Ich bin mir sicher, dass es nur bestimmte closed-source Enterprise-Produkte von Novell betreffen. Dazu gehört z.B. das Konvertierungstool in OpenOffice, Anpassungen an der Virtualisierung und Novell eDirectory, dass mit Microsoft AD (Active Directory) zusammenarbeitet. Beide Firmen haben an der Software gearbeitet, um eben die Interoperabilität zwischen den beiden Betriebssystemen zu verbessern. Somit geht das geistige Eigentum (was auch die Patente einschließt) einige Teile der mitentwickelten Software nun auf Microsoft bzw. dessen Konsortium über. Ich bin der Meinung, dass openSUSE davon nicht betroffen ist, sondern viel mehr die Komponenten für SLED und SLES. ;-)

Das einzige Feld, das noch nicht abschließend geklärt wurde, was nun mit der Firma open-slx GmbH geschieht. Die Firma open-slx GmbH hat mit Novell eine Vereinbarung getroffen, den Vertrieb der openSUSE-Box einschließlich 90-Tage-Installationssupport für Privatkunden zu übernehmen. Wird das Geschäftsfeld der openSUSE-Box wieder in die neue SUSE-Firma aufgenommen (was die Schließung der Firma open-slx GmbH zur Folge haben wird) oder verbleibt das Geschäftsfeld weiterhin bei der open-slx GmbH?

Letztendlich muss nur noch die Kartellbehörde in der USA die Übernahme von Novell zustimmen. Sobald diese Hürde geschafft ist, gehört die Firma Novell endgültig Attachmate.

In diesem Sinne können wir nur abwarten und Tee trinken. :-)

openSUSE 11.3 – proprietären Grafik-Treiber ATI Catalyst 10.11 als RPM installieren

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

ATI Catalyst 10.11 (fglrx 8.791) wurde veröffentlicht. Das Skript makerpm-ati-10.11.sh steht ab sofort zum Download zur Verfügung.

Zur Zeit ist noch keine Release Notes veröffentlicht worden.

Inhaltsverzeichnis

Einleitung

*** Wichtiger Hinweis zum ATI-Repo ***
Im ATI-Repo befindet sich noch der ältere ATI-Catalyst 10.6 (fglrx 8.741) Treiber. Daher empfehle ich den Treiber nicht unter openSUSE 11.3 zu installieren. Wenn man trotzdem diesen Treiber installiert, kann es unter Umständen passieren, dass das grafische Desktopsystem komplett ausfällt und nicht selten wird auch die Konsole völlig verzerrt, wobei man nur noch über den Failsafe-Modus wieder ins System kommt.

Diese Anleitung wie auch das Skript werden regelmäßig aktualisiert. Es lohnt sich daher öfter mal vorbei zu schauen oder im Feedreader zu speichern.

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

  1. das RPM mit dem Skript makerpm-ati-10.11.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 und openSUSE 11.1.

Hinweis: 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 fglrx-Treiber aus dem ATI-Repo sind auf jeden Fall zu deinstallieren, sonst kommt es zu Konflikten bei der Installation dieses selbstgebauten RPM-Package.

Mit vorhandene fglrx-Treiber sind z.B. folgende gemeint:

  • ati-fglrxG01-kmp-{default,desktop,pae,…}
  • ati-fglrxG02-kmp-{default,desktop,pae,…}
  • x11-video-fglrxG02

Vorhandene 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 `rpm -qa | grep -E 'fglrxG01|fglrxG02'`

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

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

  1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
  2. Möglicherweise ist die Lösung für das Problem im Troubleshooting vorhanden.
  3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-ati-10.11.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-ati-10.11.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

RPM mit dem Skript bauen

Das Skript makerpm-ati-10.11.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
-irs Das Rebuild-Skript /etc/ati/fglrxrebuild.sh installieren und im Initskript /etc/init.d/xdm einklinken. Das Skript sorgt dafür, dass bei jedem Kernel-Update das fglrx-Kernelmodul vor dem Start der Desktopumgebung gebaut wird. Es wird auch eine Logdatei /var/log/fglrx-build.log angelegt, um mögliche Compiler-Fehler festzuhalten.
-kms <yes|no> Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-old2ddriver <yes|no> den alten 2D-Treiber aktivieren oder deaktivieren
-r|–report erstellt ein Report und speichert diese in eine Datei namens ati-report.txt
-u|–uninstall entfernt ATI Catalyst restlos vom System. Zuerst wird das fglrx-Package (falls vorhanden) vom System deinstalliert. Danach werden vorhandene ATI-Dateien und -Verzeichnisse entfernt. Hinweis: Falls das Rebuild-Skript installiert wurde, wird es ebenfalls entfernt und das Initskript /etc/init.d/xdm wiederhergestellt.
-ur|–uploadreport wie Option –report nur zusätzlich wird der Report auf einem NoPaste-Service sprunge.us hochgeladen und gibt bei Erfolg den Link zurück.
-urs Das Rebuild-Skript /etc/ati/fglrxrebuild.sh deinstallieren und das Initskript /etc/init.d/xdm wiederherstellen.
-ux openSUSE 11.2: Nur den gepatchten X-Server installieren. Verbessert die Zusammenarbeit mit dem fglrx-Treiber. (empfohlen)
-h Die Hilfe anzeigen lassen
-V Version des Skript anzeigen

Downloads:

Empfohlene Vorgehensweise:

Man benötigt hierfür die Konsole mit root-Rechten, um das Skript auszuführen.

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 Desktopsystem: Bitte vom System abmelden. Sobald die grafische Anmeldung erscheint den Tastenkürzel ALT+N oder STRG+ALT+F1 drücken, um in die Konsole umzuschalten. Dann mit dem User „root“ einloggen und mit folgendem Befehl in den Runlevel 3 wechseln:

init 3
  1. Das Skript herunterladen:
    wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.11.sh
  2. Die Prüfsummendatei herunterladen:
    wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.11.sh.sha1
  3. Die Prüfsummendatei gegen das Skript prüfen:
    sha1sum -c makerpm-ati-10.11.sh.sha1

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

    makerpm-ati-10.11.sh: OK
  4. Die Rechte des Skriptes ändern und ausführbar machen:
    chown root:root makerpm-ati-10.11.sh && chmod 744 makerpm-ati-10.11.sh
  5. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert.
    ./makerpm-ati-10.11.sh -i
  6. Optional, aber empfohlen: Das Rebuild-Skript herunterladen und installieren. Das Skript klinkt sich vor dem Start von KDE, GNOME, etc. ein und baut automatisch nach jedem Kernel-Update das fglrx-Kernelmodul neu.
    ./makerpm-ati-10.11.sh -irs
  7. Den Rechner neustarten:
    reboot

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 / openSUSE 11.1: linux-kernel-headers)
  • kernel-source
  • kernel-{default,desktop,pae,rt,vanilla,xen}-devel
  • kernel-syms

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.7-0.5-desktop

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

Folgende Schritte werden auf einem 32-bit wie auch 64-bit 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-11-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:
    • openSUSE 11.3 32-bit:
      sh ./ati-driver-installer-10-11-x86.x86_64.run --buildpkg SuSE/SUSE113-IA32
    • openSUSE 11.3 64-bit:
      sh ./ati-driver-installer-10-11-x86.x86_64.run --buildpkg SuSE/SUSE113-AMD64
    • openSUSE 11.2 32-bit:
      sh ./ati-driver-installer-10-11-x86.x86_64.run --buildpkg SuSE/SUSE112-IA32
    • openSUSE 11.2 64-bit:
      sh ./ati-driver-installer-10-11-x86.x86_64.run --buildpkg SuSE/SUSE112-AMD64
    • openSUSE 11.1 32-bit:
      sh ./ati-driver-installer-10-11-x86.x86_64.run --buildpkg SuSE/SUSE111-IA32
    • openSUSE 11.1 64-bit:
      sh ./ati-driver-installer-10-11-x86.x86_64.run --buildpkg SuSE/SUSE111-AMD64
  3. Das RPM-Package installieren:
    • Neuinstallation:
      rpm -ihv fglrx*SUSE113-8.791*.rpm
    • Update:
      rpm -Uhv fglrx*SUSE113-8.791*.rpm
  4. Den Rechner neustarten:
    reboot

Troubleshooting:

  1. Nach dem Booten sieht man die Konsole (Problem mit der Konfiguration des X-Servers)
  2. Nach dem Booten hat man einen schwarzen Bildschirm (Problem mit dem Kernel-Mode-Setting)
  3. Arbeitsflächen-Effekte (Compositing) in KDE 4.4 bzw. 4.5 ist nicht aktiviert
  4. Arbeitsflächen-Effekte (Compositing) in KDE 4.5 lassen sich gar nicht mehr aktivieren
  5. In Firefox oder Thunderbird erscheinen schwarze Flächen
  6. Im ATI Catalyst Control Center zeigt mir im Abschnitt „Informationen“ noch die alte ATI-Version an, obwohl ich den neuen Treiber installiert und neugestartet habe.
  7. Mein Treiber unterstützt meine Grafikkarte nicht. Was mache ich jetzt?
  1. 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.

    einfache Variante:

    Vorher noch in den Runlevel 3 wechseln:

    init 3

    Bei einem Monitor (Single-Modus):

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

    Bei zwei Monitore (Dual-Modus):

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

    Danach den Rechner neustarten.

    Fortgeschrittene Variante:

    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 --input=/etc/X11/xorg.conf

      oder bei zwei Monitore (Dual-Modus):

      aticonfig --initial=dual-head --input=/etc/X11/xorg.conf
  2. Wenn man vor einem schwarzen Bildschirm sitzt und man weder die Konsole noch den Desktop sieht, dann liegt es höchstwahrscheinlich am neueingeführten Kernel-Mode-Setting (auch KMS genannt). Das Problem läßt sich durch Deaktivierung des KMS beheben.

    einfache Variante:

    Mit dem Skript das KMS dauerhaft deaktivieren:

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

    Fortgeschrittene Variante:

    Es gibt 2 Möglichkeiten KMS zu deaktivieren:

    • Als Bootparameter in GRUB oder LILO: nomodeset
    • KMS im Initial Ramdisk grundsätzlich deaktivieren. Der nachfolgende Befehl schaltet das KMS in der Konfiguration /etc/sysconfig/kernel auf NO_KMS_IN_INITRD=“yes“ aus.
      sed -i 's/NO_KMS_IN_INITRD=.*/NO_KMS_IN_INITRD="yes"/g' /etc/sysconfig/kernel

      Anschließend die Initial Ramdisk neubauen lassen:

      mkinitrd
  3. Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4 bzw. 4.5 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.11 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.

  4. Wenn das Compositing im OpenGL-Modus in KDE 4.5 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

  5. 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.

    einfache Variante:

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

    Fortgeschrittene Variante:

    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:

    einfache Variante:

    ./makerpm-ati-10.11.sh -old2ddriver no
  6. Fortgeschrittene Variante:

    aticonfig --del-pcs=DDX,ForceXAA
  7. Im ATI Catalyst Control Center zeigt mir im Abschnitt „Informationen“ noch die alte ATI-Version an, obwohl ich den neuen Treiber installiert und neugestartet habe.

    Bitte in den Runlevel 3 starten und dort den Treiber mit dem Skript komplett entfernen lassen (Achtung: Falls man die X-Konfiguration /etc/X11/xorg.conf noch manuell angepasst hat, so sollte man diese vorher sichern und später wieder zurückkopieren):

    ./makerpm-ati-10.11.sh -u

    Danach mittels mit dem Skript neuinstallieren:

    ./makerpm-ati-10.11.sh -i

    Abschließend neustarten.

  8. Mein Treiber unterstützt meine Grafikkarte nicht. Was mache ich jetzt? Hier kann man leider nur den Radeon-Treiber verwenden. Man öffnet die Konfigurationsdatei /etc/X11/xorg.conf.d/50-device.conf mit root-Rechten, um diese bearbeiten zu können. Einfach den Krunner mittels Tastenkürzel ALT+F2 öffnen und folgende Befehlszeile eingeben und abschließend mit Enter bestätigen:
    kdesu kwrite /etc/X11/xorg.conf.d/50-device.conf

    In der Zeile 4 bei Driver „radeon“ nimmt man vorne die Raute weg und speichert die Datei ab. Anschließend alle Anwendungen schließen und neustarten.

    Sollte man beim Neustart einen schwarzen Bildschirm bekommen, dann muss das KMS abgeschaltet werden. Bitte einmal diesen Workaround zum Abschalten von KMS im Failsafe-Modus durchführen.

Feedbacks sind wie immer willkommen. :-)

OpenRheinRuhr 2010 – Bericht zur Ausstellung und doppelseitige openSUSE 11.3 Installations-DVD (32- und 64-bit) jetzt bei mir anfordern (limitiert!)

Ich war gestern auf der OpenRheinRuhr 2010 und muss wirklich sagen, dass es eine wirklich interessante Erfahrung war. Ich durfte nette Menschen kennenlernen, die für bestimmte Open-Source-Projekte wie auch Distributionen arbeiten und vor allem auch benutzen. Und noch wichtiger war, dass die Ausstellung gut besucht war. :-)

Womit ich halbwegs gerechnet habe, dass sowohl OpenOffice wie auch LibreOffice vertreten waren. ;-) Die Vorwürfe aus dem LibreOffice-Lager gegenüber Oracle haben nicht abgerissen und klagen weiterhin, dass sie von Oracle geknebelt wurden. Die Meinungen oder Vorschläge zu OpenOffice wurden ständig ignoriert. Daher hat sich das Projekt abgespalten. Ich denke, die Geschichte kennen wir bereits aus der Presse. Jedoch hätte ich nicht gedacht, dass man Oracle so dermaßen in der Luft zerreißt. Scheinbar war die Kluft (wie auch der Frust) doch größer als angenommen.

Wie es zu erwarten war, bin ich am openSUSE-Stand hängen geblieben. ;-) Zwischen durch kam jemand vom KDE-Team zu uns rüber und wir fingen heftig an über Pro und Kontra von KDE und GNOME zu diskutieren. Ich bin auf der Seite von KDE und Sirko K. eher auf der Seite von GNOME. Da ist wohl ein heftiges Bashing und Flaming ausgebrochen. :-) Die Zukunft von GNOME 3.0 hat Sirko K. einmal vorgeführt und war selbst auch über die Möglichkeiten beeindruckt. In KDE sind Teile davon auch enthalten. Wenn man überhaupt weiß, dass diese Einstellungsmöglichkeiten existieren. ;-) Auch potenzielle openSUSE-Interessenten haben sich bei uns über openSUSE informiert. Manche von ihnen haben direkt die Installations-DVD aus der Hand gerissen. Erstaunlich ist es schon. :-)

Netterweise hat Sirko K. mir einen Stapel (15 Stück) Installations-DVD von openSUSE 11.3 mitgegeben. Die hochwertige DVD ist beidseitig gepresst mit je einer 32-bit und einer 64-bit openSUSE-Version. Ihr könnt die kostenlose DVD bei mir gegen eine Unkostenpauschale (Porto + Umschlag) von 2,- Euro erwerben. Nur solange der Vorrat reicht. Bei Interesse einfach eine Mail an mail@sebastian-siebert.de schicken und ihr bekommt die DVD direkt nach Hause geschickt. Diese DVD wäre auch für Menschen interessant, die sowohl 32-bit wie auch 64-bit Maschinen haben oder auch für Administratoren, die nicht alles mit sich herumschleppen wollen. :-)

[nggallery id=3]

Heute ist der letzte Tag der Ausstellung. Ich würde euch empfehlen, die Ausstellung einfach mal zu besuchen. (Anreise) Die Tickets sind wirklich nicht teuer. (Preise) Wer in der Umgebung wohnt und noch kommen möchte, kann es gerne tun. (Öffnungszeiten: 9.30 Uhr bis 18 Uhr) Einen Parkplatz gibt es direkt vor dem RIM und eine Parklücke erwischt man garantiert auch.

openSUSE 11.4 Milestone3 – ATI Catalyst 10.10 installieren

Mit Sicherheit habt ihr schon mitbekommen, dass openSUSE 11.4 Milestone3 veröffentlicht und zum Testen freigegeben wurde. Zudem kann ich euch zu meiner Freude mitteilen, dass ich ATI Catalyst 10.10 auf der o.g. openSUSE-Version zum Laufen bekommen habe. Es war etwas kniffelig, aber letztendlich hat der fglrx-Treiber gegen mich verloren, weil er mal hier (Kernel 2.6.36) nicht bauen und dort (Xorg 7.5 + XServer 1.9.2) nicht laufen wollte. ;-)

Natürlich will ich euch den Patch nicht vorenthalten und kann hier heruntergeladen werden:
ati-10.10-opensuse-11.4-milestone3.patch

Installation auf openSUSE 11.4 Milestone3

  1. Notwendige Pakete installieren:
    zypper in gcc make patch kernel-devel kernel-source kernel-desktop-devel kernel-syms
  2. ATI-Installer herunterladen
    wget https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-10-x86.x86_64.run
  3. Patch herunterladen:
    wget http://www.sebastian-siebert.de/downloads/ati-10.10-opensuse-11.4-milestone3.patch
  4. ATI-Installer auspacken:
    ./ati-driver-installer-10-10-x86.x86_64.run --extract ati-10.10
  5. ATI-Installer patchen:
    patch -p0 <ati-10.10-opensuse-11.4-milestone3.patch
  6. ins ATI-Verzeichnis wechseln:
    cd ati-10.10
  7. RPM-Paket vom ATI-Installer generieren lassen:
    unter openSUSE 11.4 (32-bit)

    ./ati-installer.sh `./ati-packager-helper.sh --version` --buildpkg SuSE/SUSE114-IA32

    unter openSUSE 11.4 (64-bit)

    ./ati-installer.sh `./ati-packager-helper.sh --version` --buildpkg SuSE/SUSE114-AMD64
  8. ins übergeordnete Verzeichnis wechseln:
    cd ..
  9. RPM installieren:
    zypper in fglrx*.rpm
  10. Optional: Xorg-Konfiguration erzeugen lassen:
    aticonfig --initial

Falls das Compositing nicht aktiviert werden kann, bitte das folgende Workaround ausführen:
Arbeitsflächen-Effekte (Compositing) in KDE 4.4 bzw. 4.5 ist nicht aktiviert

Viel Spaß beim Testen mit openSUSE und ATI Catalyst. ;-)