ubuntuusers.de

ubuntuusers.deWikiGrafikkartenAMDradeon

radeon

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

Der freie Xorg-Treiber radeon unterstützt auf dem Radeon-Chip basierende Grafikkarten. Er wird bei Ubuntu standardmäßig für Radeon-Grafikkarten verwendet. Der Treiber radeon beinhaltet unter anderem volle Unterstützung für:

  • RandR

  • Dual-Head

  • Xinerama

  • Hardware 2D-Beschleunigung

  • 3D-Beschleunigung (s. Tabelle)

  • AIGLX

Entscheidend für die Unterstützung ist die Familie des Chipsatzes, folgende Tabelle gibt einen groben Überblick über den aktuellen Stand der Entwicklung:

Chipsatz-Familie Bezeichnung 3D-Beschleunigung
R1xx Radeon, Radeon 7xxx OpenGL 1.3
R2xx Radeon 8500 – 9250 OpenGL 1.3
R3xx Radeon 9500 – X600, Radeon X1050 OpenGL 2.1
R4xx Radeon X700 – X850, Radeon X1200 OpenGL 2.1
R5xx Radeon X1300 – X1950 OpenGL 2.1
R6xx Radeon HD 2xxx Serie, Radeon HD 3xxx Serie OpenGL 2.1 / 3.0 (ab 12.10/12.04.2)
R7xx Radeon HD 4xxx Serie OpenGL 2.1 / 3.0 (ab 12.10/12.04.2)
Evergreen Radeon HD 5xxx Serie, Radeon R5 220 OpenGL 2.1 / 3.0 (ab 12.10/12.04.2)
Northern Islands Radeon HD 6xxx Serie, Radeon HD 7450 – 7670, Radeon HD 8350 – 8400, Radeon R5 235 OpenGL 2.1 / 3.0 (ab 12.10/12.04.2)
Southern Islands Radeon HD 7730 – 7770, Radeon HD 7850 – 7970, Radeon HD 8570 – 8970,
Radeon R5 240, Radeon R7 240 – 250, Radeon R7 265, Radeon R9 255, Radeon R9 270
Keine / OpenGL 3.3 (ab 14.04)
Sea Islands Radeon HD 7790, Radeon R7 260, Radeon R9 290 Keine / OpenGL 3.3 (ab 14.04)

Hinweis:

Diese Tabelle ist unvollständig und bietet nur einen groben Überblick. Es besteht nicht immer ein klarer Zusammenhang zwischen Bezeichnung und Chipsatz, insbesondere bei integrierten und mobilen Grafikkarten. Umfangreichere Informationen finden sich im X.Org Wiki {en} und in der Wikipedia.

Achtung!

Grafikkarten die erst nach Veröffentlichung der jeweiligen Ubuntu Version erschienen sind werden nicht unterstützt, auch wenn die Familie des Chipsatzes schon unterstützt wird, da der Kernel zu alt ist um sie zu erkennen.

Installation

Der Treiber ist bei einer Standard-Ubuntu-Installation bereits vorinstalliert. Sollte dies nicht der Fall sein, kann der Treiber über die Paketverwaltung installiert[1] werden. Folgendes Paket wird benötigt:

  • xserver-xorg-video-ati

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install xserver-xorg-video-ati 

sudo aptitude install xserver-xorg-video-ati 

Hinweis:

Die Installationsmedien von Precise Pangolin haben mit der Veröffentlichung von 12.04.2 einen neueren Kernel (3.5) und XServer (1.13) bekommen, die separat unterstützt werden. Dadurch haben alle Pakete, die ebenfalls eine separate neue Version bekommen mussten, neue Namen bekommen. Betroffene 12.04 Nutzer mit den neueren Komponenten benötigen daher statt xserver-xorg-video-ati das neue Paket xserver-xorg-video-ati-lts-quantal, bzw. -raring oder -saucy.

Aktivierung des Treibers

Der Treiber wird normalerweise automatisch benutzt, wenn ein entsprechender Chipsatz gefunden wird und kein anderer Treiber angegeben ist. In diesem Fall sind keine weiteren Schritte notwendig.

Sollte dies nicht der Fall sein, oder ist ein anderer Treiber aktiviert, kann der radeon-Treiber explizit in der Konfigurationsdatei des XServers /etc/X11/xorg.conf eingetragen werden. Dazu wird die Konfigurationsdatei mit einem Editor [2] mit Root-Rechten bearbeitet. Der Abschnitt "Device" ist um den Eintrag Driver "radeon" zu ergänzen bzw. ein bestehender Eintrag zu ändern:

Section "Device"
	Identifier	"Configured Video Device"
	Driver		"radeon"
EndSection

Nach einem Neustart sollte der Treiber aktiv sein.

Konfiguration

Die Konfiguration des Treibers teilt sich auf das Kernel Modul und den Xorg Treiber auf. Da mit der Einführung von Kernel Mode-Setting große Teile des Treibers nun im Kernel arbeiten, spielt die Konfiguration des Kernel Moduls nun eine größere Rolle.

Xorg Treiber Optionen

Zusätzliche Optionen können im Device-Abschnitt der Datei /etc/X11/xorg.conf angegeben werden, die mit Root-Rechten bearbeitet[2] werden muss. Eine ausführliche Liste aller möglichen Optionen inklusive der jeweiligen Standardwerte ist in der radeon-Manpage zu finden.

Section "Device"
...
        Option 		"<OPTION>" "<WERT>"
EndSection

Folgende Optionen sind verfügbar, statt "on"/"off" kann auch "yes"/"no", "true"/"false" oder "1"/"0" verwendet werden:

Optionszeile Werte Beschreibung
Option "SWcursor" "on"/"off" Deaktiviert die Hardware-Unterstützung des Mauszeigers
Option "NoAccel" "on"/"off" Deaktiviert jegliche Hardware-Beschleunigung
Option "ColorTiling" "on"/"off" Organisiert den Framebuffer in Kacheln statt in Bildzeilen. Kann die 3D Leistung signifikant steigern. Benötigt mindestens einen R3xx Grafikchip.
Option "ColorTiling2D" "on"/"off" Benutze zweidimensionale Kacheln. Kann die 3D Leistung im Vergleich zu eindimensionalen Kacheln noch einmal signifikant steigern. Benötigt mindestens einen R6xx Grafikchip, erst seit Ubuntu 12.10 verfügbar.
Option "EnablePageFlip" "on"/"off" Benutze Page Flip. Verringert im Zusammenspiel mit VSync die Gefahr von Tearing.
Option "AccelMethod" "XAA"(bis 12.04), "EXA" oder "glamor"(ab 13.10) Bestimmt die zu verwendende Architektur für die unabhängige 2D Hardware-Beschleunigung des XServers. XAA ist obsolet und wurde durch das schnellere aber Speicher-intensivere EXA ersetzt, die neue Glamor Architektur greift direkt auf die vorliegende OpenGL Implementation zurück.

Folgende zusätzliche Optionen sind für das standardmäßig verwendete EXA verfügbar:

Optionszeile Werte Beschreibung
Option "EXAVSync" "on"/"off" Reduziert Tearing auf Kosten der Leistung. Kann mit ein paar Grafikchips instabil sein.
Option "EXAPixmaps" "on"/"off" Benutze heuristische Verfahren zur Speicherorganisation für Bilddaten. Verursacht die Korruption von Bilddaten auf Grafikkarten mit sehr wenig Speicher.
Option "SwapbuffersWait" "on"/"off" Benutze eine tiefer greifende Methode zur Verhinderung von Tearing. Kann einen sehr negativen Einfluss auf Frameraten unterhalb der Bildwiederholfrequenz des Monitors haben.

Kernel Modul Optionen

Die Optionen für das Kernel Modul müssen als Parameter übergeben werden, dafür gibt es zwei Methoden. Entweder die Parameter werden dem Kernel in der Bootzeile übergeben (siehe auch Bootoptionen), oder man legt mit Root-Rechten[2][4] im Verzeichnis /etc/modprobe.d eine neue Datei für die Optionen an.

Als Bootoption haben die Parameter folgenden Aufbau:

radeon.<OPTION>=<WERT>

Die Dateien im /etc/modprobe.d Verzeichnis können beliebig benannt werden, müssen aber auf .conf enden. Dort können mehrere Optionen entweder Zeilenweise oder in einer Zeile mit folgendem Aufbau angegeben werden:

# Mehrere Optionen in einer Zeile
options radeon <OPTION>=<WERT> <OPTION>=<WERT>

# Eine Option pro Zeile
options radeon <OPTION>=<WERT>
options radeon <OPTION>=<WERT>

Unter Umständen, z. B. bei der Verwendung einer verschlüsselten Partition, muss zusätzlich mit folgendem Befehl[3] das Initramfs für die vorhandenen Kernel neu generiert werden, damit die Änderungen in der Datei übernommen werden:

sudo update-initramfs -u -k all 

Achtung!

Alle Optionen sollten als temporäre Bootoption zuerst getestet werden, bevor sie dauerhaft eingetragen werden. Der Kernel reagiert nicht sehr tolerant auf fehlerhafte Optionen und die Kernel Module können im Laufe der Zeit ihre Optionen ändern. Es wird empfohlen sich zusätzlich mit modinfo radeon die komplette Liste der verfügbaren Optionen des vorliegenden Kernel Moduls anzuschauen.

Folgende Optionen sind für das Kernel Modul verfügbar:

Option Werte Beschreibung
modeset 1/0 Legt fest, ob das neue Kernel Mode-Setting genutzt wird. Das Deaktivieren hat die gleiche Wirkung wie die Bootoption nomodeset.
dynclks 1/0 Aktiviert die Unterstützung für das dynamische Takten des Grafikchips.
vramlimit Zahlenwert Beschränkt für Testzwecke den Grafikspeicher auf die angegebene Menge. Angabe in MiB.
agpmode -1, 1, 2, 4 oder 8 Legt den AGP Modus fest (-1 für PCI Karten)
gartsize Zahlenwert Legt die Größe des GART Speichers fest. Angabe in MiB.
tv 1/0 Aktiviert den analogen TV Anschluss. Kann genutzt werden um einen erkannten aber nicht vorhandenen Fernseher zu entfernen.
audio 1/0 Schaltet die Unterstützung für die Audiowiedergabe über HDMI ein.
hw_i2c 1/0 Schaltet die I²C Unterstützung ein. Wird zum Auslesen der Temperatursensoren benötigt.
pcie_gen2 1/0 Aktiviert den schnelleren Übertragungsmodus von PCIe Version 2.0
dpm 1/0 Aktiviert die neue Stromspar-Architektur für Radeon HD Karten (ab Ubuntu 13.10 bzw. Kernel 3.11)

Stromsparfunktionen

Mit dem Wechsel zu Kernel Mode-Setting (KMS) sind auch die Stromsparfunktionen nun ein Teil des Kernel Moduls des Treibers geworden. Da diese Einstellungen im laufenden Betrieb änderbar sein müssen, weicht die Konfiguration der Stromsparfunktionen stark von den zuvor genannten Konfigurationsmöglichkeiten ab.

Mit Kernel 3.11 und somit Ubuntu 13.10 wurde die von AMD entwickelte neue „Dynamic Power Management“ (DPM) Stromspar-Architektur eingeführt, welche die erweiterten Stromspar-Mechanismen aktuellerer Karten der Radeon HD Generationen unterstützt und somit bei neueren Modellen eine höhere Einsparung als die klassische „Dynamic Clocks“ Architektur verspricht, welche lediglich die Taktrate des Grafikchips verändert.

Der aktuelle Zustand der Grafikkarte (Taktraten, Spannung) kann durch das Auslesen einer Gerätedateien mit folgendem Befehl ermittelt werden, dabei unterscheidet sich das Format der Ausgabe je nach verwendeter Stromspar-Architektur:

sudo cat /sys/kernel/debug/dri/0/radeon_pm_info

Sollten mehrere Grafikchips im Gerät verbaut sein, kann die betroffene Karte eventuell einen anderen Index als 0 haben (z.B. 1), der Pfad ist dann entsprechend anzupassen. Die mittels sudo angeforderten Root-Rechte[4] sind erforderlich, weil die debug Schnittstellen des Kernels standardmäßig keine Leserechte für normale Benutzer haben.

Dynamic Clocks

Diese klassische Stromspar-Architektur beschränkt sich auf die Änderung des Taktes mit dem der Grafikchip betrieben wird. Offiziell wurde sie nie als stabil gekennzeichnet, daher ist sie zwar standardmäßig im Einsatz, nimmt aber ohne eigenen Eingriff keine Änderungen vor. „Dynamic Clocks“ arbeitet mit so gut wie jedem Modell zuverlässig, kann allerdings bei aktuellen Karten nicht das volle Sparpotential ausnutzen.

Der Kernel bietet zwei Methoden zum Stromsparen:

  • dynpm - Der Grafikprozessor wird abhängig von der aktuellen Belastung dynamisch getaktet, dabei kann der Taktwechsel zu kurzem Flimmern des Bildschirms führen. Funktioniert nur wenn nur ein Bildschirm angeschlossen ist.

  • profile - Das Taktverhalten wird statisch über ein Profil festgelegt.

  • dpm - Siehe nächsten Abschnitt.

Es stehen dabei folgende Profile zur Auswahl:

  • default - Der Standardtakt wird beibehalten und es wird nichts verändert, dies ist die Standardeinstellung.

  • high - Der Grafikprozessor wird mit hoher Taktstufe betrieben (dies ist in der Regel der Standardtakt).

  • mid - Der Grafikprozessor wird mit mittlerer Taktstufe betrieben.

  • low - Der Grafikprozessor wird mit geringer Taktstufe betrieben, dies kann bei einigen Laptops zu Problemen mit dem Bildschirm führen. Nicht jeder Grafikchip hat mehr als zwei festgelegte Taktstufen, in dem Fall sind low und mid identisch.

  • auto - Es wird zwischen mittlerer und hoher Taktstufe gewechselt, abhängig davon ob der Rechner an einer Stromversorgung hängt oder nur über einen Akku versorgt wird.

Mit Ausnahme des default Profils wird bei allen Profilen auf niedrige Taktstufe gewechselt, wenn der Bildschirm angewiesen wird in den Standby-Modus zu wechseln.

Die Einstellungen können geändert werden, indem die Schlüsselwörter mit Root-Rechten[4] in die folgenden dazugehörigen Gerätedateien geschrieben werden:

/sys/class/drm/card0/device/power_method
/sys/class/drm/card0/device/power_profile

Dabei ist zu beachten, dass bei Systemen mit mehreren Grafikkarten der Pfad eventuell angepasst werden muss (z. B. card1 statt card0). Um bspw. testweise zur dynpm Methode zu wechseln, kann folgender Befehl genutzt werden:

echo dynpm | sudo tee /sys/class/drm/card0/device/power_method 

Wie bei jeder Einstellung, die über eine Gerätedatei vorgenommen wird, ist sie nach einem Neustart verloren. Wenn die Änderung dauerhaft übernommen werden soll, muss sie bei jedem Startvorgang angewendet werden. Eine Möglichkeit ist, die Änderungen als einfache echo Befehle in die Datei /etc/rc.local einzufügen.[2] Wenn etwa dauerhaft das Profil auto aktiv sein soll, könnte die rc.local so aussehen:

echo profile > /sys/class/drm/card0/device/power_method
echo auto > /sys/class/drm/card0/device/power_profile

exit 0

Dynamic Power Management

Die DPM Unterstützung kann nur mit Karten der HD Generationen verwendet werden, ältere Karten sind auf die alte „Dynamic Clocks“ Unterstützung angewiesen. Da der in Ubuntu 13.10 enthaltene Kernel die erste Version mit dieser Architektur ist, kann die Verwendung von DPM mit einzelnen Karten noch instabil oder unzuverlässig sein. Durch diesen experimentellen Zustand ist DPM noch standardmäßig deaktiviert und muss mithilfe der dpm Kernel Option erst aktiviert werden.

Sollte das Standardverhalten von DPM nicht den eigenen Vorstellungen entsprechen, lässt sich selbst eine der folgenden Verhaltensweisen festlegen:

  • balanced - Ein ausgewogener Kompromiss aus Sparsamkeit und Leistung, dies ist die Standardeinstellung.

  • battery - Es wird aggressiver gespart, um die Akkulaufzeit von Mobilgeräten zu maximieren.

  • performance - Es wird versucht auf Kosten der Sparsamkeit möglichst viel Leistung zur Verfügung zu stellen, wenn diese benötigt wird.

Bei diesen Verhaltensweisen wählt der Treiber ein passendes von der Hardware angebotenes Profil mit mehreren Taktstufen, zwischen denen die Grafikkarte eigenständig Last-abhängig wechselt. Nicht jede Grafikkarte bietet für jede der drei Kategorien ein Profil an, so kann der Treiber sich etwa bei einem fehlenden balanced Profil stattdessen auch für ein battery Profil entscheiden.

Alternativ kann die Karte auch in einem konstanten Zustand gehalten werden, dazu stehen folgende Optionen zur Verfügung:

  • auto - Erzwinge keinen Zustand, damit nach dem aktuellen Verhaltensmuster dynamisch gewechselt werden kann. Dies ist die Standardeinstellung.

  • low - Erzwinge den niedrigsten Zustand, um z.B. bei fehlendem Bedarf an Grafikleistung durch den Benutzer den Verbrauch zu minimieren.

  • high - Erzwinge den höchsten Zustand, um ohne Rücksicht auf den Verbrauch immer die größte Leistung zur Verfügung zu haben. Dies kann bei schlechter Kühlung allerdings zur Drosselung durch Überhitzen bis hin zu einem Absturz führen.

Diese Einstellungen können über das Schreiben der jeweiligen Schlüsselwörter in folgende Gerätedateien verändern werden:

/sys/class/drm/card0/device/power_dpm_state
/sys/class/drm/card0/device/power_dpm_force_performance_level

Die Verhaltensmuster lassen sich analog zu den Profilen von „Dynamic Clocks“ anwenden, auch hier kann bei Systemen mit mehreren Grafikchips der Pfad anders ausfallen (card1 statt card0). Dementsprechend kann auf gleiche Weise mit folgenden Befehlen vorübergehend das Verhaltensmuster zu Testzwecken auf battery geändert werden oder der niedrigste Zustand erzwungen werden:

echo battery | sudo tee /sys/class/drm/card0/device/power_dpm_state 

echo low | sudo tee /sys/class/drm/card0/device/power_dpm_force_performance_level 

Für eine permanente Änderung der Einstellungen kann auch hier analog zu „Dynamic Clocks“ auf entsprechende echo Befehle in der /etc/rc.local Datei zurückgegriffen werden.

Hardware-beschleunigte Videodekodierung

Seit Trusty Tahr ist der Treiber in der Lage, die ab der HD 4000 Serie verbauten UVD Einheiten der 2. Generation (und neuer) zu verwenden, um über VDPAU diverse Videocodecs direkt von der Hardware dekodieren zu lassen. Davon ausgenommen sind allerdings HD 4730, HD 4830-4890, Mobility HD 4850/4870 sowie die integrierte Grafik der AMD 700 Chipsatzfamilie, da sich die UVD Einheit dort von der restlichen Serie unterscheidet. Alle Karten ab der Radeon 9500 sind darüber hinaus auch ohne die UVD Einheit in der Lage, über einen generischen Codec zumindest MPEG1 und MPEG2 kodierte Videos (Video-CD, DVD-Video, DVB SDTV Signale der ersten Generation) über ihre Shader Einheiten beschleunigt zu dekodieren, auch wenn diese Codecs bereits relativ wenig Leistung benötigen.

Aus Platzgründen werden die nötigen Dateien für die UVD Unterstützung nicht vorinstalliert, weshalb die Installation des folgenden Pakets notwendig ist:

  • mesa-vdpau-drivers

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install mesa-vdpau-drivers 

sudo aptitude install mesa-vdpau-drivers 

Probleme

Konflikt mit fglrx

Beim Wechsel von dem proprietären ATI-Treiber (fglrx) zu radeon kann es zu Konflikten zwischen beiden Treibern kommen, wenn der fglrx-Treiber unvollständig deinstalliert wurde. Dies kann sich durch Abstürze, Fehler beim Systemstart, Geschwindigkeitsprobleme und fehlende 3D-Unterstützung äußern. Abhilfe schafft die Deinstallation des Pakets: fglrx bzw. bei der seit Oneiric ebenfalls verfügbaren aktualisierten Version fglrx-updates (bei manuell durchgeführter Installation des fglrx-Treibers siehe hier). Anschließend müssen die folgenden Pakete erneut installiert werden:

  • libgl1-mesa-glx

  • libgl1-mesa-dri

  • xserver-xorg-video-radeon

  • xserver-xorg-core

Die Neuinstallation lässt sich mit folgendem Befehl erreichen:

Mit apt-get:

sudo apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri xserver-xorg-video-radeon xserver-xorg-core 

Mit aptitude:

sudo aptitude reinstall libgl1-mesa-glx libgl1-mesa-dri xserver-xorg-video-radeon xserver-xorg-core 

Analyse der XServer-Log-Datei

Wer beim Durchsehen der /var/log/Xorg.0.log auf Folgendes stößt, sollte sich nicht wundern: (II) RADEON(0): num pipes is 4. Hier läuft der Treiber unter einer Radeon x850xt, die eigentlich 16 Pipelines hat und man dementsprechend denken könnte, dass Einiges verschwendet würde. Da es aber keine Karte mit 2 oder 6 Pipelines gibt, hat man diese zu Blöcken a 4 Stück zusammen gefasst. Also ist die Ausgabe vollkommen in Ordnung.

Auch bei der Meldung (II) RADEON(0): Detected total video RAM=262144K, accessible=131072K (PCI BAR=131072K) ist alles in Ordnung. Die erste Zahl gibt an, wieviel Grafikspeicher erkannt wurde und die anderen beiden, wie groß der Bereich ist, auf den die CPU auf einmal zugreifen kann. Dieser Bereich kann aber hin und her geschoben werden. Weil die CPU nicht viel mit den Berechnungen der Grafikkarte zu tun haben sollte, sind die letzten beiden Werte zu vernachlässigen, denn die Grafikkarte kann auf ihr gesamtes RAM zugreifen.

Deaktivieren von Kernel Mode-Setting

Für ATI Grafikkarten wird Kernel Mode-Setting (KMS) verwendet. In wenigen Fällen kann es hiermit Probleme geben, die es erfordern zum alten User-Space Mode-Setting (UMS) zu wechseln. Um dies zu tun fügt man entweder die Bootoption nomodeset hinzu oder man benutzt die unter Konfiguration beschriebene modeset=0 Option. Mit dem Wechsel zu UMS werden viele Optionen für das Kernel Modul nutzlos und auch die verfügbaren Optionen des Xorg Treibers ändern sich stark, zur Konfiguration sollte die radeon-Manpage konsultiert werden.

Als Nebeneffekt fällt der grafische Bootsplash Plymouth in den Textmodus zurück und die virtuellen Konsolen haben wieder die kleinere Standardauflösung wie in vorhergehenden Ubuntu Versionen. Hier {de} gibt es eine Anleitung, wie diese Nebeneffekte behoben werden können.

Achtung!

Die Unterstützung für UMS nimmt zunehmend ab und liegt ab Southern Islands überhaupt nicht mehr vor. Das Deaktivieren von KMS kann zu fehlender Hardware-Beschleunigung und einem allgemein mit UMS nicht mehr funktionierenden radeon Treiber führen und sollte daher nur in absoluten Ausnahmefällen als dauerhafte Lösung akzeptiert werden.

Bild größer als der Bildschirm

Auch moderne Fernseher benutzen immer noch Overscan zur Darstellung von Video-Signalen, d.h. das Bild wird hochskaliert, damit die Ränder nicht zu sehen sind. Da ein Bildschirm über HDMI nicht erkennen kann, ob ein Multimedia-Gerät oder ein Computer angeschlossen ist, wird oft auch bei einem angeschlossenen Computer Overscan verwendet, was dann aber unnötig ist. Die meisten Geräte besitzen eine Option um Overscan abzuschalten, damit das Bild passend dargestellt wird.

Kein Ton über HDMI

Die Unterstützung der Audiowiedergabe über HDMI hängt immer etwas hinterher, da die Entwickler anderen Dingen eine höhere Priorität zuweisen. Somit kann eine ganze Weile vergehen, bis die Unterstützung für aktuellere Grafikkarten als stabil genug angesehen wird um standardmäßig aktiviert zu werden. Liegt die Unterstützung bereits vor und wird lediglich noch nicht als stabil genug angesehen, so kann man wie unter Konfiguration beschrieben mit der Option audio=1 diese trotzdem aktivieren.

Diese Revision wurde am 24. April 2014 07:58 von frustschieber erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: radeon, Hardware, treiber, ati, Grafikkarten, amd