Leap 42.2 KDE - Artefakte bei Fenster-Drag&Drop & Maus-Flackern

Hinweis: In dem Thema Leap 42.2 KDE - Artefakte bei Fenster-Drag&Drop & Maus-Flackern gibt es 6 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Hallo openSUSE-Forum!


    Ich habe ein kleines Problem mit meiner openSUSE Installation. Ich habe Leap 42.2 mit KDE installiert und es funktioniert soweit alles bis auf die Windows-Tasten meiner Tastatur (was ich aber nicht hier besprechen will) und ein Problem mit KDE/KWin. Erste Anmerkung: Ich habe eine englische Installation und kenne die deutschen Begriffe nicht:


    Zunächst ein bisschen mehr zu meinem System/meiner Hardware:
    Ich nutze sowohl die Onboardgrafik meines Intel i7-4770K - also Intel HD Graphics 4600 - als auch die eingebaute Grafikkarte, eine Radeon HD5670 (Redwood und so...). An beiden ist jeweils ein Monitor angschlossen. Ich werde diese Monitore zum Verständnis ab jetzt "Intel-Screen" und "Radeon-Screen" nennen. (Der Grund für die Verwendung von beiden ist ein dual-bootendes Windows, bei dem diese Konfiguration für mich sinnvoll ist, ich möchte allerings für Linux nicht jedes mal einen Monitor an die andere Grafikeinheit stecken.)


    Unter "System Settings > Display and Monitor > Compositor" kann man ein Rendering Backend wählen. In meinem Fall stehen da OpenGL 3.1, OpenGL 2.0 und XRender zur Verfügung.


    1. Egal welchen Compositor ich wähle: Wenn ich Fenster auf dem Intel-Screen mit Drag&Drop umherziehe hinterlassen sie Artefakte. Allerdings ist es mit den OpenGL Backends nicht so stark wie mit dem XRender Backend.
    2. Mit den OpenGL Backends fängt die Maus auf dem Radeon-Screen an zu flackern. Hauptsächlich wenn ich sie über anklickbaren Flächen bewege. Mit dem XRender Backend flackert die Maus gar nicht.


    Ich würde gerne beide Probleme beheben, aber von mir aus gerne eins nach dem anderen: Wer mir helfen kann oder es versuchen möchte bestimmt, welches wir zuerst angehen.
    Falls gewünscht kann man das ganze auch auf 2 Threads aufteilen.


    Ich versuche schonmal ein wenig Information mitzugeben, die nützlich sein könnten:


    Der (wahrscheinlich) interessante Teil von lspci:

    Code
    [...]
    00:02.0 Display controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
    [...]
    01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood XT [Radeon HD 5670/5690/5730]
    01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Redwood HDMI Audio [Radeon HD 5000 Series]
    [...]



    Der (wahrscheinlich) interessante Teil von lsmod:


    Nun zu dem, was ich bereits versucht habe:


    Hier (https://community.kde.org/Plas…Heavy_rendering_artifacts) unter "Heavy rendering artifacts" nachzulesen kam ich auf die Idee DRI3 zu verwenden. Ich habe dann einem Forumsbeitrag (https://bbs.archlinux.org/viewtopic.php?id=208733) folgend in /etc/X11/xorg.conf.d/ ein File 20-intel.conf mit folgendem Inhalt angelegt:


    Code
    Section "Device"
       Identifier  "Intel Graphics"
       Driver      "intel"
       Option      "TearFree" "true"
       Option      "DRI" "3"
    EndSection

    Ich habe den Driver auch testhalber mit i915 ersetzt. In beiden Fällen ließ sich der XServer nicht mehr starten. Danach habe ich das File wieder gelöscht um wieder in den grafischen Modus starten zu können. (Möglicherweise wissenswert: ich habe in der xorg.conf.d schon erfolgreich eine 910-rat.conf für meine Mad Catz M.M.O.7 Mouse eingerichtet. Es sollte aber keinen Einfluss auf den Rest haben)



    Was mit dem OpenGL ES Backend (Genannt als zweite Lösung bei den heavy rendering artifacts, 1. Link s.o.) auf sich hat und wie ich das aktiviere konnte ich nicht herausfinden. Google führte mich zu KWin Environment Variablen (https://community.kde.org/KWin…nt_Variables#KWIN_COMPOSE) - Ich habe allerdings keine Ahnung, wie ich diese sinnvoll bearbeiten kann. Schon gar nicht ohne irgendetwas dauerhaft kaputt zu machen.


    Zum Flackern der Maus bin ich bisher noch nicht gekommen, mir fehlt dort auch jeglicher Anhaltspunkt.


    Noch als Anmerkung:
    Ich sehe mich weder als Linux-Anfänger (ich bin - meinem Vater sei Dank - damit aufgewachsen), noch als eine Art Linux-Fortgeschrittener: Meistens funktioniert bei mir alles wie es soll, daher fehlen mir immer wieder mal Problemlöse-Skills, so wie jetzt. Ich habe kein Problem damit in der Konsole zu arbeiten und kann euch gerne noch mehr Informationen liefern, wenn ihr mir sagt was ihr braucht. Ich hoffe ihr könnt mir helfen.


    lg.
    Antarctris

    Für den Inhalt des Beitrages 106073 haftet ausdrücklich der jeweilige Autor: Antarctris

  • Versuch es doch mal mit kernel-default aus dem kernel:stable Repo.


    Repo hinzufügen:

    Code
    zypper ar -f /download.opensuse.org/repositories/Kernel:/stable/standard/ kernel


    Kernel installieren aus diesem Repo:



    Code
    zypper dup --from kernel

    Wenn es nicht funktioniert, Repo löschen:


    Code
    zypper rr kernel



    Und den alten Kernel wiederherstellen.

    Code
    zypper in -f kernel-default

    Ich schau dann aber immer in Yast---Bootloader nach, ob auch der richtige Kernel installiert ist.
    Yast funktioniert auch im RL3 (Textmodus).

    Für den Inhalt des Beitrages 106084 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Hey,


    danke für die schnelle Antwort! Ich werde mal einen vollständigeren Bericht der Ereignisse geben - Ich bin mir nicht sicher, was davon wirklich relevant ist.
    Also: Ich habe das ganze gestern ausprobiert und mit deinen Befehlen den Kernel 4.10.1-5.gf764d42-default installiert. Daraufhin wollte mein Rechner nicht mehr booten: Irgendeine Kernel-ID wäre wohl nicht in Ordnung, weswegen Grub sich geweigert hat den Kernel zu starten. Ziemlich offensichtlich war daran secureboot Schuld. Das stand witzigerweise noch auf Windows.. Ich hab es auf OtherOS gestellt und er ist wieder gestartet.


    Während dem Systemstart wurde eine Liste von Errors angezeigt, Irgendwelche Namespace Lookup Failures, mit dem alten Kernel bekam ich diese Anzeige nicht. Und ebenso schnell wie sie aufgetaucht war und gebraucht hat um mir leichte Sorgen zu machen war sie auch schon wieder weg. Das System ist trotzdem vollständig gestartet. Ich hatte allerdings den Eindruck, dass es ein paar Sekunden länger braucht um den XServer zu starten (Das ist aber im Zeitalter von SSDs nicht wirklich relevant, ich kenne noch die Zeiten da das Hochfahren 2-7 Minuten gedauert hat, da komm ich mit < 1 Min in allen Fällen klar).


    Nun zurück zu den eigentlichen Problem:
    Auf dem Intel-Screen gibt es keine Artefakte mehr. Egal welchen Compositor ich verwende: Die Artefakte sind weg. Hierfür schonmal tausend Dank!


    Dazu allerdings noch eine Frage: War Leap 42.2 nicht eigentlich dafür ausgelegt mit dem 4.4er Kernel zu laufen - hat es irgendwelche Auswirkungen, wenn ich bei dem 4.10er kernel bleibe?


    Zum zweiten Teil es Problems: Das Maus-Flackern auf dem Radeon-Screen ist geblieben wie es war. Also bei OpenGL Backend flackert es, bei XRender nicht. Ich fände es gut, wenn man dieses Flackern bei den OpenGL Backends auch noch beseitigen könnte.


    lg.
    antarctris

    Für den Inhalt des Beitrages 106125 haftet ausdrücklich der jeweilige Autor: Antarctris

  • Da ich meine eigenen Posts nicht bearbeiten kann schreibe ich den Nachtrag hier:


    1.
    Durch askubuntu (http://askubuntu.com/questions…ckering-in-kde-plasma-5-4) habe ich ausprobiert, ob es mit dem KWIN_TRIPLE_BUFFER funktioniert. Leider nicht - Die Maus flackert dann sogar noch mehr. Ebenso wenig hat eine Umstellung der Tearing Prevention (System Settings > Display and Monitor > Compositor) etwas bewirkt.


    2.
    Die Errormeldung beim Systemstart ist ein "ACPI Error [DSSP] Namespace Lookup Failure AE_NOT_FOUND". Ich habe keine Ahnung, was das genau bedeutet oder für Auswirkungen hat. Ich konnte bisher zumindest keine feststellen. Solange das so bleibt sehe ich auch keinen Sinn darin sich darum kümmern.



    lg.
    Tris

    Für den Inhalt des Beitrages 106126 haftet ausdrücklich der jeweilige Autor: Antarctris

  • Dazu allerdings noch eine Frage: War Leap 42.2 nicht eigentlich dafür ausgelegt mit dem 4.4er Kernel zu laufen - hat es irgendwelche Auswirkungen, wenn ich bei dem 4.10er kernel bleibe?

    Es hat "im allgemeinen" keine negativen Auswirkungen. Neuere Hardware wird besser erkannt.


    Die Errormeldung beim Systemstart ist ein "ACPI Error [DSSP] Namespace Lookup Failure AE_NOT_FOUND".

    Da wird irgendwo irgendetwas von der Hardware nicht richtig erkannt. Wenn alles andere funktioniert, würde ich das "ignorieren".
    Ich denke, daß sicher einige von uns genau wissen was es bedeutet.


    Ich hab es auf OtherOS gestellt und er ist wieder gestartet.

    Damit hast Du Grub aktualisiert. Mit uname -a in der Konsole oder im Kinfocenter in Plasma siehst Du welchen Kernel Dein System nutzt.


    Das Maus-Flackern auf dem Radeon-Screen ist geblieben wie es war.

    Dazu kann ich nichts sagen. Ich nutze hier Leap 42.2 mit Kernel 4.10 (wegen der Hardware) und mit Kde4! (ein ewig Gestriger).

    Für den Inhalt des Beitrages 106127 haftet ausdrücklich der jeweilige Autor: Kanonentux

  • Es ist schlicht kaum möglich irgendeinen Kernel ohne solche Warnungen und Fehler zu booten.


    Da weder im Kernel noch in der Hardware intelligente Japaner sitzen, die vernünftig denken und handeln,
    ist JEDES Betriebssystem beim Start auf die nicht sonderlich intelligente Try- and- Error Methode angewiesen.
    Es wird schlicht erst einmal angenommen irgendein Gerät wäre vorhanden. Dann wird versucht -zuerst möglichst "generisch", also nicht spezifisch für genau ein Gerät, sondern sehr allgemein für die Klasse dieser Geräte- auf diese vermutete Geräteklasse zuzugreifen.
    Führt das zu einem Fehler, werden einfach andere/weitere Geräte getestet.
    Soweit, so gut.


    Viele Fehler, die beim Booten gezeigt werden, sind also normal.
    Sogar die Allermeisten.


    Beim ACPI (AdvancedConfigurationAndPowerInterface) ist das ähnlich. Diese Schnittstelle sollte** die Konfiguration und die ganzen Poweroperationen (Suspend-to-disk, Suspend-to-ram, Supend-to-kneipe) vereinheitlichen. Zumindest so, dass der Zugriff von Betriebssystemebene aus auf die tatsächlich einzuschläfernde Geräte eben nicht jeweils einen spezifischen Treiber erfordert.


    Dazu bastelt der Boardhersteller, der i.d.R. wissen sollte, welche Geräte er drauflötet, halt im zugehörigen BIOS ein paar Datenstrukturen rein.
    dmidecode ist der Befehl um da ein wenig reinzugucken. (Abba wirklich nur ein wenig. Wenn die Hersteller nicht wollen, dann wollen sie nicht. Und sie wollen nicht.)


    Bei modernen Betriebssytemen werden diese Dinge beim Booten gelesen, mit dem BIOS ein wenig verhandelt und der ganze Käse dann schlicht im Weiteren völlig ignoriert.
    Der Kernel lernt beim Booten, wie er die Hardware zu bedienen hat, und lässt sich dann vom BIOS nicht mehr in die Suppe spucken.


    Der hier beschriebene "Fehler" geht in die Richtung Power-Management. Was auch immer nun tatsächlich dahinter stecken möge.
    Mit dem Aufkommen der SSDs tritt diese Meldung wieder öfter auf. Auch SSDs haben PowerModi, die es zu bedienen gilt.


    Jedenfalls gibt es prinzipiell zwei Lösungen für das Problem:

    • Beim Boardhersteller gucken, ob es ein BIOS- Update gibt, und wenn ja nach Installation Beten&Booten.
      (Funktioniert bei euch Ungläubigen eh nich.)
    • Den Splashscreen lauter und bunter schalten. Dann sieht man die Meldung nicht mehr.