Mark Shuttleworth hat in einem Blog Post geschrieben, dass Ubuntu eine der ersten Distributionen sein wird, die Wayland verwendet, was einiges an medialem Echo hervorgerufen hat. Persönlich hat mich der Blogpost überrascht, da auf dem Ubuntu Developer Summit für mich nicht ersichtlich wurde, dass Wayland schon zur Diskussion steht. Nur in einer Sitzung zu OpenGL ES in Composited Window Managers hatte ich Mark eine Frage zu Wayland stellen hören und war etwas verwundert. Für mich auch Anlass mal wieder in die Commit Historie zu schauen und ich habe erfreut festgestellt, dass die Entwicklung an Wayland aktiver geworden ist.

Nun was ist Wayland überhaupt? Wayland ist im Prinzip der Nachfolger des X-Servers, jedoch bedeutend schlanker. Wayland ist nur noch ein sehr dünner Display Manager mit eingebautem Compositor, der die Fenster zeichnet. Damit das ganze funktioniert braucht es viele der Technologien, die in den letzten Jahren Einzug erhalten haben, wie KMS und GEM. Genau hab ich mich auch noch nicht mit Wayland auseinandergesetzt, da es meiner Meinung nach, noch viel zu weit in der Zukunft ist. Jedoch sollte ich mich langsam aber sicher, damit beschäftigen, denn sonst steht KDE am Ende ohne Compositor dar (KWin als X WindowManager ist natürlich in einem X freien System nicht wirklich sinnvoll)

Warum sollte man X überhaupt ersetzen? X11 ist älter als ich, xlib ist nicht gerade die schönste API um mit zu arbeiten – nicht überraschend bei einem Alter von fast 30 Jahren. X11 ist entwickelt für die Ansprüche der Rechner aus den 80er Jahren. Xlib enthält also einiges was man heute nicht mehr braucht: Farbverwaltung, Zeichnung, etc. und so ziemlich alles was man heute mit OpenGL machen sollte. Heutige Anwendungen nutzen die primitiven Funktionen von X zum Zeichnen nicht mehr, so ziemlich jedes Toolkit hat dafür bessere Methoden. So bietet Qt an komplett auf der CPU zu zeichnen, statt native Aufrufe zu verwenden und ist dabei bedeutend performanter. Das ganze führte so weit, dass Bereiche von X über Jahre kaputt waren ohne dass es irgendjemand aufgefallen ist.

Die X Entwickler um Keith Packard kennen auch die Probleme und haben immer wieder neue Lösungen angebracht. So zum Beispiel XCB – ein etwas schönerer Ersatz um nicht auf Xlib aufsetzen zu müssen. Nur hat das erst mal niemanden interessiert – KWin zum Beispiel verwendet immer noch XLib und nicht XCB. Genauso die Toolkits: mittlerweile hat man die Erfahrung an den Problemen von X herumzuprogrammieren und warum sollte man etwas neu programmieren, wenn es funktioniert? Ein anderer Bereich ist die Erweiterung des Protokolls durch Erweiterungen wie XFixes – welche wie der Name sagt Fehler im X Protokoll behebt.

Warum sollte aber ein Display Manager eine bessere Lösung sein? Dazu kann man sich anschauen wie aktuell Fenster auf den Bildschirm kommen. Das Fenster wird zuerst gemappt – erhält also einen Bereich auf dem Bildschirm. Der X Server sorgt dafür, dass nur die nicht überlappten Bereiche gezeichnet werden. Die Anwendung zeichnet in der Regel in Pixmaps als Buffers und diese werden von X dann auf den Screen geblittet. Der X Server ist also zuständig dafür zu sorgen, dass die Inhalte aktualisiert werden. Wenn man also ein Fenster über einem anderen verschiebt, werden ständig beide neu gezeichnet. Nun schalten wir die XComposite Erweiterung dazu und betrachten uns das neue Verhalten. X leitet die Ausgabe der Fenster in eine off-screen Pixmap um (Moment? Die Anwendung zeichnet selbst doch auch schon in eine Pixmap…) und benachrichtigt einen externen Client (in der Regel den Fenstermanager) über die XDamage Erweiterung wann sich die off-screen Pixmap verändert. Das geschieht schön asynchron und in klitze kleinen Häppchen (man kann sich vorstellen, was passiert, wenn der Compositor nicht alle Änderungen mibekommt). Der Fenstermanager (oder auch Compositor) nutzt nun die GLX Erweiterung Texture from Pixmap um aus der Pixmap eine Textur zu erstellen und mittels OpenGL diese auf den Bildschirm zu zeichnen. Der ganze "legacy" Bereich des X Servers wird nun nicht mehr benötigt. Man muss keine Zeichenoperationen unterstützen, keine Fenster verschieben können und so weiter und so fort.

Ein kleiner Display Manager ist genau das was man will. Jede Anwendung wird automatisch und immer umgeleitet. Sie braucht also auch keine Informationen wo sie sich befindet. Interessant ist nur die Größe, ob sie aktiv ist oder nicht und vllt. ob sie sichtbar ist oder nicht (z.B. für Videoplayer um automatisch zu pausieren). Wenn man sich nun auch festlegt, dass Compositing generell über OpenGL erfolgt, kann man auch statt einer Pixmap direkt einen Buffer verwenden, der in OpenGL direkt benutzt werden kann. Der X Fenstermanager entfällt und kann nun durch einen viel schlankeren Compositor ersetzt werden.

Viele der heutigen Probleme im Compositing Stack von X sind vermutlich unlösbar. Ich denke da zum Beispiel an das Problem der "Löcher in Fenstern" oder die Tatsache, dass man keine Live Bilder von minimierten Anwendungen hat (was auch der Grund ist für das Stottern der de-minimier Animationen ist). Auch Lösungen um Live Bilder von Anwendungen auf anderen Desktops zu erhalten ist eigentlich nur ein riesiger Hack. Warum wird mein Bildschirm neu gezeichnet, wenn sich etwas auf einem anderen Desktop ändert? Bei einer Architektur, die sich primär auf Compositing ausrichtet, ist das natürlich viel einfacher.

Der Wechsel auf Wayland ist natürlich nichts, was schnell vollzogen werden kann und ich denke mal, dass es locker noch fünf Jahre dauern wird. Alle Toolkits müssen dazu die X Abhängigkeit verlieren, Desktop Shells müssen portiert werden – hier ist es vor allem wichtig gute Compositor zu erstellen, da sonst Funktionalität verloren geht und die wichtige Adaptierung von Wayland verhindern wird. Dies ist zum Beispiel bei KWin ein etwas schwieriges Unterfangen, da die Anwendung komplett X voraussetzt – nur die Effekte könnten fast komplett wiederverwendet werden (nach einer Portierung auf OpenGL ES 2). Es gibt sicherlich auch Anwendungen und Toolkits die niemals portiert werden – für diese wird es dann in Wayland auch einen eingebetteten X Server geben. Die Angst, dass geliebte Anwendungen durch die Transition verloren geht, besteht also nicht. Auch die Netzwerktransparenz von X bleibt somit erhalten.

Und was ist nun von der Canonical Ankündigung zu halten? Für mich klingt es danach, dass sie Unity so schreiben, dass es keine X Abhängigkeit erzwingt (wie zum Beispiel Plasma auch nicht) und dass sie wohl daran arbeiten werden Compiz als Compositor für Wayland fit zu machen. Dies wäre natürlich sehr interessant, da ich mich dort dann auch bedienen kann Bzw. dass man in den Bereichen zusammenarbeiten kann. Wir sind glücklicherweise so weit, dass wir grundlagen Technologie nicht mehr getrennt entwickeln. Vorerst bedeutet das wohl, dass Compiz auf OpenGL ES portiert werden muss – genauso wie KWin. Abgesehen davon wird wohl nicht viel passieren. Die Anwendungen werden weiter X verwenden.

Natürlich ist das jetzt auch nichts unglaublich herausragendes von Canonical in dem Bereich früh dabei zu sein. Sie werden es wohl auch nicht schaffen als erste Wayland einzusetzen, da MeeGo auch daran arbeitet (Kristian Høgsberg arbeitet für Intel) und gerade für Mobile Devices X nicht die beste Technologie ist. Außer Maemo setzt aktuell kein Linux Handy OS auf X. Um es ganz klar zu sagen: alle Distributionen werden so schnell wie möglich ein etwas funktionierendes Wayland ausliefern, um den Entwicklern eine Basis zum Portieren geben zu können.

Ich persönlich begrüße die Entwicklung, auch wenn es gerade für meine Anwendung viel Arbeit bedeuten wird, auf Wayland zu portieren und ohne eine Vollzeit Stelle wird so etwas kaum machbar sein. Dass Ubuntu nun diese Ankündigung macht, ist wirklich nicht überraschend, aber man muss Mark gratulieren zum guten Marketing

=-=-=-=-=
Powered by Blogilo

Diese Woche war es mal wieder soweit und ich bin auf den Entwicklungszweig der kommenden Version 4.6 der KDE Plattform, KDE Plasma und KDE Anwendungen umgestiegen. Normalerweise wechsel ich erst zum ersten Beta Release, jedoch wurde der Wechsel bereits nun erforderlich. Auf Grund der schlechten Erfahrungen des letzten Entwicklungszyklus, hatte ich mein Entwicklungsmodell angepasst und hatte unter Plasma 4.5 immer den Fenstermanager KWin in der Entwicklungsversion (plus persönliche Anpassungen) eingesetzt. Ich hoffe dass dies hilft Probleme früher zu bemerken, als wenn die Nutzer mit dem Beta Release die ersten Tester sind.

Um KWin "trunk" fahren zu können, darf KWin natürlich keine Abhängigkeiten auf andere Komponenten aus trunk haben. Das einzige Problem war dabei bisher die Fensterdekoration Oxygen, welche mit dem Widget Style zusammen eine gemeinsame Bibliothek in kdebase/workspace hat. Da diese sich verändert, zerstört das eine Übersetzung (ich sage als immer, dass ich ein reicher Mann wäre, wenn ich für jedes Mal wenn mein KWin trunk nicht kompiliert wegen Oxygen, einen Cent bekäme). Meine Lösung war Oxygen einfach in der Build Datei zu deaktivieren. KWin lädt dann einfach Oxygen von 4.5 (dank binärkompatibilität der Fensterdekorationen möglich) und das Problem ist umschifft. Und ich bin stolz, dass ich mehrere Monate entwickelt habe ohne jemals Oxygen durch ein git commit -a && git svn dcommit deaktiviert zu haben

Letztes Wochenende wurden nun Änderungen für die "Activities" eingespielt, welche auch eine weitere trunk-Abhängigkeit haben. Da diese Änderungen nicht mit einem Kommentar in CMakeLists rückgängig gemacht werden können, stand ich vor einem kleinen Problem: zurück auf 4.5 und test Account zur Entwicklung oder kompletter Wechsel. Das ganze verbunden mit dem Zeitdruck des aufkommenden Feature Freeze. Also einmal trunk neu durchkompiliert und auf 4.6 als primärer System gewechselt. Hat mich leider einen Abend gekostet, an dem ich eigentlich noch wichtige Features für 4.6 einbauen wollte

Für mich war es das erste mal seit Wochen, dass ich 4.6 neugebaut habe und es war für mich auch spannend, zu sehen woran die anderen Entwickler gearbeitet hatten und noch erfreulicher war, festzustellen, dass man nach Änderungen regelrecht suchen muss. Ein klares Zeichen dafür, dass KDE Plasma mittlerweile sehr ausgereift ist und die größten Änderungen weiter unten im Stack sind – so wie die Optimierungen in KWin.

Sehr erfreulich ist auch bereits die Stabilität von 4.6. Bisher ist mir noch keine Anwendung abgestürzt, obwohl wir gerade in der Phase sind, die wohl die instabilste überhaupt ist: zwischen soft feature freeze und hard feature freeze. Der klassische Zeitraum für "it compiles, ship it". Ich freue mich, dass wir in 4.6 den Nutzern wohl ein noch besseres Produkt liefern werden können als wir bereits in 4.5 konnten.

=-=-=-=-=
Powered by Blogilo

Auch dieses Jahr hat das Linux Journal seine Leser abstimmen lassen über die besten Anwendungen/Softwareprodukte und hat die Readers’ Choice Awards 2010 vergeben. Dabei hat KDE Software sehr erfolgreich abgeschnitten. Amarok und digiKam konnten jeweils in ihrer Kategorie gewinnen. Besonders für die Amarok Entwickler freut mich das sehr, da sie doch in den letzten Jahren viel Kritik einstecken mussten. Da ist es schön zu sehen, dass die Anwender die Arbeit schätzen.

Ein sehr schöner Erfolg ist auch das Abschneiden der KDE Plasma Workspaces (im Artikel als KDE bezeichnet): es konnte mit GNOME gleichgezogen werden und beide Desktopumgebungen belegen den ersten Platz. Im Vergleich zum Letzten Jahr konnte Plasma GNOME 10 % abknapsen. Als Plasma Entwickler freut es mich, dass die Anwender unserer Arbeit schätzen. Hier bin ich auch schon auf die Ergebnisse nächstes Jahr gespannt. Ich hoffe dass die Kategorie in Desktop Shell umbenannt wird, um auch unsere neuen Kollegen GNOME Shell und Unity neben KDE Plasma, GNOME Panel, XFCE, etc. antreten zu lassen.

KDE hat auch ein paar richtig tolle zweite Plätze belegt: Platz zwei hinter Android als "Product of the Year", OwnCload hinter MeeGo als "Best New Open-Source Project", KDevelop hinter Eclipse als "Best IDE", Choqok hinter Gwibber als "Best Microblogging Client". Hier sind auch ein paar neue und vielversprechende Projekte dabei. Gratulation und weiter so. Gerade KDevelop freut mich als Nutzer ungemein – ich muss leider auf Arbeit mit Konkurrenzprodukten arbeiten.

Man kann allen Lesern des Linux Journals nur danken für diese tollen Ergebnisse. Aber natürlich auch Gratulation allen anderen ausgezeichneten Produkten. Ein ganz besonderer Dank jedoch und Gratulation an all unsere Nutzer. Wir können zwar Software für uns selbst schreiben, aber ohne Nutzer ist es halt doch nichts. Und nur Nutzer können uns so tolles Feedback, wie diese Auszeichnungen geben. Daher: Danke

=-=-=-=-=
Powered by Blogilo

Wie gerade auf dem Dot angekündigt, wird morgen der erste KWin Bug Day sein. Es geht darum die immer größer werdende Zahl an offenen Bugs zu ordnen. Dazu gehört Bugs zu reproduzieren oder auch zu überprüfen ob Bugs überhaupt noch gültig sind, oder ob wir sie schon längst behoben haben. Hierzu braucht es überhaupt keine Programmierkenntnisse, eine aktuelle KWin Version ist völlig ausreichend. Daher meine Empfehlung: Morgen Update auf Kubuntu 10.10 und danach ab 13 Uhr im #kde-bugs IRC Channel auf FreeNode vorbeischauen und mithelfen.

Schon mal im Voraus vielen Dank an alle, die mithelfen

=-=-=-=-=
Powered by Blogilo

Bis zum Februar 2009 gab es eine wöchentliche Zusammenfassung aller KDE Commits im Commit-Digest. Danach hat Danny Allen die Arbeit alleine nicht mehr stemmen können. Mittlerweile arbeitet er daran es neu zu starten mit der Hilfe von vielen Freiwilligen und hat dazu eine Webplattform aufgebaut. Nun braucht es Freiwillige, die mitarbeiten die Commits durchzugehen und wichtige Commits herauszuheben. Mehr Infos dazu in Dannys Blog.

Der Commit-Digest ist ein unglaublich wichtiges Instrument, da er die KDE Entwicklung noch transparenter macht. Die Anwender können dadurch gut die Entwicklung verfolgen und sehen woran die Entwickler arbeiten. Ich erinnere mich daran, dass ich wöchentlich den Digest verfolgte als es zum KDE 4.0 Release ging und der Digest war somit ein wichtiger Faktor, dass ich überhaupt mit der Entwicklung begonnen habe.

Also hier nun auch von mir der Aufruf: helft bitte mit den Commit-Digest wieder mit Leben zu füllen! Danke.

=-=-=-=-=
Powered by Blogilo

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

Die freien Mesa Treiber haben in den letzten Jahren tolle und wichtige Fortschritte gemacht. Mesa ist eine der wichtigsten Komponenten des freien Desktops heutzutage. Für mich als KWin Entwickler die wichtigste Upstream Komponente – auch wenn ich selbst Mesa Treiber nicht nutze. Von Mesa ist es abhängig, ob man Compositing standardmäßig hat, ob Blur eingeschaltet wird und andere wichtige visuelle Eigenschaften. Die Treiber sind aber auch unglaublich wichtig für die Geschwindigkeit des Systems. Viele (vermutlich alle) Beschwerden über den langsamen KDE 4 Desktop lassen sich auf den Treiber zurückführen (proprietär und frei). Dies ist gerade in 4.5 sehr wichtig, weil wir Blur standardmäßig aktivieren werden, sofern der Treiber es unterstützt. Wir müssen uns also darauf verlassen können, dass die Entwickler nur das in der API anbieten, was die Hardware wirklich unterstützt.

Ich werde nun einige der Probleme beschreiben, die wir so mit den Mesa Treibern haben. Das ist aber kein Rant – ich schätze die Arbeit der Mesa Entwickler und bin ihnen sehr dankbar und freue mich darauf bald einen freien Treiber auch auf meinem System einsetzen zu können (Nouveau unter Debian unterstützt noch kein DRI).

KWin führt eine Whitelist über die Treiber, welche Compositing unterstützen. Also wir parsen den Version String, den man auch unter OpenGL Version in glxinfo findet, und ermitteln daraus den Treiber. Wäre das ganze standardisiert, dann wäre es richtig einfach. Ein vorbildliches Beispiel hier von NVIDIA:

OpenGL version string: 3.2.0 NVIDIA 195.36.24

Solange ich jetzt für KWin arbeite hat das bei NVIDIA nie Probleme verursacht. Zuerst die OpenGL Version, dann Hersteller und Treiber Information. Bei NVIDIA aktivieren wir falls die Version mindestens 173.14.12 ist. Die freien Treiber machten sich aber scheinbar einen Spaß daraus die Treiber Information immer wieder an eine andere Stelle zu schreiben und unsere Annahmen wichtige Information steht z.B. an zweiter Stelle haben dann plötzlich nicht mehr funktioniert. Das führte dann dazu, dass der Treiber nicht mehr in der Whitelist war und somit Compositing nicht mehr aktiviert wurde. Mittlerweile haben wir einen extra Parser für Mesa Treiber. (Richtig toll wäre natürlich wenn man sich auf die OpenGL Version verlassen könnte, aber das ist unmöglich, denn es gibt auch noch den Software Rasterizer und der nennt sich auch Mesa).

Im 4.4 Entwicklungszyklus hatten wir das Problem, dass einige Mesa Treiber die Anwendung in den Tod gezogen hatten, wenn man versuchte die Version zu ermitteln. Das Problem hierbei ist, dass man einen OpenGL Kontext braucht um die Version zu ermitteln und der Treiber die Anwendung in den Tod gezogen hat, wenn man einen Kontext erstellt. Das führte dann dazu dass KWin nicht mehr startete, denn wir schauen immer ob Compositing unterstützt ist. Zum Glück haben wir Logik um Crashes zu erkennen und deaktivieren dann sicherheitshalber mal Compositing. Schwieriger wurde es in den Systemsettings. Dort ist die gleiche Logik um zu schauen ob man Effekte einschalten kann mit dem Resultat, dass Systemsettings abstürzen sobald man auf "Desktop" geklickt hat. Das ganze wurde kurz vor Beta 1 zu solch einem Problem, dass wir noch schnell eine Sicherheitslösung eingebaut hatten, die etwas zu weit gegriffen hat und in der Beta mal eben Effekte für einige freie Ati Treiber deaktivierte.

In 4.5 verlangen wir den Treibern nun bedeutend mehr ab. Wir haben zwei grafische Effekte, welche programmierbare GPUs erfordern. Zum einen den neuen Blur Filter, zum anderen einen Filter um bessere Thumbnails zu erhalten. Diese Filter werden natürlich nur verwendet, wenn die Grafikkarte das auch unterstützt. Zum Glück macht es OpenGL einem einfach: es gibt Erweiterungen auf die man testen kann. Unsere neuen Filter brauchen die Erweiterungen GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_framebuffer_object und GL_ARB_shading_language_100. Wir überprüfen, ob die Erweiterungen vorhanden sind und aktivieren die Filter – so weit die Theorie. Unsere Effekte haben eine statische Methode welche aufgerufen wird bevor der Effekt geladen wird. Diese Methode führt die Überprüfung aus und sagt "Ja, ich funktioniere" oder "Nein, ich funktioniere nicht". Wenn Blur meint, dass er funktioniert, dann informiert er Plasma sofort darüber und Plasma verwendet nun bedeutend stärker transparente Hintergründe für die Popups. Nun wird so ein Popup mit starker Transparenz angezeigt, Blur Effekt springt an und versucht ein framebuffer object zu bekommen und hoppla funktioniert nicht. Somit kein Blur und das Popup ist unlesbar, weil zu transparent (siehe Bug 240956).

Das heißt also wir können nicht darauf vertrauen, dass das was der Treiber sagt was er unterstützt auch unterstützt ist. Also müssen wir manuell die Überprüfung durchführen, was natürlich unnötige Rechen- und Speicherzeit für alle Nutzer verschwendet. Es wird nun beim Start versucht ein framebuffer object der richtigen Größe zu erstellen und nur wenn das funktioniert wird Blur aktiviert. Gut Blur ist nun deaktiviert, Plasma verwendet nicht zu transparente Hintergründe – Problem gelöst.

Naja nicht wirklich: die Grafikkarte behauptet ja, dass Blur funktioniert also muss es machbar sein. Die Erklärung liegt im direkten und indirekten Rendering. Die benötigten Erweiterungen stehen nur bei direktem Rendering zur Verfügung. Wir verwenden für Mesa Treiber jedoch indirektes Rendering, d.h. alle OpenGL Befehle werden zuerst an den X Server übermittelt und von diesem an die Grafikkarte weitergereicht. Also unser oben beschriebenes Problem liegt darin, dass der Treiber behauptet Erweiterungen zu unterstützen welche nur mit einem direct rendering Kontext verfügbar sind.

Also brauchen wir einen direct rendering context. Wir haben auch Code, der ermittelt ob wir einen direct rendering context verwenden können. Dieser überprüft auf die glX Version. Wir brauchen die Funktion glXCreatePixmap(), welche seit glX 1.3 verfügbar ist. Also alles unter 1.3 kann kein direct rendering. Naja stimmt nicht ganz über eine Extension ist das auch in früheren Versionen verfügbar und Mesa unterstützt die. Also Code geändert und auf die Extension überprüft und nun gibt’s auch direktes Rendern für Intel Karten und somit Blur. Mission erfüllt: glückliche Anwender.

Schön wärs. Nun haben wir direktes Rendern, aber es gibt Karten, die sind einfach zu alt für Blur. Ergebnis: KWin startet und schaltet Compositing sofort aus (siehe Bug 242113). Der Treiber unterstützt OpenGL Shading Language für Grafikkarten, die das ganz bestimmt nicht können. Nun sind wir also kurz vor den RCs und bei vielen Nutzern werden die Effekte nicht mehr funktionieren, weil der Treiber etwas unterstützt, was die Hardware nicht kann. Wir könnten nun einfach direktes rendern wieder ausschalten für diese Treiber, aber das würde auch Effekte zerstören, die keine Shader brauchen, aber direktes Rendern – zum Beispiel den Logout Effekt.

Auch wenn ich nun viel über Intel geschrieben habe, gibt es auch Probleme mit anderen Mesa Treibern. Z.B. mit dem Treiber für Ati R600 Chips im kommenden OpenSUSE 11.3. Bei diesem werden alle Thumbnails und Fenster in Present Windows auf dem Kopf stehen (siehe Bug 240354). Das Problem ist im Treiber Entwicklungszweig bereits behoben und wir wollten das daher eigentlich ignorieren – bis ich gestern openSUSE auf meinem Zweitrechner mit R600 installierte…

Nun kann ich mir Gedanken dazu machen, wie wir am Besten eine Blacklist erstellen, die einfach von uns und den Distributionen erweitert werden kann. Vor allem wie man Treiber wieder von der Blacklist herunterbekommt ohne mit jeder neuen Treiberversion die Blacklist aktualisieren zu müssen. Whitelist funktioniert nicht – haben wir ja schon, wissen wir dass es eine schlechte Idee ist. Und ich glaube wir verwenden eine Whitelist, weil Blacklist bei Compiz zu Problemen geführt hatte…

=-=-=-=-=
Powered by Blogilo