Opensuse Leap 42.1 – Nvidia – KDE 5 – unregelmäßiger Crash des Windowmanagers

Der KDE Plasma-Desktop von Opensuse Leap 42.1 macht mir immer wieder erhebliche Schwierigkeiten. Leider auch bzgl. elementarer Dinge wie etwa der Bedienbarkeit der Fenster. Ich habe zwar den neuesten proprietären Treiber von Nvidia installiert; der hilft aber ebensowenig wie ältere Treiber oder ein Wechsel von OpenGL 2.0 zu OpenGL 3.1:

Bei Drag- und Drop-Aktionen mit komplexeren Applikationen wie etwa “kontact” oder Eclipse auf dem Desktop zerreißt es manchmal den Windowmanager. Danach haben sämtliche Fenster keine Bedienleiste mehr.

Ähnliches passiert auch bei Änderungen der Fensterdekoration über die KDE-“Systemeinstellungen”.

Es ist nun nicht notwendig, sich nach einem solchen desaströsen Vorfall ab- und wieder anzumelden. (Leider funktioniert nämlich auch das Abmelden nicht verlässlich … ). Solange man noch ein Terminalfenster öffnen kann, kann man den Windowmanager erneut starten.

Man muss dazu jedoch wissen, das sich das Kommando geändert hat. Statt “kwin &” ist das jetzt zu verwendende Kommando:

ich@mytux:~> kwin_x11 &

Ich hoffe, dieser Tipp hilft dem einen oder anderen.

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.