Fglrx/FAQ

Aus Linupedia.org
Version vom 1. Mai 2007, 21:16 Uhr von Revealed (Diskussion | Beiträge) (Q: Spiegelserver für Xorg 7.2 Final Version: (nu is gut.))
Wechseln zu: Navigation, Suche
A T I   T R E I B E R   B U C H      I N S T A L L A T I O N   U N D   K O N F I G U R A T I O N
ATI: Einleitung - Radeon - RadeonHD - fglrx -> Installationsvoraussetzungen - Installation - Manuelle Installation - Installationprüfung - Problemlösungen - SaX2 - FAQ - ATI Schluss

Dieser Teil setzt Installationsvoraussetzungen voraus.

Fglrx Override der X Version

Angenommen, sie haben ihr X aus einem zusätzlich optional hinzugefügten Repository aktualisiert, dann könnte beim ausführen des Assistenten zum installieren des Treibers "fglrx" eine Meldung wie diese ausgegeben werden:

Detected version of X does not have a matching 'x720' directory
You may override the detected version using the following syntax:
     X_VERSION=<xdir> ./ati-driver-installer-<ver>-<arch>.run [--install] 
  • Lösung: Starten Sie den Assistenten mit der angegebenen Syntax, um ein Paket für die naheliegendste X-Version erstellen zu lassen. Achten sie dabei auf die richtige Architektur ihres Systems.
  • Dabei gilt es wieder, "32 bit" und "64 bit" unterscheiden zu können. Ihre Architektur können Sie per Befehl beispielsweise durch nachstehenden Ausgabe überprüfen:
uname -rio
Die Ausgabe könnte wie folgt ausfallen, was auf eine "32 Bit" hinweisen würde (i386):
2.6.18.8-0.1-default i386 GNU/Linux

Wählen sie bitte im Anschluss aus der von fglrx mit ausgegebenen Liste die richtige Version und fügen sie diese mit der richtigen Syntax ein:


  • Beispiel für Liste:
    x430        XFree86 4.3.x
    x430_64a    XFree86 4.3.x 64-bit
    x680        X.Org 6.8.x
    x680_64a    X.Org 6.8.x 64-bit
    x690        X.Org 6.9.x
    x690_64a    X.Org 6.9.x 64-bit
    x700        X.Org 7.0.x
    x700_64a    X.Org 7.0.x 64-bit
    x710        X.Org 7.1.x
    x710_64a    X.Org 7.1.x 64-bit
  • Beispiel für Befehlskette 32 Bit:
X_VERSION=x710 ./ati-driver-installer-TABTASTE.run --install



Wo sind die Logdatei des fglrx Assistenten bei ATI Grafikkarten?

Die Logdatei des installers befindet sich normalerweise (bei openSUSE) in folgendem Pfad:

/usr/share/ati/fglrx-install.log 

Sie ist besonders in Fällen, in denen Fehler bei der Installation ergründet werden möchten von besonderem Nutzen.

Überprüfen mit lsmod und modprobe

  • Erfolgreiches Laden testen:
Ob das Modul erfolgreich gebaut werden konnte und damit auch erfolgreich geladen werden kann, lässt sich anhand des folgenden Befehl und dessen Ausgabe testen:
modprobe fglrx

Wenn dabei eine Meldung wie „FATAL: Not Found“ oder ähnliches ausgegeben wird, dann gab es einen Fehler und dann sollte die "fglrx-install.log" Datei unter „/usr/share/ati/“ zur Diagnose herangezogen werden.

Editoren die bei fast jeder Installation dabei sind, wären beispielsweise "nano", "mcedit" oder "pico". Also in dem Fall kann beispielsweise:
nano /usr/share/ati/fglrx-install.log
eingegeben werden und der Inhalt der Datei würde aufgezeigt.
Dieser Inhalt kann Aufschluss über eventuelle Fehler bei der Installation geben. Falls diese kritisch sein sollten, kann anschließend mit dieser Information im Internet oder im Forum (bitte mit detaillierter Beschreibung wie es dazu kam) -- Hilfe gesucht werden.
  • Keine Ausgabe ist Erfolg!
wenn bei:
modprobe fglrx
keine Ausgabe erfolgt, testen Sie bitte, anhand der Ausgabe von,
lsmod |grep fglrx
ob das erfolgreich geladene Modul entsprechend an der richtigen Schnittstelle in der Ausgabe wiedergespiegelt wird.
  • Beispielausgabe lsmod |grep fglrx (Erfolg):
fglrx                 665980  35
agpgart                35528  2 fglrx,intel_agp

Wichtig! Wenn das Laden des Modul erfolgreich war, resultieren alle weiteren Fehler aus falschen Paketabhängigkeiten oder fehlkonfigurierten xorg.conf Dateien.


Möglichkeiten mit aticonfig

Aticonfig ist Zeilen - bzw. Textbasierend und muss deswegen aus dem Terminal, der Konsole, oder beispielsweise im "Runlevel 3" ausgeführt werden. Das ganze wieder mit entsprechender Berechtigung, um Schreibzugriff auf die "xorg.conf" zu haben.

Um sich die Möglichkeiten des Befehls aticonfig Auflisten zu lassen, reicht die einfache Eingabe von

aticonfig

Dann werden Variationen und Parameter oder Schalter aufgelistet, mit denen die xorg.conf modifiziert werden kann. Vieles davon ist beispielsweise bei der Konfiguration eines Fernsehers sehr hilfreich. Die Ausgabe ist sehr lang und im "runlevel 3" kann das Problem auftauchen, dass nicht alles auf den Bildschirm passt. Hiermit sei Abhilfe geschaffen:

durch drücken von "SHIFT + BildAuf" bzw. "SHIFT + BildAb" kann ein Bildlauf erzielt werden.

Vorweg: Angenommen beim Befehl "aticonfig --initial" käme eine Fehlermeldung, dass die xorg.conf nicht gefunden weden könne, dann wird aticonfig durch den Schalter "--input=/etc/X11/xorg.conf" nachgeholfen. Eine einfache "Single head" Initialisierung müsste dann so aussehen:

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

Wenn jetzt beispielsweise eine einfache Desktopanordnung erwünscht währe, also ein einzelner Monitor (Single head), dann könnte durch einfache Eingabe von:

aticonfig --initial

diese erwünschte vorkonfiguration der xorg.conf erfolgen.

Wenn dualhead genutzt werden möchte:

aticonfig --initial=dual-head --screen-layout=above

Dabei würden eben beispielsweise "dual-head" aktiviert und die Monitore übereinander angeordnet.


Wenn beispielsweise bei 2 Monitoren die Vorzüge des Bigdesktop ausgenutzt werden sollen, also die Horizontale oder Vertikale Anordnung der Monitore als eine große Arbeitsfläche, dann kann dies durch folgenden Schalter erreicht werden:

aticonfig --dtop=horizontal --overlay-on=1

wenn "horizontal" dabei durch "horizontal,reverse" ersetzt würde, dann würden die Monitore zwar horizontal angeordnet aber eben vertauscht also links wäre dann der Monitor welcher ursprünglich rechts angeordnet worden wäre.

Die Auflösung für die Monitore:

Diese kann mit folgenden Befehlen beispielsweise für "Monitor oder Screen 0" eingestellt werden:

aticonfig --resolution=0,1280x1024,1024x768,800x600,640x480

Wobei hier jetzt darauf geachtet werden muss, dass die erste Auflösung nach der "0" die Auflösung ist, mit welcher der Xserver starten würde. Und dass hier alle Auflösungen mit angegeben werden, müssten, die eventuell zum Start bestimmter Programme notwendig sind. Angenommen ein Programm würde 640x480 benötigen um Starten zu können, diese Auflösung wäre aber nicht angegeben, würde das in "Out of Sync" oder einer Fehlermeldung oder ähnlichem resultieren.

Die Auflösung für den 2. Monitor kann beispielsweise durch Eingabe von: aticonfig --resolution=1,1280x1024,1024x768,800x600,640x480 Erfolgen; -- wobei hier "--resolution=0" durch "--resolution=1" für den nächsten Screen oder Monitor ersetzt wurde.

Erwähnenswert sind außerdem, auch wenn Fernseherkonfiguration noch nicht zu den Stärken dieses HowTo´s gehört, folgende Schalter:

--tv-info

Zeigt die momentane verwendete Geometrie des Fernsehers, das Fernseherformat und ob das Gerät physikalisch angeschlossen bzw. aktiviert ist.

Und es kann beispielsweise herausgefunden werden ob ein DVI Schirm überhaupt angesprochen werden kann durch Prüfen der Ausgabe von:

aticonfig --query-monitor

Welches informationen zu angeschlossenen und aktivierten Monitoren zurückliefern wird.


Detaillierte Einstellungsmöglichkeiten bitte selbst nachlesen. Beispielsweise ist es auch möglich die horizontale und vertikale Refreshrate oder "Hz" des Monitors einzustellen, wobei es aber stark auf die physikalischen Eigenschaften und Leistungsfähigkeit des zum Einsatz kommenden Gerätes ankommt. Falsche Einstellungen können dabei das Gerät beschädigen. Deswegen möchte hier an dieser Stelle nicht weiter darauf Eingegangen werden.

POSIX Shared Memory fglrx

Das ganze macht man,um beispielsweise beim ausführen von "fgl_glxgears" folgender Fehlermeldung und 2D Darstellung vorzubeugen:

Using GLX_SGIX_pbuffer
FGLTexMgr: open of shared memory object failed (Permission denied)
__FGLTexMgrCreateObject: __FGLTexMgrSHMmalloc failed!!!

Das kann mit einem Editor nach Wahl erledigt werden natürlich wieder mit entsprechender Berechtigung ausgestattet:

su 

dann beispielsweise mit kwrite die fstab editieren:

kwrite /etc/fstab 

Anschließend sollte dann die Datei /etc/fstab (beispielsweise am Ende) um folgenden Eintrag ergänzt und abgespeichert werden:

tmpfs                /dev/shm             tmpfs      defaults              0 0

und das neu eingetragene "tmpfs" sollte dann direkt in der Konsole oder Terminal gemountet werden durch Eingabe von:

mount /dev/shm

Dadurch wird das virturelle Laufwerk bei jedem Systemstart automatisch mit eingebunden.

Nachbessern Symlinks / fehlende Dateien in Debugmeldung

Nach eingabe nachfolgender Befehle Wird angezeigt, dass diverse Dateien fehlen oder dass etwas nicht gemapt werden könne:

LIBGL_DEBUG=verbose fglrxinfo

(zeigt normal keine Fehler)

su
ldconfig

(zeigt normal keine Fehler) Wenn bei ldconfig „nichts“ ausgegeben wird, war die Konfiguration an dieser Stelle erfolgreich und es kann fortgefahren werden.

Im Fall das es zu Fehlern kam:

  • 64 Bit: Es fehlen libGL´s?:
bitte das hier komplett anschauen: Aber Warnung! Die Pfade für die Symlinks im falle 64 bit sind vermutlich nicht korrekt - leider hat dem Atuor des Beitrages noch niemand auf die Frage geantwortet und: "er verwende mittlerer Weile eine 32 bit Installation bei der es einfacher sei an Lösungen heranzukommen":

UNGELÖST: hilfe zu symbolischen links? Vermutlich müssen die Symlinks mit dem Verzeichnis X11R6 abgeglichen werden... Weil die Pfade die als Lösung für 32 Bit bekannt sind für eine 64 Bit Installation angepasst werden müssen.

  • 32 Bit: Es fehlen libGL´s?

Das Legen des Symbolischen Links erfolgt durch:

ln -sf /usr/X11R6/lib/modules/dri /usr/lib/dri

An dieser Stelle bitte gleich nochmal den Rechner Neustarten – damit die Änderungen wirksam werden. Danach bitte wieder mit einem "berechtigtem Account" oder auch als „root“ zur weiteren Konfiguration Anmelden.

Ansonsten bitte im Forum melden – generell bitte falls irgendwelche Schwierigkeiten auftreten, sollte nicht gezögert werden zu Fragen.

(wird noch nachgebessert --- more coming soon - sorry)

Den Start des Xservers testen

Achtung! Dient auch als Referenz zu Sax2 Problematiken mit fglrx -

Hier sollen möglichkeiten vermittelt werden, wie mit den Ausgaben der Logdateien zu fglrx und bestimmten Fehlermeldungen umgegangen werden kann:

Stellen sie sicher, dass alle benötigten Pakete installiert wurden:

Stellen sie auch sicher, dass das Modul fglrx fehlerfrei geladen werden konnte:


prinzipiell erstellt der Computer beim Start des Xservers eine Logdatei. Darin speichert er Informationen, wie er die Einstellungen der xorg.conf verarbeiten konnte. Nachfolgende Ausgaben hängen also immer von der aktuell verwendeten xorg.conf ab.

  • Diese Informationen werden in folgendem Verzeichnis abgelegt:
/var/log/Xorg.0.log

Bei näherer Betrachtung dieser Datei, wird schnell klar, dass diese auch Informationen beinhaltet, die nicht direkt auf die Fehler hinweisen bzw. für eine Diagnose nicht von relevanz sein müssen.

Dazu gehören informationen, welche in dieser Datei beispielsweise durch "II" am Beginn der Zeile gekennzeichnet werden oder wie der Treiber bei der Wahl des Boardtyps vorgegangen ist.

Aufgrund dieser Kennzeichnungen bietet es sich an, mit einem Tool diese informationen auf die Essenz zu beschränken und direkt auf dem Terminal oder in eine Datei ausgeben zu lassen.

Da aber nicht alle Ausgaben von "II" unnütz sind, wird nachfolgend eine Befehlskette vorgestellt welche gezielt zur Diagnose bei "fglrx" sinnvoll ist:

Diese könnte beispielsweise so aussehen und mit dem tool "egrep" in eine Datei im "tmp" Verzeichnis in ein Textdokument umgeleitet werden:

egrep "WW|EE|dri|drm|enabled|disabled" /var/log/Xorg.0.log >>/tmp/XorgLogEssenz.txt

In dem Textdokument werden sich dann nützliche und mehr essenzielle Meldungen, die für eine eventuelle Korrektur der xorg.conf von Nöten sind finden lassen.

  • Beispiele zur Diagnose anhand des Textdokuments:

Beispiele zu WW (Warnungen):

Warnungen sind nicht immer als kritisch anzusehen und können meistens ignoriert oder nach Wunsch oder aus Optikgründen nachgebessert werden.

Falls sie allerdings diese Warnmeldung erhalten:
(WW) fglrx(0): Probed monitor is YYYxYYY mm, using Displaysize YYYxYYY mm
Dann kann dies in der xorg.conf in der Sektion für Monitor auch entsprechend anpasst werden. Um mit der Optimalen Displaysize arbeiten zu können, müsste die alte Eintragung in der xorg.conf durch die richtige "Probed Monitorsize" ersetzt werden.
Wenn sie die Warnmeldungen zu den Schriftpfaden ihrer xorg.conf verbessern möchten, weil diese als WW verworfen wurden, können Sie diese mit einer # am Beginn der Zeile auskommentieren. Achten sie aber ggf. darauf, dass bestimmte Programme die Sie später nachinstallieren diese trotz des Vorgehens benötigen könnten und sie dann wieder manuell nachbessern müssten um ein Laden zu erzielen.

Meldungen zu enabled und disabled:

auf jeden Fall enabled sollten sein:

  • Acceleration
  • Directrendering

momentan zu Vorbeuge sollten sicherheitshalber disabled sein:

  • Composite
  • AIGLX
Composite sollte aufgrund von Kompatibilitätsgründen mit Xorg 7.2 rc2 deaktiviert werden. Unter Beryl-Xgl hat diese Option bei fglrx keinen Einfluss weil Xgl seine Eigene Composite Extension zur Verfügung stellt. AIGLX sollte generell deaktiviert sein, da seitens fglrx noch keine Unterstützung angeboten wird. Das Aktvieren von AIGLX führt zu einem Fehler. Dieser könnte andere Probleme provozieren, deswegen deaktivieren Sie bitte AIGLX, wenn sie folgende oder eine ähnliche Fehlermeldung erhalten:

EE Kritische Fehler die unbedingt nachgebessert werden sollten:

(EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed(/usr/lib/dri/fglrx_dri.so:
undefined symbol: __driCreateNewScreen_20050727)
(EE) AIGLX: reverting to software rendering
  • Deaktivieren sie AIGLX durch editieren der xorg.conf:
Section "ServerFlags"
  ...
  Option       "AIGLX" "off"
  ...
EndSection

EE Weil nicht alle Module geladen wurden:

  • Prüfen sie in ihrer Section Module ob alles nötige vorhanden ist:
Section "Module"
  Load         "dbe"
  Load         "type1"
  Load         "freetype"
  Load         "extmod"
  Load         "glx"
  Load         "v4l"
  Load         "dri"
EndSection

EE oder Fehlermeldungen zu drm und dri können sich häufig auf Probleme mit falsch platzierten Dateien beziehen:

su
ldconfig
  • bessern sie ggf durch nachinstallieren fehlender Pakete aus, oder legen Sie Symbolischen Links bzw. Platzieren sie Dateien auf welche sich die Fehler beziehen entsprechend.

Generelles, das in der Xorg.conf geprüft werden sollte:

#  Option       "KernelModuleParm" "agplock=0" ##Auskommentieren wegen Fehlermeldung.
   Option      "KernelModuleParm" "locked-userpages=0" ##Anstelle der auskommentierten Option
  • Fügen sie in der Sektion device welche auch die BUS ID beinhaltet falls nicht vorhanden folgende Einstellungen hinzu oder ändern sie die vorhandenen Werte ggf. ab in:
  Option       "EnablePrivateBackZ" "no"
  #Option       "backingstore" "true"
  Option       "XAANoOffscreenPixmaps" "true"

...

Beim öffnen von fgl_glxgears wird alles in 2D dargestellt und es kommt die Meldung:

Using GLX_SGIX_pbuffer
FGLTexMgr: open of shared memory object failed (Permission denied)
__FGLTexMgrCreateObject: __FGLTexMgrSHMmalloc failed!!!

Alles fehlerfrei - wie kann ich kurz testen, ohne ein aufwändiges Spiel starten zu müssen?

fgl_glxgears

Q: ATI: Welche Modules sollte ich in der xorg.conf eingetragen?

A: Folgende Module sollten dort für fglrx eingetragen werden:

Section "Module"
  Load         "dbe"
  Load         "type1"
  Load         "freetype"
  Load         "extmod"
  Load         "glx"
  Load         "v4l"
  Load         "dri"
EndSection

TLS auf den kompatiblen Modus für Wine setzen

TLS kann kann man, wenn man eine ATI Grafikkarte ha, beispielsweise für "wine" bei Workstationprodukten wie folgt in der "xorg.conf" auf den kompatiblen Modus stellen:

 Option       "UseFastTLS" "2"

Q: ATI: Doppelte Einträge in der xorg.conf?

A: Das passiert meistens aufgrund der Annahme, sax2 könne mit der xorg.conf für fglrx perfekt umgehen.

  • Da dies aber zur Zeit nicht immer der Fall ist, sollte generell nach erfolgreichem manuellen Editieren der xorg.conf auf den Einsatz von sax2 verzichtet werden.
  • Auf Doppeleintragungen und deren Sinn ist eventuell zu Achten. - ggf. müssten alle Einstellungen entsprechend nachgebessert werden. Framebuffer Einträge sind sinngemäß der ATI Konfigurationsmethode anzupassen. Lassen sie sich durch Diagnosebefehle und die xorg.log Datei auf den richtigen Weg bringen.

Erstellung eines fglrx RPM

Einleitend ist wichtig zu erwähnen:

Die rpm - und die Installer Methode sollten bitte nicht gemischt zum Einsatz kommen. Also eventuell vorher die ungewünschte Variation deinstallieren.


Wenn ein rpm Paket für die verwendete Distribution mithilfe des ATI Installers erstellt werden möchte, dann wird dazu in diesem Abschnitt geholfen:

Wie üblich muss hier als "su" oder "root" oder mit "sudo" gearbeitet werden.

Zum eigendlichen Akt:

  • bitte in das Verzeichnis mit dem ATI Installer wechseln, in welches sie den Installer heruntergeladen haben - mit:
cd /

Das Auflisten verfügbarer Unterstützung erfolgt mittels:

./ati-driver-installer-8.34.8*TABTASTE.run --listpkg

Mögliche angebotene Variationen werden dadurch aufgelistet und fallen beispielsweise wie folgt aus:

SuSE Packages:

  • SuSE/NLD9-IA32
  • SuSE/SLES9-IA32
  • SuSE/SUSE91-IA32
  • SuSE/NLD9-AMD64
  • SuSE/SLES9-AMD64
  • SuSE/SUSE91-AMD64
  • SuSE/SUSE100-IA32
  • SuSE/SUSE92-IA32
  • SuSE/SUSE93-IA32
  • SuSE/SUSE100-AMD64
  • SuSE/SUSE92-AMD64
  • SuSE/SUSE93-AMD64
  • SuSE/SLED10-IA32
  • SuSE/SLES10-IA32
  • SuSE/SUSE101-IA32
  • SuSE/SLED10-AMD64
  • SuSE/SLES10-AMD64
  • SuSE/SUSE101-AMD64
  • SuSE/SUSE102-IA32
  • SuSE/SUSE102-AMD64

Um für SUSE 10.2 dann aufgrund dieser Liste ein "IA32 - (32 Bit) rpm" zu Erstellen, kann jetzt der Installer folgendermaßen ausgeführt werden:

./ati-driver-installer-8.34.8*TABTASTE.run --buildpkg SuSE/SUSE102-IA32

Das gebaute "rpm" wird dann unter folgenden Verzeichnissen entsprechend der Architektur jeweils abgelegt:

32 Bit:

/usr/src/packages/RPMS/i386 

64 Bit:

/usr/src/packages/RPMS/x86_64 

Und kann bei der 32 Bit Variante für "openSUSE 10.2" beispielsweise folgenden Namen tragen:

fglrx_7_1_0_SUSE102-8.34.8-1.i386.rpm

Danach müsste dieses wieder installiert werden durch:

Wechseln in das entsprechende Verzeichnis mit;

cd /usr/src/packages/RPMS/i386

Und durch Einbinden des rpm´s mit dem Befehl "rpm";

rpm -Uhv --force fglrx_7_1_0_SUSE102-8.34.8-1.i386.rpm

die --force Option kommt hierbei ausnahmsweise zum Einsatz, weil dabei dann sichergestellt wird, dass trotz eventuell vorhandener Dateien erfolgreich installiert wird, bzw. eventuell vorhandene Dateien einfach überbügelt werden. Das ist aber mit Vorsicht zu genießen!

Deinstallation von fglrx

Vorgehensweisen

Auf dieser Seite, soll umschrieben werden, wie der Treiber fglrx jenachdem ob der Assistent zum Installieren verwendet wurde, - oder das eigens erstellte rpm Paket, richtig deinstalliert werden kann:

Dabei gibt es wie gerade schon erwähnt zwei Möglichkeiten:

  • a) die durch einfaches durcharbeiten des Assistent erstellte Installation
  • Zum Assistent:
  • b) die durch das eigens erstellte "rpm" erstellte Installation:
  • Zum RPM:


Deinstallation wenn der Assistent verwendet wurde

Im Verzeichnis /usr/share/ati/ liegt die Ausführbare "fglrx-uninstall.sh" und auch die Logdatei "fglrx-install.log". Um den Treiber "fglrx" zu deinstallieren sollte ein Ausführen des "fglrx-uninstall.sh" Script genügen.

dazu muss wieder entsprechend priviligiert gearbeitet werden. Also beispielsweise kann mit sudo oder als "su" oder als "root" operiert werden:

Dazu müsste dann in das Verzeichnis gewechselt werden mit:

cd /usr/share/ati/

Und danach der Uninstaller ausgeführt werden mit:

./fglrx-uninstall.sh

Unter Umständen können Dateien der fglrx Installation trotz der erfolgreichen Deinstallation zurückbleiben; auch manuell angelegte symbolische Links bleiben dementsprechend normaler Weise erhalten. Dort muss ggf. manuell nachgebessert werden.

Kenntnisse im Umgang mit dem Dateisystem sind dazu eine Vorraussetzung.

Deinstallation wenn das RPM verwendet wurde

Um das fglrx rpm zu Deinstallieren, verwendet man beispielsweise erwähnte Paketmanager. Dies kann beispielsweise auch mittels "rpm" oder einfach im YaST 2 erledigt werden.

dazu sollten die Pakete "fglrx" beispielsweise in der Suchmaske vom Yast2 Paketmanager eingegeben werden und entsprechend zum löschen markiert werden.


In Folgenden Artikeln wird der Umgang mit Paketmanagern und YaST vermittelt:

fglrx nach einem Kernelupdate erneut einbinden

Angenommen ein Kernelupdate für die Distribution musste eingespielt werden, oder ein Patch oder Treiber musste in die Kernel integriert werden. Oder dieser wurde beispielsweise umkonfiguriert und deswegen neugebaut. Dann muss auch das Treibermodul erneut eingebunden, beziehungsweise funktionsfähig gemacht werden.

Bei einem Kernelupdate könnte entweder gleich eine (falls vorhanden) komplett neue Treiberversion integreiert werden.

Achtung:

Falls ein neuer Treiber eingebunden wird bitte vorher die Alte Version sauber deinstallieren.


Ansonsten kann das erneute Einbinden des selben Treibers. Oder Funktionsfähig Machen des Moduls durch manuelles Ausführen des Scripts "fglrx-kernel-build.sh" (befehl von Version 8.35.5) erreicht werden.

Das ganze müsste wieder entsprechend privilligiert ausgeführt werden. Also als "su" oder "root"

Dazu:

  • Anmelden mit berechtigtem Account ("su") und In das Verzeichnis wechseln mit:

cd /usr/bin/

  • Und ausführen mit:

fglrx-kernel-build.sh

  • Abschliessend sollte das Laden des Moduls nochmals geprüft werden mit:
modprobe fglrx
  • Wenn dabei keine Fehlermeldung ausgegeben wird und die Ausgabe von:
lsmod |grep fglrx
  • "fglrx" in der Liste geladener Module wiederspiegelt, kann davon ausgegangen werden, dass das Modul wieder erfolgreich eingebunden werden konnte.

Ergänzung: Das Script "fglrx-kernel-build.sh" lässt sich normalerweise auch global (wieder als su ..) ausführen, ohne das man vorher in das Verzeichnis wechseln muss.

Die Einstellungen der "xorg.conf" müssten abschliessend noch einmal selbständig geprüft werden. Um den Start des Xservers zu Garantieren.

Reparatur des Controlpanel mit älteren Treiberversionen

fglrx vor Version 8.35.5 und das CPL streikt!

Empfohlen wird das Vorgehen in nachstehenden Thread:

Der Trick hat unter 64 bit sowie 32 bit nachweislich funktioniert. Die Fehlermeldung fällt zwar in einigen Fällen anders aus aber die Lösung war meist die Selbe.

Q: Ich habe probleme mit der Darstellung beim Scrollen und verschieben der Icons?:

A: falls in der xorg.conf der Eintrag backingstore existiert, kommentieren sie diesen wie folgt aus:

#   Option       "backingstore" "true"

Quelle: Hilfe Darstellungsproblem KDE

Q: Spiegelserver für Xorg 7.2 Final Version

A: Eine Liste mit Verzeichnissen aus den deutschen Spiegelservern, welche die benötigten Repositories Xorg 7.2 für SUSE 10.2 beinhalten. Wenn Sie die Adresse beim Erstellen einer YAST Installationsquelle in das Feld Server eingeben, lassen sie den Teil nach .de, also alles inklusive /pub/usw... weg:

Im Verzeichnis "repositories" lässt sich unter anderem auch "KDE 3.5.6" finden.) Wenn sie in Yast2 Die Adresse mit dem Menüpunkt "url Angeben" eingeben möchten, können sie die Adressen belassen, wie sie sind. Achten sie darauf, dass diese auf SUSE 10.2 quellen deuten. Achten sie darauf, möglichst ihre Installationsquelle auf ihre bereits verwendeten quellen anzupassen. Es empfiehlt sich erfahrungsgemäß möglichst den selben Spiegelserver für alle Quellen zu verwenden, da dann weniger mehrfachverbindungen abgehandelt werden müssen.

http://ftp5.gwdg.de/pub/opensuse/repositories/xorg72/openSUSE_10.2/
ftp://ftp.rz.uni-wuerzburg.de/pub/linux/opensuse/repositories/xorg72/openSUSE_10.2
ftp://ftp.stw-bonn.de/pub/opensuse/repositories/xorg72/openSUSE_10.2
ftp://ftp.halifax.rwth-aachen.de/opensuse/repositories/xorg72/openSUSE_10.2
ftp://ftp.gwdg.de/pub/linux/suse/opensuse/repositories/xorg72/openSUSE_10.2/
ftp://ftp.tu-cottbus.de/pub/unix/linux/opensuse/repositories/xorg72/openSUSE_10.2
ATI: Einleitung - Radeon - RadeonHD - fglrx -> Installationsvoraussetzungen - Installation - Manuelle Installation - Installationprüfung - Problemlösungen - SaX2 - FAQ - ATI Schluss



Zurück zur Grafikkarten und Monitore