Nvidia Treiber, KDE-Plasma-Desktop 4.14, Tearing-Effekt: Triple Buffering einschalten!

Meine Leser wissen, dass ich bzgl. des Linux-Desktops auf KDE setze. Den HW-technischen Unterbau liefern in meinen privaten Systemen, die ich meist selbst aufbaue, Nvidia-Grafikkarten. In der Regel verwende ich dafür den proprietären Treiber, dessen Modul ich über das Installationsskript von Nvidia kompilieren und installieren lasse. (Mit der unangenehmen Konsequenz eines “tainted” Kernel – aber das nur nebenbei).

Dieser Artikel betrifft ein Plasma-Problem, das ich auf Desktop-Systemen hatte. (Der Artikel bezieht sich nicht auf Laptop-Systeme mit Optimus-Technologie.) Seit geraumer Zeit (schätzungsweise seit KDE 4.12 bis heute unter KDE 4.14.9) plagte mich folgender, immer wiederkehrender Fehler:

Nach dem Starten des KDE Plasma Desktops mit aktivierten 3D-Effekten (OpenGL) – kam es bei der Bewegung von bestimmten Fenstern immer wieder zum sogenannten “Tearing”-Effekt. Besonders deutlich sichtbar wurde der für Fensterbegrenzungslinien von “konsole” oder Fenstern mit komplexeren GTK-Anwendungen. Dies erwies sich als unabhängig von der Voreinstellung der des OpenGL Composite Typs und des Qt-Grafiksystems (“native” oder “raster” Rendering)

Erstaunlicherweise verschwand dieser Effekt bei mir ebenso regelmäßig, wenn ich unter den KDE Systemeinstellungen auf dem Panel zu “Arbeitsflächen-Effekte” >> “Erweitert” eine der dortigen Einstellungen änderte und auf “Anwenden” drückte. Danach war für diese X-Sitzung Ruhe. Bei der Einstellungsänderung wurde offenbar etwas erkannt, was beim normalen KDE-Start nicht der Fall war). Aber solche manuellen Eingriffe bei jedem Start von KDE sind natürlich nervig.

Zufällig bin ich in anderem Zusammenhang vor ein paar Tagen über folgende Bug-Artikel gestolpert:
https://bugs.kde.org/show_bug.cgi?id=322060
https://bugs.kde.org/show_bug.cgi?id=330794
https://bugs.kde.org/show_bug.cgi?id=343184

Dadurch animiert habe ich nun mal “Triple Buffering” explizit in die “xorg.conf” eingetragen. Der Installer von Nvidia tut das nämlich nicht von sich aus. Er bewegte aber den einmal vorgenommenen händischen Eintrag bei der nächsten Treiber-Installation interessanterweise aus der “Device Section” in die “Screen Section”:

Auszug aus der /etc/X11/xorg.conf”:

Section "Screen"

    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-0"
    Option         "metamodes" "DVI-I-1: nvidia-auto-select +5120+0, HDMI-0: nvidia-auto-select +0+0, HDMI-1: nvidia-auto-select +2560+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    Option         "TripleBuffer" "true"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

 
Man erkennt hier, das ich Xinerama für 3 Schirme nutze. Der interessante Eintrag ist aber:

Option “TripleBuffer” “true”

Ich kann nur sagen:

Seitdem ist jegliches Tearing auf meinem 3-Schirme-Desktop verschwunden – ohne weitere Zusatzmaßnahmen und egal, was ich unter “Arbeitsflächen-Effekte” >> “Erweitert” für Einstellungen zum Punkt “Einzelbild-Zerreißen (Tearing) verhindern (Vsync)” einstelle. Auch ein spezieller Export der Umgebungsvariablen “__GL_YIELD” wie in einem der Bug-Reports beschrieben, erwies sich unter KDE 4.14 als überflüssig – diese Umgebungsvariable ist bei mir gar nicht gesetzt.

r
So einfach – man muss es halt nur wissen! Mein Dank an alle, die sich um diesen Bug in seinen verschiedenen Ausprägungen gekümmert haben! Ein schönes Beispiel dafür, dass der Open Source Prozess auch im Zusammenspiel mit Closed Source Komponenten funktioniert – auch wenn es manchmal etwas dauert.

Mouse / Keyboard frieren nach KDE-Login ein – ein .cache-Problem im Plasma-Desktop

In der letzten Woche hatte ich nach einigen Updates und Experimenten mit diversen Gnome Programmen (nautilus, tracker, …) unter KDE massive Probleme mit der Maus unmittelbar nach dem Einloggen in den KDE-Desktop (Opensuse 13.2; KDE 4.14.X mit KDE 5 Komponenten). Angemerkt sei, dass ich den aktuellen proprietären Nvidia-Treiber “352.41” benutze.

Die Maus ließ sich anfangs bewegen und man konnte auch genau einmal in ein Fenster – z.B. ein Terminal – klicken. Danach zeigten weder die Maus noch Navigationstasten des Keyboards eine Wirkung – und wenn doch, dann mit ganz erheblicher Zeitverzögerung.

Das Einzige was noch funktionierte war Ctrl-Alt-Del; man konnte danach zwar unter den erscheinenden Optionen nicht mehr per Tastaur/Maus wählen – aber nach 30 sek. wurde der automatische Logout durchgeführt. Nach einem erneuten Login gab es dann seltsamerweise keinerlei Probleme mehr mit der Maus oder Tastatur.

Interessant war auch, dass das Problem offenbar User-spezifisch war. Ein initialer Login nach dem Booten unter einer anderen UserID führte zu keinen Freezes.

Es war praktisch unmöglich zu beurteilen, ob das Problem an Plasma, anderen KDE-Komponenten oder eben den Gnome-Programmen lag. Die üblichen Log-Einträge (systemd journal, .xsession-errors) gaben nichts her.

Nach ein wenig Recherche im Internet fand ich folgende Artikel:
https://bugs.kde.org/show_bug.cgi?id=341963
https://forum.kde.org/viewtopic.php?f=289&t=124690

Ich hatte keineswegs dort angesprochene Probleme mit einer voll-laufenden Partition oder ähnlichem. Aber einer der dort besprochenen Lösungsansätze half:

Nach einem Löschen der Einträge/Subverzeichnisse im Verzeichnis “~/.cache” lief alles wieder wie es sollte. Das geschilderte Problem ist seither nicht wieder aufgetaucht.

Herzlichen Dank an all diejenigen, die im Rahmen der Bewältigung ihrer eigenen Probleme das Thema potentieller “.cache”-Probleme des KDE-Plasma-Desktops herausgefunden haben! Es ist wert, diesen Punkt als KDE-Nutzer im Kopf zu behalten.

Welches der Programme, das im “.cache”-Verzeichnis Einträge hinterlegt, Schuld war, konnte ich nicht mehr nachvollziehen, da ich die “.cache”-Subverzeichnisse leider und idiotischerweise pauschal gelöscht habe. Es wäre besser gewesen, es für spätere Analysen einfach umzubenennen ….. Als potentiell schuldige Programme kommen in meinem Fall in Frage :
chromium, fontconfig, gstreamer, ibus, mozilla, tracker, webkit, xine-lib.

Linux – Nvidia GTX 750 TI – Parallelbetrieb von 2 Dell U2515H mit 2560×1440 plus einem 1920×1200 Schirm

Erst vor kurzem hatte ich in einem Artikel über positive Erfahrungen mit einem Dell U2515H an einer GTX 750 TI Graka unter Linux und KDE berichtet. Dabei hatte ich belegt, dass es möglich ist, einen Dell U2515H in der nativen Auflösung von 2560×1440 über HDMI zusammen mit 2 Schirmen in der Auflösung 19210×1200 über DVI-Ausgänge parallel an einer Gigabyte GTX 750TI zu betreiben. Siehe:

Linux – Nvidia GTX 750 TI – Dell U2515H – HDMI – 2560×1440 Pixel

Inzwischen hat einer der 1920×1200 Schirme an besagtem System nach vorhergehender Alterschwäche den Geist aufgegeben und wurde durch einen weiteren Dell U2515H ersetzt. Nachzutragen ist, dass auch eine Konfiguration mt 2 Dell U2515H mit je 2560×1440 px an 2 HDMI-Anschlüssen und einem 1920×1200 LCD an einem der DVI-Anschlüsse der Graka einwandfrei funktioniert. Zumindest bei Verwendung eines aktuellen proprietären Nvidia Treibers.

kde_3_screens_3

Voraussetzung sind – wie im letzten Artikel ausgeführt – gute, aktuelle HDMI-Kabel mit 4K-Unterstützung (und hinreichender Länge – in meinem Fall 2m und 3m).

Nachtrag, 14.12.2015, KDE-Anpassungen,, ältere Grafikkarten:
Ein Leser hat mich angeschrieben und Sorgen bzgl. der Anpassung von KDE-Anwendungen an die hohe Auflösung sowie bzgl. der Performance älterer Grafikkarten geäußert. Ich habe die Fragen in folgendem Artikel beantwortet:
Linux – Dell U2515H – questions regarding KDE adjustments and older graphics cards

Nachtrag, 14.12.2015, Nvidia GTX 960
Ich konnte inzwischen auch die Konfiguration aus 2 Dell U2515H per Display Port und einem 1920×1200 Schirm per DVI an einer Nvidia GTX 960 testen. Funktioniert problemfrei!