Wie einige vielleicht wissen, haben wir in KDE Plasma Workspaces 4.5 leichte Probleme mit den freien Grafikkartentreiber. Die einzige Möglichkeit so etwas für die Zukunft zu verhindern, ist dass wir mehr testen und größere Änderungen am Rendering Stack nur zu Beginn des Release Zyklus implementieren, so dass diese etwa 6 bis 7 Monate getestet werden können. Ich selbst nutzte nun KWin von trunk und nicht mehr von branch um mögliche Probleme möglichst schnell zu bemerken. Dies kann man aber nur wenn man auch die freien Treiber benutzt. Und hier wird es problematisch:
Bis vor Kurzem war mein Hauptsystem ein Notebook mit einer NVIDIA 9600M. Eine andere Grafikkarte einzubauen ist durch die Tatsache "Notebook" schon mal nicht möglich. Man hat also die Wahl zwischen dem proprietären Treiber und Nouveau. Als Distribution setze ich Debian Testing aka Squeeze ein. Die Version von Nouveau in testing unterstützt nur 2D was den Ansprüchen eines Entwicklers am OpenGL Compositing Bereich nicht genügt. Da Squueze bereits Feature Frozen ist, wird sich da auf absehbare Zeit nichts ändern. Jedoch existiert auch eine neuere Version in experimental, welche auch die neuste Kernel Version aus experimental benötigt. Damit bekomme ich OpenGL zum Laufen, sogar GLSL funktioniert recht gut, jedoch ist der Treiber für den Einsatz auf einem Notebook noch ungeeignet, da die Stromsparmechanismen noch nicht vollständig implementiert sind. Die Akkulaufzeit ist deutlich schlechter und Suspend to RAM ist bei mir gescheitert. Somit leider wieder zurück zum NVIDIA Treiber.
Seit ein paar Wochen habe ich ein neues System mit einer ATI R710 Grafikkarte, die ich vor etwa zwei Jahren gekauft hatte um neben NVIDIA auch mit Mesa und fglrx testen zu können. Leider hat sich seit damals die Situation nicht wirklich verbessert – zumindest unter Debian Testing. Mit dem freien radeon Treiber erreiche ich maximal einen Kernel oops beim Starten vom X Server – ein wirklich schönes Bild man startet zum ersten Mal und sieht nur einen schwarzen Bildschirm und kann auch nicht auf ein Terminal wechseln. Mit den Treibern und Kernel aus X sieht es etwas besser aus: X startet zwar immer noch nicht aber es gibt zumindest keinen oops, aber in dmesg findet man einen Crash Trace. Nun ist Testing natürlich mit Mesa 7.7 etwas alt (meine Vermutung warum ich die Probleme in 4.5 mit dem Intel System das mir zum Testen zur Verfügung steht nicht reproduzieren kann, ist dass Testing zu alt ist) und man könnte Mesa von Hand bauen. Wenn man KDE baut, sollte man das wohl auch schaffen. Hmm Wiki etwas veraltet: "Under some newer distributions, like Ubuntu 7.04". Mit längerem Suchen findet man dann doch eine Anleitung die recht aktuell aussieht, jedoch möchte ich einfach nicht Dateien unter /usr austauschen und X zu erklären, wo es mesa findet will irgendwie nicht – zumindest ändert sich am Ergebnis nichts: kein X Server.
Nun gibt es ja nicht nur einen, sondern zwei freie Treiber: radeonhd. Diesen könnte man auch mal ausprobieren, also installiert, xorg.conf angepasst und kdm neugestartet und wieder nichts. Also Rechner komplett neustarten und siehe da, es gibt Verbesserungen: X startet zwar nicht, aber man fällt zumindest auf ein Terminal zurück. Mit Hilfe einer größeren Suchmaschine war das Problem schnell gefunden: radeonhd funktioniert nicht mit Kernel Mode Setting (KMS). Nur wie deaktivieren? Die Suchmaschine sagt was von "nomodeset" in grub übergeben, jedoch sieht man beim Hochfahren sehr schön, dass KMS aktiviert wird. Tja unter Debian wird KMS dynamisch aktiviert, wenn der radeon Treiber geladen wird. Man muss also die Datei /etc/modprobe.d/radeon-kms.conf anpassen (völlig offensichtlich, oder?), danach startet auch X und siehe da, es wurde Farbe. Nur mein primärer Bildschirm hatte leicht verzehrte Farben. Login und sogar Desktopeffekte sind aktiv und nach Spielen mit XRandR sind die Bildschirme korrekt eingerichtet, nur wird der falsche Bildschirm als primär angesehen – aber OK. Leider ist die OpenGL Version nur 1.5 und da KMS ja nicht unterstützt ist, funktionieren Funktionen wie Shader (ARB und GLSL) und Framebuffer Objects leider nicht. Keine guten Voraussetzungen für die KWin Entwicklung mit diesem Treiber. Damit hätte ich noch arbeiten können, jedoch gab es leichte Probleme nach dem Suspend Test: der größere der beiden Bildschirme wollte einfach nicht mehr. Egal was ich in XRandR eingestellt hatte, ließ er sich nicht dazu überreden etwas anzuzeigen. Dieser Fehler hat sogar erfolgreich einen Neustart von X überlebt.
Tja da steh ich nun ich armer Tor und bin so klug als wie zuvor. Auf beiden Systemen läuft wieder der proprietäre BLOB. In der Gesmatheit meiner Feature Anforderungen sind die proprietären Treiber für mich weiterhin die einzige Wahl, kurz zusammengefasst gibt es folgende Showstopper:
- Nouveau überlebt Suspend auf Notebok nicht
- Radeon endet in Kernel oops
- Radeonhd mag meinen Full-HD Bildschirm nicht
Nun gäbe es noch eine Möglichkeit das ganze Problem auf die Distribution zu schieben: laut der Meinung einiger Leute im Phoronix Forum sei das ja der Hauptgrund für die Probleme in 4.5, da ich die falsche Distribution nutze. Jedoch habe ich in regelmäßigen Abständen die Ati Karte mit verschiedenen Distributionen ohne Erfolg getestet. Zuletzt auch Kubuntu Maverick Beta, diese sollte ja das neueste mitbringen, was es so aktuell gibt. Und ja, X startet, jedoch startet X sich auch neu, wenn man Desktop Effekte aktiviert. Also kann ich auch bei einer Distribution bleiben, welche ich kenne und schätze. Rolling Release ist für mich undenkbar, da Treiber Probleme implizieren, dass ich nicht mehr an KWin entwickeln kann. Ein gewisses Grad an Stabilität benötige ich halt doch
=-=-=-=-=
Powered by Blogilo
Hm… seltsame Probleme hast du… 😉
Nun, ich habe zwar in meinem Notebook (Dell Studio XPS 1640) eine ATI HD 3670, aber keine Probleme mit radeon/mesa. KMS funktioniert übrigens auch! Ach ja, ich nutze Ubuntu 10.04 64 bit.
Mit dem Stromsparen hast du Recht; die freien Treiber scheinen derzeit ein bisschen mehr zu konsumieren als fglrx. Umgekehrt zeigte fglrx bis Catalyst-Version 10.4 (das war meine letzte) ca. 10 nervige Bugs (bis hin zu Abstürzen z.B. bei Userneuanmeldung auf neuem Terminal), die die freien Treiber nicht haben.
Ich habe nur einen Bildschirm, aber der ist 1920×1080 und wird perfekt unterstützt.
Suspend funktioniert nicht, aber das liegt am Motherboard bzw. BIOS, das leider ebenfalls ziemlich verbuggt ist. (Nicht umsonst gibt Dell fast jedes Monat ein Update heraus. Einige der Updates umgehen HW-Fehler des Motherboards. Ich glaube, meine Notebook ist trotz seiner erst 2 Jahre Existenz das mit der höchsten aktuellen BIOS-Version bei Dell.)
die HD 3670 ist eine R600 Grafikkarte, also eine Kategroie älter und besser unterstützt.
Nehm Archlinux. Stabil wenn man immer mal wieder ein Auge auf die Webseite wirft, aktuell und auch viele Dev-Pakete gibt es im Arch User Repository (AUR).
Ist doch schade, dass du von deiner Distribution ausgebremst wird. Seit einiger Zeit keine Probleme mit radeon+KMS.
ihr braucht mir keine Distris zu empfehlen – ich bin zufrieden mit der, die ich nutze. Von Arch hab ich schon genügend Negativgeschichten gehört als dass ich sie überhaupt in Betracht ziehen würde.
Hmm frage mich was für negatives du da gehört hast. Ich habe schon alle möglichen Distributionen ausprobiert. Dabei ist Arch bis jetzt mit Abstand die Beste! Gerade wenn man gerne sehr aktuelle Software haben möchte… Ist aber nur meine Persönliche Erfahrung. Es soll doch jeder das Benutzen, was am besten passt 😉
genau das ist das Problem: ich möchte nicht alles in Neu: KDE und die Abhängigkeiten reichen, für den Rest hätte ich gerne ein stabiles System. Ich möchte mich mit der Wartung des Systems möglichst wenig beschäftigen und das kann man bei einem rolling Release halt nicht.
Selber schuld. Bei Arch gibts zum Beispiel mesa-git im AUR, xorg 1.9 in testing, usw. Alles was eine Entwicklerherz höher schlägen lässt.
Du beschwerst dich über alte Softwareversionen in deiner Distri, willst aber auch keine mit neueren. Übers selber kompilieren regst du dich dann auch noch auf. Ja was denn dann?!
Meinte natürlich: willst keine Distro mit neueren Softwareversionen
Mit den freien ATI-Treibern hatte ich auch so meine Probleme. Vielleicht werden die ja irgendwann besser, momentan funktioniert alles mit dem proprietären Nvidia-Treiber ausgezeichnet. Wie sieht es eigentlich mit fglrx aus? Als ich das das letzte mal ausprobiert habe, war das ziemlich verbuggt, funzt das mittlerweile?
Bei mir funktioniert der fglrx relativ zufriedenstellend. Mit direct rendering ist er jedoch nicht zu gebrauchen, im Gegensatz zu den NVIDIA Treibern.
Hallo,
seltsamer Weise funhktioniert Ubuntu 10.10 mit effekte und KMS einwandfrei im Gegensatz zu Kubuntu und Kwin. Man sollte nur soweit gehen wie die Treiber es auch zulassen es nützt niemanden etwas mit viele Möglichkeiten wenn es nicht sauber läuft.
Gruß
Die Glaskugel wurde aber auch noch nicht erfunden. Als wir vor Monaten die Funktionen implementierten und sie auf aller Hardware die wir hatten, getestet hatten, konnten wir nicht ahnen, dass sie in der nächsten Treiber/X/Kernel/KDE Kombination zu Problemen führt.
Im Übrigen hat sich die Anforderung an die Hardware seit KDE 4.0 nicht verändert. Nur jetzt fangen halt die Treiber an zu meinen zu unterstützen, was wir seit 4.0 nutzen (und nicht nutzen wenn der Treiber es nicht kann). Der Fall “ich kann es vielleicht aber nur wenn die Sonne aus dem Winkel scheint” haben wir leider nicht vorhergesehen.
Wer Sarkasmus findet, darf ihn behalten.
Hallo,
sag ich ja es sind Funktionen eingebaut die der Treiber noch nicht unterstüzt bzw nicht unterstützte da muß man zwangsweise damit rechnen das der Schuss mal nach hinten geht. Es interesiert keinen wer letzt endlich die schuld hat, wenn man überhaupt von Schuld reden kann, man sieht es stürtzt ab und sagt KDE ist sche… und das ist es was mich persönlich ärgert. Durch viele Supereffekte die KDE unumstritten hat und meiner Überzeugung nach auch besser als alle anderen sind aber nicht überall laufen, wobei mann NV, ATI und Intel als Hauptgrafk sehen sollte, wirft es ein schlechtes Licht auf KDE. Weil man eben keine Glaskugel hat kann man auch nur Funktionen einbauen die auch laufen und nicht für die Zukunft programmieren.
Das ganze spiegelt nur meine Meinung wieder, vor Deinen Leistungen zu KWin habe ich aber trotz allem meine Hochachtung! Gruß
Wir haben aber nicht fuer die Zukunft programmiert sondern gegen einen 6 Jahre alten Standard und es hat problemlos jahrelang funktioniert. Dass ploetzlich die Treiber anfangen zu behaupten, dass sie den Standard implementieren (jedoch fehlerhaft) war nicht vorhersehbar. Dazu hab ich auch ausfuehrlich gebloggt und die Situation erklaert. Bitte lese dir diese blogposts durch