Grafikkarten/AMD/radeon

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

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

  1. Installation von Programmen

  2. Einen Editor öffnen

  3. Ein Terminal öffnen

  4. Root-Rechte

Inhaltsverzeichnis
  1. Installation
    1. Aktivierung des Treibers
  2. Konfiguration
    1. Xorg-Treiber Optionen
    2. Kernelmodul Optionen
    3. Stromsparfunktionen
      1. Dynamic Clocks
      2. Dynamic Power Management
    4. Hardware-beschleunigte Videodekodierung
  3. Probleme
    1. Deaktivieren von Kernel Mode-Setting
    2. Bild größer als der Bildschirm
    3. Kein Ton über HDMI
  4. Links

Achtung!

Alle in diesem Artikel genannten Pakete sind Bestandteil der LTS Enablement Stacks, wodurch sie mehrfach in den Paketquellen vorliegen. Wird eine Ubuntu Version mit Langzeitunterstützung verwendet, die einen dieser „Stacks“ verwendet, so muss jedes der auf dieser Seite genannten Pakete um das dem „Stack“ zugeordnete Suffix ergänzt werden. Die Installation des falschen Pakets kann im Problemfall zu einem nicht mehr startenden System führen!

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:

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
R5xx Radeon X1300 – X1950
R6xx Radeon HD 2xxx Serie, Radeon HD 3xxx Serie OpenGL 2.1
OpenGL 3.0 (ab 12.10)
OpenGL 3.3 (ab 14.04)
OpenGL 4.1 (ab 16.04) ¹
R7xx Radeon HD 4xxx Serie
Evergreen Radeon HD 5xxx Serie, Radeon R5 220
Northern Islands Radeon HD 6xxx Serie, Radeon HD 7450 – 7670, Radeon HD 8350 – 8400, Radeon R5 220 – 235
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 – 280,
Radeon R7 340 – 350, Radeon R7/R9 370
OpenGL 3.3 (ab 14.04)
OpenGL 4.1 (ab 16.04)
Sea Islands Radeon HD 7790, Radeon R7 260, Radeon R9 290, Radeon R7/R9 360, Radeon R9 390
Volcanic Islands Radeon R9 285, Radeon R9 380, Radeon R9 Fury OpenGL 4.1 (ab 16.04) ²

  1. R6xx und R7xx unterstützen nur OpenGL 3.3. Evergreen und Northern Islands unterstützen OpenGL 4.1 lediglich mit wenigen High-End Chips vollständig, der restlichen Hardware fehlen ein paar Instruktionen, die nur im professionellen Bereich verwendet werden. Da die fehlenden Instruktionen bisher noch nicht emuliert werden können, listet der Treiber bei den betroffenen Karten weiterhin nur eine OpenGL 3.3 Unterstützung auf.

  2. Für Volcanic Islands wird zwar der gleiche Mesa Treiber wie für Southern Islands und Sea Islands benutzt, jedoch kommt der radeon Treiber nicht zum Einsatz. Stattdessen wird das Kernelmodu amdgpu mit dem gleichnamigen X Treiber verwendet, sodass dieser Artikel nur sehr eingeschränkten Nutzen hat.

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 🇬🇧 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:

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 

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 Kernelmodul 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 Kernelmoduls 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" "EXA"/"glamor" Bestimmt die zu verwendende Architektur für die unabhängige 2D Hardware-Beschleunigung des XServers. Die neue Glamor Architektur greift direkt auf die vorliegende OpenGL Implementation zurück und wird ab R300 unterstützt. Ab Southern Islands wird nur noch Glamor unterstützt, ältere Chips werden standardmäßig mit EXA betrieben.
Option "DRI" "2"/"3" Bestimmt die größte zu verwendende Version der Direct Rendering Infrastructure, ab 15.10 nutzbar. Standardmäßig wird DRI2 verwendet, ab 17.04 wird DRI3 automatisch verwendet wenn Glamor benutzt wird. Das neu eingeführte DRI3 verspricht eine bessere Sicherheit, mehr Leistung und weniger Probleme mit der Synchronisierung von Fensterinhalten, es kann allerdings in einigen Fällen noch zu Instabilitäten kommen. Der Betrieb von DRI3 in Kombination mit EXA wird nicht empfohlen und erfolgt auf eigene Gefahr!

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.

Kernelmodul Optionen

Die Optionen für das Kernelmodul 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 Verzeichnis /etc/modprobe.d 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 Kernelmodule 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 Kernelmoduls anzuschauen.

Folgende Optionen sind mitunter für das Kernelmodul 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/1/0 Aktiviert die neue Stromspar-Architektur für Radeon HD Karten (Standard ist -1 für auto)
audio -1/1/0 Aktiviert die Audioausgabe über HDMI (Standard ist -1 für auto)

Stromsparfunktionen

Mit dem Wechsel zu Kernel Mode-Setting (KMS) sind auch die Stromsparfunktionen nun ein Teil des Kernelmoduls 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.

Die neue „Dynamic Power Management“ (DPM) Stromspar-Architektur wurde von AMD enwickelt, 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 über „Dynamic Clocks“ zwei Methoden zum Stromsparen (power_method):

  • 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 - Diese Option steht für das im folgenden Abschnitt beschriebene „Dynamic Power Management“. Wenn DPM keine Verwendung findet, ist profile die Standardeinstellung. Um DPM explizit zu aktivieren oder deaktivieren muss der dazugehörige Kernel Parameter verwendet werden, im laufenden Betrieb kann nicht zwischen DPM und „Dynamic Clocks“ gewechselt werden.

Es stehen dabei folgende Profile zur Auswahl (power_profile):

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

Hinweis:

Ab Kernel 3.13 wird DPM automatisch für die Chipsätze ab R7XX (Radeon HD 4XXX) verwendet. Die älteren Chipsätze der Serien R6XX (Radeon HD 2XXX/3XXX) werden ebenfalls unterstützt, aber DPM muss dafür manuell aktiviert werden. Entweder über die Bootoption radeon.dpm=1 oder wie oben im Abschnitt Kernelmodul Optionen beschrieben.

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 rc.local 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 deren UVD Einheiten als problematisch erwiesen haben.

Ab Vivid Vervet wird auch die erste UVD Generation der HD 2000 und HD 3000 Serie unterstützt. Weiterhin haben die Entwickler die Probleme mit den zuvor genannten Karten der HD 4000 Serie in den Griff bekommen, sodass nun die UVD Einheiten aller Radeon HD Karten unterstützt werden.

Alle Karten ab der Radeon 9500 sind darüber hinaus auch ohne die UVD Einheit in der Lage, über einen generischen VDPAU 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 Verwendung von VDPAU nicht vorinstalliert, weshalb die Installation des folgenden Pakets notwendig ist.

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install mesa-vdpau-drivers 

sudo aptitude install mesa-vdpau-drivers 

Seit Xenial Xerus bietet der Treiber für Karten ab der R600 Chipfamilie die Hardwarebeschleunigung ebenfalls über VA-API an, sodass für Programme die ausschließlich VA-API unterstützen kein VDPAU Backend mehr verwendet werden muss. Die hierfür benötigten Dateien können mit dem folgenden Paket installiert werden.

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install mesa-va-drivers 

sudo aptitude install mesa-va-drivers 

Wenn man sich zwischen beiden Schnittstellen entscheiden kann sollte man VDPAU den Vorzug geben, da es noch einmal etwas weniger CPU Last verursacht als VA-API.

Probleme

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 Kernelmodul nutzlos und auch die verfügbaren Optionen des Xorg-Treibers ändern sich stark, zur Konfiguration sollte die Manpage zu radeon 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 🇩🇪 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“ (siehe Einleitung) ü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 auch bei einem angeschlossenem Computer Overscan angewendet, sodass die Ränder des dargestellten Bildes verloren gehen. Die meisten Fernseher bieten eine Möglichkeit, Overscan für den verwendeten HDMI Anschluss zu deaktivieren, welche jedoch bei einigen Geräten gut versteckt, schlecht benannt oder nicht im Handbuch dokumentiert sein kann.

Sollte der Fernseher zu den wenigen Geräten gehören, die keinerlei Möglichkeiten zum Abschalten von Overscan bieten, so kann man den Treiber anweisen das Bild zu verkleinern, damit es passend dargestellt wird. Da durch das Hoch- und Runterskalieren des Bildes die Bildqualität sinkt, sollte dies jedoch nur als letztes Mittel angesehen werden. Um diese „Underscan“ genannte Kompensationsfunktion zu aktivieren, müssen mithilfe von xrandr die entsprechenden Attribute des betroffenen Anschlusses angepasst werden. Das Ausführen von xrandr --prop listet oberhalb der unterstützten Bildschirmmodi zusätzlich die für jeden Anschluss verfügbaren Attribute inklusive der möglichen Werte auf. So lässt sich beispielsweise mit folgendem Befehl Underscan am HDMI-0 Anschluss aktivieren:

xrandr --output HDMI-0 --set underscan on 

Sollte das Bild immer noch nicht richtig passend erscheinen, so lässt sich mit den underscan hborder bzw. vborder Attributen der eingefügte horizontale und vertikale Rand genauer festlegen.

Wie alle direkt über xrandr vorgenommenen Änderungen wird der so erzielte Effekt nicht gespeichert. Daher ist es nötig, die ausgeführten xrandr Befehle bei jedem Start ausführen zu lassen. Die Befehle müssen aus einer grafischen Oberfläche heraus ausgeführt werden, daher sollten die in Autostart beschriebenen Möglichkeiten genutzt werden.

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 Kernelmodul Optionen beschrieben mit der Option radeon.audio=1 diese trotzdem aktivieren.