noctus.net

Wenn mir ein Merkmal an PCs wichtig ist, dann ist es schnelle und saubere Wiedergabe von HD-Material. Während 720p überhaupt kein Problem darstellt, gibt es bei 1080p zum Teil drastische Unterschiede.

ATI Radeon HD4670

Aus diesem Grund tauschte ich dereinst meine eher betagte ATI Radeon 9600 (Chip RV350) gegen eine ATI Radeon HD4670 (Chip RV730), da mir erstere nicht mehr die Performance bot, die ich als Normalzustand voraussetze. Doch von Anfang an sah ich mich Problemen gegenüber gestellt. So war es praktisch an der Tagesordnung, dass der Bildschirm beim Systemstart bei der Aktivierung von KMS schwarz wurde und auch blieb. Dem Festplattengeräusch war zu entnehmen, dass das System und schließlich auch X normal weiter startete, das Bild blieb jedoch unbenutzbar. Die Tastenkombination SysRq+R,S,U,B ging nach kurzer Zeit trotz Verärgerung locker von der Hand, um zumindest das System so sauber wie möglich neu zu starten. Nach 1, maximal 2 Neustarts trat das Problem nicht mehr auf. Die Beziehung zwischen Kalt- und Warmstarts tiefer zu ergründen erschien mir zu müßig.

Ein weiteres Problem stellte der Einsatz von 3D in Form von OpenGL dar: immer wenn ein (vermeintlich) zu großer oder aufwändiger Zeichenkontext auf dem Bildschirm aktiv war, stockte das System kurz und startete urplötzlich und ohne jegliche Meldung neu. Trotz aller Anstrengungen, das Ausschreiben von System-Logs zu erzwingen gelang es mir nicht, auch nur eine Spur eines Hinweises zu finden, wo das Problem liegen könnte. Dieses Problem trat auf mit dem gl-Ausgabetreiber vom mplayer sowie beim Umschalten zwischen einer 3D-Applikation und einem anderen Fenster.

Schließlich das größte Manko: die HD-Wiedergabe von 1080p-Material war – Pardon – unter aller Sau. Der Verlust der Synchronisierung von Audio und Video war keine Seltenheit. Ruckeln und Schlieren (Tearing) an der Tagesordnung. Keine wirklich angenehme Benutzererfahrung, wenn ein Video stockt und bei stärkeren horizontalen Bewegungen quasi auseinander gerissen wird. Und stets droht die Gefahr, dass das System sich mal eben einen Neustart gönnt, wenn man es wagen sollte, den theoretischen Geschwindigkeitsgewinn einer OpenGL-Ausgabe nutzen zu wollen.

Ich spielte schon mit dem Gedanken, mir einen komplett neuen PC mit aktuellen Bauteilen zusammenzusetzen, als mir meine alte Radeon-Karte in den Sinn kam. Ich wollte es auf einen Versuch anlegen …

ATI Radeon 9600

Und ich sollte es nicht bereuen. Sämtliche angesprochenen Probleme sind verschwunden. Es erscheint mir unlogisch, wie eine deutlich ältere Karte mit deutlich weniger Leistung dennoch eine um ein Vielfaches bessere und stabilere Erfahrung bieten kann, aber genau so ist es. Die Wiedergabe von großformatigem HD-Material läuft nun sauber und ohne Probleme, der Systemstart läuft normal durch. Und 3D ist nun – der Leistung der Karte entsprechend – komplikationsfrei möglich.

In diesem Sinne stieß ich kürzlich auch auf eine Lösung für das Tearing-Problem. Durch den Einsatz von Compiz als Window-Manager löst sich das Problem in Luft auf. Dies begründet sich damit, dass Compiz auf OpenGL als Zeichenkontext setzt, wogegen Xfwm4, mein Standard-WM, XRender verwendet. Die für die Vermeidung von Schlieren unbedingt erforderliche VSync-Funktionalität ist dagegen in XRender nicht verfügbar, in der OpenGL-Ausgabe im Grafikkarten-Treiber jedoch standardmäßig aktiviert. Dadurch wird die Synchronisation der Zeichenoperationen mit dem Bildschirm erzwungen, womit eine flüssige Ausgabe erfolgt.

Als Treiber für beide Grafikkarten kam stets der offenen radeon-Treiber zum Einsatz, da das proprietäre Pendant in Form des fglrx-Treibers entweder nicht zur aktuellen X-Version kompatibel war oder schlichtweg nicht funktionierte. Und während die Einführung der Gallium-Architektur für den r600-Treiber aus meiner Sicht nur Nachteile brachte, mauserte sich der r300-Treiber zu einer zuverlässigen und durchaus performanten Möglichkeit, die Radeon 9600 zu betreiben. Alle Unzulänglichkeiten, die mich beim klassischen r300-Treiber zum Wechsel auf meine Radeon HD4670 bewegten sind nun pasé.

Fazit: um meinem Ziel einer angenehmen Wiedergabe von HD-Material näher zu kommen, musste ich einen Schritt zurück tätigen.

Da mich das lautstarke Knarzen meiner Logitech MX518 beim Scrollen schon lange störte und auch die Oberfläche dieser nicht mehr wirklich angenehm war, gönnte ich mir nach langer Zeit einmal etwas Neues. Nach kurzer Suche fiel meine Wahl auf die Logitech M500:

Damit kann ich nun endlich laut- und scheinbar endlos scrollen. Die Kippfunktion des Mausrads ist allerdings nicht ganz glücklich geraten; bei einem Mittelklick löst man viel zu leicht die Vor/Zurück-Funktionalität aus. Das fehlen der Tasten zum Umstellen der Auflösung im Vergleich zur MX518 kann ich verschmerzen, da ich diese sowieso nie wirklich genutzt habe. Nichtsdestotrotz wünschte ich mir bei meiner neuen Maus eine höhere Auflösung; die augenscheinlich standardmäßigen 400 CPI sind mir zu wenig.

Von früheren Versuchen war mir noch das Werkzeug Lomoco bekannt, welches ebenso die Möglichkeit bietet, die Auflösung sowie einige anderen Parameter von Logitech-Mäusen anzupassen. Der Versuch sollte allerdings erst einmal fehlschlagen:

$ lomoco --1200
002.018: 046d:c069 Unsupported Logitech device: Unknown

Da hieß es nicht verzagen sondern Quellen laden. Die schließlich notwendige Anpassung erwies sich als einer der heißgeliebten Einzeiler:

--- src/lomoco.c    2011-03-05 22:06:12.000000000 +0100
+++ src/lomoco.c    2011-03-05 22:07:23.000000000 +0100
@@ -47,6 +47,7 @@
 {0xc025, "MX500 Optical Mouse",                        "M-BP81A",     0, 1, 1, 1, 0},
 {0xc031, "iFeel Mouse (silver)",                       "M-UT58A",     0, 1, 0, 0, 0},
 {0xc041, "G5 Laser Gaming Mouse",                      "M-UAC113",    0, 1, 0, 1, 0},
+    {0xc069, "M500 Laser Mouse",                           "M-500",       0, 1, 1, 0, 0},
 {0xc501, "Mouse Receiver",                             "C-BA4-MSE",   1, 0, 0, 0, 0},
 {0xc502, "Dual Receiver",                              "C-UA3-DUAL",  1, 0, 0, 0, 1},
 {0xc503, "Receiver for MX900 Receiver",                "C-UJ16A",     1, 0, 0, 1, 0},

Der Quellcode selbst dokumentierte in einfacher Form, wie man an die nötigen Angaben gelangen kann. (In diesem Fall der Inhalt von /proc/bus/input/devices)

Und damit kann ich nun meine neue Maus per Lomoco konfigurieren. Um das ganze festzuhalten erstellte ich auch gleich einen Report für das Lomoco-Debian-Paket.

Ein sehr interessantes Projekt, auf dass ich kürzlich gestoßen bin ist Gloobus, hier insbesondere die Preview-Komponente:

Erklärtes Ziel dieses Projektes ist es, eine allgemeine Vorschau für Daten aller Art zu implementieren. Besonderes Augenmerk wird hierbei auf die Geschwindigkeit gelegt, denn einer langsamer Start ist ein KO-Argument für eine Vorschau. Dazu gesellt sich noch eine äußerst ansprechende Erscheinung, die laut Beschreibung sogar anpassbar sein soll.

Bei einigen kurzen Tests erwies sich die Vorschau als recht gut benutzbar, auch wenn sie bei hochauflösenden Bildern ähnlich langsam ist wie allgemeine Bildbetrachter wie Ristretto im Vergleich zum hier sehr schnellen Gthumb. Möchte man die jeweilige Datei genauer unter die Lupe nehmen, gibt es einen Vollbildmodus, möchte man sie bearbeiten eine entsprechende Schaltfläche dafür. Schlau ist auch die automatische Anzeige von Album-Cover beim Abspielen von Audio-Dateien.

Ein guter Schritt in die richtige Richtung, nur würde ich mir wünschen, dass die Vorschau automatisch beim Hovern von Dateien aktiv wird. Natürlich verbunden mit einer konfigurierbaren Wartezeit, falls man doch einmal nicht möchte, dass ein 1080p-HD-Video mit einer entsprechenden Dateigröße geladen wird.

Ich ging bisher davon aus, dass ich aufgrund meiner doch schon sehr langen Nutzung mittlerweile sämtliche Geheimnisse im Opera-Browser ergründet habe. Und immer wieder gelingt es ihm, mich vom Gegenteil zu überzeugen.

Heutiges Beispiel? Ich versuchte, Thunderbird als als Empfänger für mailto-Links einzurichten. Ein einfaches /usr/bin/thunderbird --compose genügt hier aber natürlich noch nicht, da die Bezugsadresse fehlt. Also versuchte ich, die erforderlichen Platzhalter zu finden, welche Opera durch die entsprechenden Textteile ersetzt. Ich stieß zwar auf eine Dokumentation einiger Platzhalter, doch sind diese nur für die Verwendung in Buttons brauchbar, welche beliebig in die Oberfläche integriert werden können. Bei meinen Experimenten damit fuhr ich mehr oder weniger absichtlich mit der Maus über das Eingabfeld und dies bekam ich zu sehen:

Schön, wenn jemand mitdenkt.

Ich habe nun unter http://download.noctus.net/debian/ ein Debian-Repository für meine selbstgebauten Pakete eingerichtet. Momentan sind dort folgende Pakete verfügbar:

• Filezilla (generiert aus den offiziellen Nightly Builds)
• QEMU (generiert aus den CVS-Snapshots)
• KQEMU
• Thunderbird (inklusive „Reply-To-List-Patch“, siehe Thunderbird auf Mailinglisten)

Folgende Zeile gehört in die /etc/apt/sources.list, wenn ihr meine Pakete nutzen wollt:

deb http://download.noctus.net/debian unstable/

Kompiliert habe ich sie unter Debian Sid, ihre Lauffähigkeit auf anderen Debian-Zweigen kann ich somit leider nicht garantieren. Um die Warnungen APTs aufgrund des unsignierten Repositories zu unterbinden, kann folgender Befehl ausgeführt werden:

wget http://noctus.net/0x77B0B098.pub.asc -O - | apt-key add -

Damit wird mein öffentlicher Schlüssel dem APT-Schlüsselbund hinzugefügt. Nähere Informationen hierzu finden sich im Debian Wiki.

Ich teste die Pakete auf meinem eigenen System recht ausgiebig und nutze sie auch alltäglich, dennoch kann ich Fehlfunktionen auf anderen Systemen nicht ausschließen, daher geschieht die Nutzung meiner Pakete auf eigene Gefahr.

Hinweis an Debian–Nutzer: seit Version 1.5.0.5-1 wurde dem Thunderbird–Paket seitens der Maintainer der Reply–To–List–Patch hinzugefügt. Meine Pakete sind damit obsolet und werden nicht mehr aktualisiert.

Seit einiger Zeit verfolge ich die Aktivitäten auf manchen Mailinglisten wie z. B. der „Debian User German“-Mailingliste. Da ich auch hin und wieder antworten möchte, war ich, wie wohl die meisten Thunderbird-Nutzer, gezwungen, entweder die „Antworten“-Funktion zu verwenden und die E-Mail-Adresse zu korrigieren oder aber die Privatadresse des Empfängers bei der „Allen Antworten“-Funktion zu entfernen.

Der Grund dafür ist, dass Thunderbird keine Möglichkeit bereitstellt, direkt auf die E-Mail-Adresse zu antworten, welche im List-Post-Mailheader enthalten ist. Dieser Mailheader legt im Allgemeinen fest, auf welche E-Mail-Adresse zu antworten ist, um direkt in die Mailingliste zu posten.

Angenervt von der Tatsache, dass der Umgang mit Mailinglisten im Thunderbird deshalb ziemlich umständlich ist und ich auch schon versehentlich eine E-Mail direkt an einen Poster geschickt habe, begab ich mich auf die Suche nach einer Lösung für dieses Problem. Und ich wurde fündig: Reply To List Thunderbird Extension.

Der Haken an dieser Erweiterung für Thunderbird ist jedoch, dass sie ein wenig tiefere Eingriffe in den Quellcode des Mailclients erfordert, da sie auf einige Funktionen zugreift, welche sich noch nicht in den offiziellen Quellen des derzeitigen Thunderbird-Entwicklungszweiges befinden. Der dafür erforderliche Patch ist nicht sonderlich umfangreich und deshalb erstaunt es umso mehr, dass der zugehörige Bugreport erst sechs Jahre nach Eröffnung geschlossen wurde.

Die Zeit bis zur Veröffentlichung von Thunderbird 3.0 wollte ich nicht abwarten, also lud ich mir mit Hilfe meiner Paketverwaltung die erforderlichen Quelldateien herunter, wandte den Patch an und baute mir frische und installierfertige Pakete. Diese wurden natürlich sogleich installiert, um die erforderliche Erweiterung ergänzt und für funktionstüchtig befunden. Mir steht nun also die gewünschte „An die Liste antworten“-Funktion zur Verfügung, welche das Arbeiten mit Thunderbird wieder etwas komfortabler macht.

Um anderen diesen Aufwand zu ersparen, stelle ich die von mir erstellten Pakete in meinem Repository zur Verfügung.

Ich wechselte bereits vor einiger Zeit vom offiziellen ATI-Treiber („fglrx“) zu seinem freien Pendant („radeon“) und bin damit bis auf einige Dinge auch recht zufrieden. Der Treiber ist im Gegensatz zum offiziellen Treiber sehr stabil und erlaubte mir nun auch erstmalig, die Composite-Erweiterung des X-Servers zu nutzen.

Bedauerlicherweise stand mir hier bis jetzt kein Direct Rendering zur Verfügung, was zur Folge hatte, dass sämtliche die Grafik betreffenden Berechnungen nicht direkt von meiner Grafikkarte durchgeführt werden konnten. Doch dies hat sich heute geändert. Das tägliche Systemupdate meiner Debian-Sid-Installation brachte heute die Mesa-Bibliotheken in Version 6.4.2-1 mit sich und nachdem ich im Bugtracker keine Release-kritischen Fehler finden konnte, welche mich betroffen hätten, aktualisierte ich die Bibliotheken.

Nun, nachdem ich mein System einmal neu gestartet hatte, um einige Dinge unter Windows zu erledigen, wollte ich einmal nachschauen, was mir die Aktualisierung gebracht hat und führte glxinfo aus:

ashura@core2:~$ glxinfo
name of display: :0.0
*********************************WARN_ONCE*********************************
File r300_state.c function r300Enable line 456 TODO - double side stencil !
***************************************************************************
No ctx->FragmentProgram._Current!!
display: :0
screen: 0
direct rendering: Yes …

Erst traute ich meinen Augen nicht und vergewisserte mich deshalb mit Hilfe von glxgears:

ashura@core2:~$ glxgears
5304 frames in 5.0 seconds = 1060.651 FPS
5326 frames in 5.0 seconds = 1065.156 FPS
5335 frames in 5.0 seconds = 1066.958 FPS
5343 frames in 5.0 seconds = 1068.417 FPS
5332 frames in 5.0 seconds = 1066.281 FPS

Zugegeben: der freie Treiber ist halb so schnell wie der offizielle, aber dies kann sich in Zukunft ja noch ändern.

Der aktuelle Entwicklungszweig von Mesa ist nun also in die offiziellen Pakete eingeflossen, womit mir nun endlich Direct Rendering zur Verfügung steht, was mir bisher nur die offiziellen Treiber ermöglichten.

Jetzt kann ich also auch endlich gänzlich auf ATIs Treiber verzichten, womit mein System gleich ein ganzes Stück sauberer wird. Und in Kombination mit meinem Wechsel des X-Servers zum modularen Zweig vor einiger Zeit ist mein System nun bestens gewappnet für nützliche Verschönerungen wie Xgl und AIGLX.

Angesichts der doch recht trägen Bedienbarkeit des per QEMU emulierten Windows-Systems spielte ich hin und wieder mit dem Gedanken, die Leistungsfähigkeit mit Hilfe des KQEMU-Kernelmodules zu verbessern. Doch die scheinbar komplizierte Kompilierung und Einbindung in mein System schreckte mich immer wieder ab. Zumindest bis vor ein paar Tagen, als ich beschloss, es erneut zu versuchen; die extrem niedrige Geschwindigkeit des Windows-Systems machte es einfach nahezu unbenutzbar.

Meine Suche nach vorgefertigten Paketen für meine Paketverwaltung verlief erfolglos, also machte ich mich daran, alle erforderlichen Schritte mit Hilfe des Quellcodes durchzuführen. Meine Suche führte mich zuallererst zu einem Blogeintrag bei Geek Pit. Das dort beschrieben Vorgehen führte aber leider nicht zum Erfolg, QEMU ließ sich nicht kompilieren und quittierte mit einer nicht sonderlich hilfreichen Fehlermeldung (welche mittlerweile in meinem Kommentar zu diesem Blogeintrag nachlesbar ist). Bei meiner Suche danach stieß ich neben einigen erfolglosen Diskussionen in Mailinglisten auf Nando Florestans „Installing KQEMU in Ubuntu“. Das dortige Script erschien mir, nachdem ich es mir zu Gemüte geführt hatte, recht brauchbar. Wie die Kommentare unter dem Beitrag aber zeigen, ist es noch fehlerbehaftet, weshalb ich es ein wenig überarbeiten und an mein System anpassen musste. Die fertige Fassung stelle ich hier zur Verfügung. Besonders nützlich an dem Script ist, dass es für den Kompiliervorgang kurzzeitig den aktuell installierten GCC (GNU Compiler Collection) umbenennt und eine gleichnamige symbolische Verknüpfung auf den alten GCC 3.x anlegt. Damit greift make auf diesen zu, womit sich QEMU kompilieren lässt. Ein weiterer Fehler ließ sich beseitigen, indem ich die aktuelle Version von checkinstall installierte, welche sich noch nicht im Repository meiner Paketverwaltung befand. Dieses Programm hat die nette Eigenschaft, dass es ein mit meiner Paketverwaltung installierbares und verwaltbares Archiv erzeugt.

Nachdem QEMU und KQEMU nun erfolgreich kompiliert, installiert und im Falle von KQEMU an die richtige Stelle verschoben wurden, wollte ich das Kernelmodul per modprobe laden. Murphys Gesetz folgend verlief aber auch dies nicht erfolgreich; ich erhielt ein „FATAL: Error inserting kqemu Invalid module format“, was sich darauf begründet, dass das mit dem GCC 3.x kompilierte Kernelmodul nicht in meinen per GCC 4.x kompilierten Kernel geladen werden kann. Meine Suche danach führte mich zu diesem hilfreichen Beitrag im QEMU-Board. Ich folgte dem dort beschriebene Vorgehen, kompilierte KQEMU mit meinem aktuellen GCC erneut und verschob das Modul in das erforderliche Verzeichnis. Damit konnte ich das Kernelmodul schließlich erfolgreich laden. Ich legte die KQEMU-Gerätedatei /dev/kqemu mit den erforderlichen Zugriffsrechten an und startete mein Windows-System per QEMU.

Und es hat sich gelohnt: die Geschwindigkeit ist massiv gestiegen und macht das System nun erstmalig wirklich benutzbar. Natürlich ist das emulierte System langsamer als ein physikalisch installiertes, doch für Testläufe und dergleichen reicht es allemal. Ein weiterer Nebeneffekt machte sich kurz darauf auch bemerkbar: Töne des Windows-Systems wurden nun auch endlich ausgegeben. Mir war zuvor noch nicht bewusst, dass hierfür SDL (Simple DirectMedia Layer) erforderlich ist. Das Windows-System läuft nun also genau so wie vorher, nur weitaus schneller und mit Tonausgabe.

Angesichts der Tatsache, dass QEMU zwangsläufig mit dem GCC 3.x kompiliert werden muss, verzögerte sich das ganze Vorhaben beträchtlich aber unlösbar war es letztendlich dennoch nicht.

Da es mich immer mehr nervte, für Arbeiten unter Windows mein Debian-System herunter- und Windows hochfahren zu müssen, habe ich mich nun endlich einmal durchgerungen, mich mit QEMU zu befassen.

QEMU ist ein vollwertiger System-Emulator, mit dessen Hilfe man beliebige Systeme in virtuellen Maschinen unter GNU/Linux, Windows und Mac OS X laufen lassen kann. Doch im Gegensatz zum bekannteren VMWare ist QEMU freie Software, das heißt, dass man sich die Quellen herunter laden, sie studieren und auch – die entsprechenden Programmierkenntnisse voraus gesetzt – modifizieren um sich angepasste Versionen zu erstellen.

Die Installation verlief unter meinem Debian-System gewohnt einfach. Ein einfaches apt-get install qemu genügte, um den Emulator sofort betriebsbereit installieren und einrichten zu lassen. Als nächstes musste ein Festplatten-Image für mein künftiges Windows-Gastsystem her, was wiederum mit qemu-img create winxpsp2.img 2G schnell erledigt war; damit hatte ich nun binnen weniger Augenblicke ein unformatiertes, 2 Gigabyte großes Festplatten-Image erstellt. Die Einbindung meiner physisch vorhandenen Laufwerke stellte sich zuerst als schwierig heraus, doch nach dem ich das QEMU-Tutorial im Ubuntuusers Wiki gelesen hatte, war auch dies kein Problem mehr. Ein noch viel ausführlicheres Tutorial findet sich in Form dieses Threads zu QEMU bei linuxforen.de; dort werden so gut wie alle aufkommenden Fragen beantwortet.

Als Nächstes folgte nun die Installation des Windows-Gastsystemes. Hierfür habe ich – wie bei meinem tatsächlichen Windows-System auch – ein angepasstes Setup verwendet, welches ich vor längerer Zeit per nLite erstellt hatte. Damit lässt sich das zu installierende System bereits vor der Installation an die eigenen Bedürfnisse anpassen; die Einstellmöglichkeiten sind umfangreich. Ohne Probleme konnte die Installation abgeschlossen werden und es folgte der große Moment: Windows startete.

Nach einigen kleineren nachträglichen Anpassungen hatte ich nun also ein vollständiges Windows-System, welches – natürlich nicht so schnell wie mein tatsächliches Windows-System – als Gastsystem unter Debian lief. Wirklich bemerkenswert einfach verlief die Einrichtung der Netzwerkverbindung, welche es dem Gastsystem ermöglichen sollte, auf das Internet zuzugreifen; mit einem einfachen -net nic -net user war dies im Handumdrehen erledigt.

Fortan startete ich dieses Gastsystem nur noch mit der Option -snapshot, welche QEMU veranlasst, jegliche Änderungen am (Datei-)System des Festplatten-Images lediglich temporär durchzuführen. Sofern man nicht im QEMU-Monitor (welche per Strg + Alt + 2 erreichbar ist) den Befehl commit ausführt, werden alle Veränderungen beim Beenden des Gastsystemes verworfen.

Der eigentliche Anlass dieses Vorhabens war jedoch hauptsächlich eines: die Installation der derzeitigen Beta 2 Preview des Internet Explorer 7. Nach dem der Eindruck der ersten Beta-Version für viele eher nüchtern war, versprach diese Version nun erstmalig auch wirkliche Ver(schlimm)besserungen unter der Haube. Viele Rendering-Bugs sollten behoben und einige neue Features hinzugefügt worden sein.

Um den IE 6 weiterhin parallel nutzen zu können, verließ ich mich nicht auf die Installation, sondern kopierte den Inhalt aus dem im Stammverzeichnis temporär entpackten Setup-Archiv in ein anderes Verzeichnis und brach das Setup ab. Ein wenig später erfuhr ich, dass man aber ebenso einfach das Setup mit einem Archivprogramm öffnen kann, um an dessen Inhalte zu gelangen.

Abschließend benannte ich nur noch die shlwapi.dll um und erstellte die aus den Standalone-Paketen des IE bekannte leere iexplore.exe.local-Datei; damit konnte ich den IE 7 nun starten. Eine alternative Methode besteht unter Nutzung des IE7 Standalone Launch Script. Ich ließ mich nicht von der veränderten, Windows Vista-inspirierten Oberfläche beirren sondern rief einige erste Seiten auf, um die tatsächlichen Verbesserungen heraus zu finden.

Mein bisheriger Eindruck bestätigt meine Erwartungen: der IE hat offenbar einiges dazu gelernt (alphatransparente PNGs werden nun offenbar korrekt unterstützt, die Pseudoklasse :hover wird nun auch bei nicht-Links interpretiert), aber vieles fehlt noch. So fehlt merkwürdigerweise die Unterstützung für einige andere der Pseudoklassen, die min-* und max-*-Eigenschaften sind noch immer nicht implementiert, obwohl sie wirklich nötig wären. Die Interpretation von fehlerhaftem Code wurde dagegen offenbar minimiert, was darin resultiert, dass nun diverse Hacks nicht mehr funktionieren.

Fazit: Allzu viel hatte ich nicht erwartet und dementsprechend bin ich von den neuen Rendering-Fähigkeiten auch nicht allzu enttäuscht. Ein wirkliches Urteil werde ich mir wohl frühestens bei Erscheinen der Beta 2 bilden. Bis dahin hat das Entwicklerteam des IE noch einiges zu tun und ich hoffe, dass so viel wie möglich ausgebessert wird. Zudem sollte der IE nun beständig weiter entwickelt werden, sofern Microsoft noch etwas am Marktanteil des IE liegt. Die Alternativen sind vielfältig und schon seit längerer Zeit dem IE in vielen Bereichen voraus.

Immerhin hat mir das ganze ein „Sandbox“-System beschert, mit dem ich nun nach Belieben experimentieren kann, ohne mein tatsächliches Windows-System zu gefährden.

Ich befasse mich nun schon eine beachtliche Zeit lang mit meinem Debian-System und arbeite aktiv damit. Nach und nach gelingt es mir, einen weiteren Schritt zur vollen Nutzbarkeit der Geräte an und in meinem Rechner zu tätigen. Heute wollte ich mich (erneut) mit der 3D-Beschleunigung befassen.

Zu meinem „Glück“ steckt in meinem Rechner eine Sapphire Radeon 9600 Atlantis und Grafikkarten mit Chips von ATI (bzw. die Treiber dafür) haben den Ruf, sich – im Gegensatz zu mit NVIDIA-Chips bestückten Grafikkarten – etwas „schwierig“ in GNU/Linux-Systeme zu integrieren. Aber nichtsdestotrotz wollte ich es nun (erneut) versuchen; warum sollte ich auf die 3D-Beschleunigung verzichten, nur weil ich ein Nicht-Windows-System nutze? Also frisch ans Werk.

Ich begann meine Suche nach einer kurzen Suche auf der ATI-Supportseite in der Treibersektion, wurde schnell fündig und konnte die Linux-Treiber für meine Grafikkarte herunterladen. Zuallererst habe ich es mit dem Installer versucht, welcher augenscheinlich ordnungsgemäß alle erforderlichen Dateien einrichten konnte. Im Anschluss daran musste ich nur noch fglrxconfig ausführen, um die Konfigurationsdatei für meinen X-Server, xorg.conf auf den neuesten Stand zu bringen. Damit sollte die Einrichtung abgeschlossen sein und ich mich eines Debian-Systemes mit 3D-Beschleunigung erfreuen können. Sollte. Nach dem obligatorischen Neustart war vom neuen Treiber nichts zu spüren. Die Testtools glxgears und glxinfo spuckten nach wie vor ärmliche Ergebnisse aus:

ashura@core2:~$ glxgears Xlib: extension "XFree86-DRI" missing on display ":0.0".
1638 frames in 5.0 seconds = 327.600 FPS
1488 frames in 5.0 seconds = 297.600 FPS
1612 frames in 5.0 seconds = 322.400 FPS
1388 frames in 5.0 seconds = 277.600 FPS
1488 frames in 5.0 seconds = 322.400 FPS

Soviel also zum offiziellen und einfachen Weg.

Angesichts dieses Misserfolges stellte ich meine alte xorg.conf wieder her und begab mich wieder in Richtung Suchmaschine. Nach längerer Suche stieß ich schließlich auf dieses sehr gute Tutorial für die ATI-Treiberinstallation. (Die Site ist offenbar seit einiger Zeit offline. Ich habe daher aus dem Google-Cache ein Backup des Tutorials erstellt.) Da ich einen 2.6er-Kernel verwende, kam für mich der entsprechende Installationsweg auf dieser Seite in Frage, welcher – zu meinem Erstaunen – angenehm kurz zu sein schien.

Nach dem ich also die erforderlichen Kommandos in der Konsole ausgeführt hatte, wurde mir ständig die gleiche Fehlermeldung präsentiert:

ATI module generator V 2.0 ==========================
kernel includes at /usr/src/linux/include not found or incomplete
file: /usr/src/linux/include/linux/version.h

Nach dem ich nun also wieder unseren liebsten Freund – die Suchmaschine – gequält hatte, fand ich heraus, dass ich die Kernel-Header meines aktuellen Kernels benötigte. Ich zweifelte jedoch schon fast an meinem Verstand und meinen Suchmethoden, als ich diese nirgends auftreiben konnte. Wieder nach einigem Suchen stieß ich dann aber auf den erlösenden Befehl: apt-get install linux-headers-`uname -r`. (Der Unterbefehl uname -r spuckt hierbei die Version des aktuell laufenden Kernels aus.) Damit konnte ich nun (endlich!) die Kernel-Header installieren. Dass ich bei meiner Suche nach „kernel-headers-2.6.12“ nicht erfolgreich war, verwunderte mich nun nicht mehr sonderlich.

Nachdem ich nun noch eine auf das eigentliche Kernel-Header-Verzeichnis deutende symbolische Verknüpfung namens „linux“ unter /usr/src angelegt hatte, um den ATI module generator zufrieden zu stellen, führte ich erneut oben erwähnte Kommandos zur Kompilierung des Treibermodules aus. Es folgte also das altbekannte fglrxconfig und meine xorg.conf war wieder auf dem neuesten Stand. Danach folgte der Neustart und die ersten nervösen Momente beim Starten des Systemes. Der X-Server gab keine Fehlermeldung aus, Auflösung und Farbtiefe waren unverändert und mein Window-Manager wurde wie gewohnt gestartet. Nun also der spannende Moment; ich führte glxgears aus:

ashura@core2:~$ glxgears
11883 frames in 5.0 seconds = 2376.600 FPS
12929 frames in 5.0 seconds = 2585.800 FPS
12946 frames in 5.0 seconds = 2589.200 FPS
12947 frames in 5.0 seconds = 2589.400 FPS
12947 frames in 5.0 seconds = 2589.400 FPS

Ungeachtet dieser mehr als erfreulichen Ausgabe führte ich nun dennoch zusätzlich glxinfo aus:

ashura@core2:~$ glxinfo | grep "direct rendering"
direct rendering: Yes

Und was soll ich nun noch groß sagen, außer: „Es funzt™!“

Zugegeben: die Installation war lang und steinig, aber dafür bin ich nun recht froh, alles selbst gemacht zu haben und ich dieses Wissen sammeln konnte. Meiner Meinung sollte ATI hier aber noch einiges in Bezug auf die einfache Installation der Treiber und damit einher gehend die Bedienerfreundlichkeit verbessern, wenn ihnen die GNU/Linux-Nutzer nicht gänzlich egal sind.