AW: W-Lan konfiguration
*Puuuuuuuh*, na also.
OK, nun eine kurze Erklärung, warum du diese Probleme hattest. (Und warum ich so ein guter "Hellseher" bin *g*).
Die Sache ist die, sowohl der ATI-Treiber als auch ndiswrapper oder besser die Windows-Treiber, man mit ndiswrapper einbinden kann, sind keine Open Source Software wie Linux und das dazugehörige System selbst.
Sogenannte Closed-Source Treiber können aus rechtlichen und auch teilweise aus technischen Gründen NICHT direkt in den Kernel eingebunden werden, und das hat auch seinen Grund. Wird z.B. ein kritischer Fehler in einem Open Source Treiber entdeckt, dann können die Kernel-Entwickler sich selbst drum kümmern und das tun sie auch meist recht schnell, da sie ja den Quellcode des Treibers haben (meist hat ihn auch einer dieser Entwickler selbst geschrieben). Tritt aber dieses Problem bei einem Treiber auf, der im Kernel wäre OHNE daß die Entwickler das Problem beheben können, weil ihnen der Quellcode fehlt, dann gute Nacht.
Microsoft z.B. macht es prinzipiell ähnlich. Die lassen auch (zumindest freiwillig nicht, Viren/Rootkits fragen ja nicht bei MS nach .. *kicher*) keinen fremden Code in ihren Kernel dessen Quellen sie nicht haben. Der einzige Unterschied ist, daß der Quellcode bei MS-Software eben nicht offen liegt.
Gäbe es quelloffene Treiber für Deine Graphik- oder WLAN-Karte, dann könnte man sie direkt in den Kernel einbinden und alles wäre in Butter, denn in jedem neuen Kernel-Release wären die Treiber gleich mit drin und sie würden auch zum Kernel passen.
In meinem Desktoprechner ist z.B. eine etwas ältere ATI-Karte drin, die mit einem OSS-Treiber wunderbar auch mit 3D-Unterstützung läuft. Ich hatte bisher noch nie Ärger nach einem Kernel-Update oder wenn sich die Version des X-Servers änderte, weil die Treiber eben immer zur neuen Version passten.
Neuere ATI-Karten laufen mit den bisher vorhandenen OSS-Treibern leider nur eingeschränkt, meist ohne 3D.
Da ATI weder selbst offene Treiber entwickelt noch die Spezifikationen seiner neuen Karten offenlegt, damit jemand aus der Linux-Community anhand dieser Daten einen Treiber schreiben kann, gäbe es nur eine Möglichkeit für OSS-Treiber, nämlich das jemand "entschlüsselt" wie die Hardware mit dem Treiber kommuniziert um dann rückwirkend auf die Spezifikation zu schließen. Sowas nennt man (die Experten mögen mich korrigieren) "reverse Engineering". Ich bin mir sicher, daß einige der mittlerweile offenen Treiber genau auf diesem Wege entstanden sind. Man ermitelt, wie die Hardware funktioniert und versucht anhand dieser Daten einen Treiber zu schreiben.
Der Haken an der Sache, es ist ein sehr zeitaufwendiger und komplizierter Prozeß, der umso komplizierter wird, je komplizierter die Hardware ist.
Insgesamt gibt es also nur noch eine übrigbleibende Möglichkeit, nämlich daß ATI eigene Treiber mit NICHT offenem Quellcode entwickelt und diese dann über ein Kernelmodul, also einen Treiber, der nicht fest im Kernel sitzt sondern nur zur Laufzeit (also wenn er gebraucht wird) geladen wird.
Würde ATI auch das nicht tun, so wie z.B. einige Hersteller von WLAN-Karten keine Linuxtreiber schreiben und auch keine Specs offen legen, dann läuft die Karte nicht (es sei denn es gibt so ein Hilfsmittel wie ndiswrapper).
Das Prinzip der Kernelmodule wird übrigens nicht nur für Closed Source Treiber verwendet, eigentlich ist es eine Entwicklung von Linux selbst, die viele native Treiber auch nutzen, denn es macht z.B. bei Wechselmedien Sinn, daß der Treiber nur dann geladen wird, wenn diese Hardware eingestöpselt wird, da dann der Kernel als solcher schlanker und schneller bleibt.
Die älteren Versionen des Linux-Kernels waren rein "monolithisch", d.h. alle Treiberfunktionen waren fest in den Kernel einkompiliert. Damit wird der Kernel zwar stabiler, weil er sich eben nicht während des Betriebes ändert, aber es hatte einen entscheidenden Nachteil.
Hatte man neue Hardware, deren Treiber eben noch nicht im Kernel war, dann musste man, um diese Hardware nutzbar zu machen eine neuen Kernel mit einem Treiber für die neue Hardware kompilieren. Für einen Server, der hohe Stabilität und praktisch keine wechselnde Hardware hat, macht sowas Sinn, aber für einen Desktoprechner ist das eher unpraktisch. (Stell Dir vor, Du müsstest bevor Du den USB-Stick lesen kannst, einen neuen Kernel kompilieren und wenn Dein Nachbar mit seinem USB-Stick kommt, dann gleich nochmal
).
Nun könnte man sagen "Moment, dann kompiliere ich mir halt einen Kernel mit ALLEN verfügbaren Treibern und hab das Problem nicht".
Haken an der Sache:
1. Der Kernel wird dann ziemlich "fett" und lahmarschig und vor allem
2. Es gibt ständig neue Hardware und damit auch neue Treiber, so daß diese Methode wenn überhaupt, dann nur für kurze Zeit was bringen würde.
OK, zurück zum Thema.
Die ATI-Treiber und auch ndiswrapper nutzen diese Möglichkeit der Kernel-Module, allerdings muß in diesem Fall, da eben die Module NICHT von den Kernelentwicklern selbst kommen, nach jedem Kernel-Update das jeweilige Modul an den neuen Kernel angepasst werden.
Es ist klar, daß es da ab und zu mal Probleme gibt.
Man kann es vielleicht mit 2 Menschen vergleichen, die unterschiedliche Sprachen sprechen (Linux-Kernel und ATI-Treiber) und einen Dolmetscher (Kernel-Modul) haben, wobei noch hinzukommt, daß beide ihren Sprachschatz dauernd erweitern (das ist besonders beim Linux-Kernel so. Wenn der Kernel irgendwann mal nicht mehr in ständiger Weiterentwicklung ist, dann ist das der Tag an dem Linux tot wäre). Der Dolmetscher muß immer das aktuellste Wörterbuch der beiden Sprachen haben, sonst kommt es zu Übersetzungsfehlern.
Ich könnte noch stundenlang so weiter schreiben, aber ich hoffe zumindest Du hast so ein wenig mitbekommen, worum es dabei geht.
Kurz noch zurück zu Deinem Problem.
Ab jetzt wirst Du bei jedem Kernel-Update aufpasssen müssen, daß das Modul für den ATI-Treiber neu gebaut wird. Das steht auch alles in meinem HowTo und es ist, wenn man es ein- zweimal gemacht hat, dann auch nur noch Routine.
Bei Problemen mit ndiswrapper nach einem Kernel-Update wirst Du genauso schauen müssen, daß das passende Modul zur neuen Kernelversion vorhanden ist. Das SuSE-Paket scheint da einen etwas anderen Weg als die "originalen" Pakete von ndiswrapper zu gehen, aber eines solltest Du Dir merken.
Ruhig bleiben und nicht gleich SuSE neu installieren. Erstmal ndiswrapper neu installieren oder deinstallieren und wieder installieren, Deine Einstellungen für die Karte gehen dadurch nicht verloren, weil sie woanders gespeichert werden.
Wenn ein Update von xorg-Paketen ansteht, dann vorher erstmal die Datei /etc/xorg.conf sichern und wenn dann die graphische Oberfläche nimmer will nach einem Neustart, dann einfach die Kopie wieder einspielen (aber vorher auch von der neuen Version der Datei xorg.conf eine Kopie anfertigen, vielleicht braucht man die ja nochmal). Das geht alles sehr flott über die Kommandozeile und auch ohne graphische Oberfläche und wenn Du noch aus DOS-Zeiten den Norton Commander kennst, dann hilft Dir vielleicht folgender Befehl weiter:
Was dann passiert sage ich jetzt nicht, laß Dich einfach POSITIV überraschen
.
Ausserdem gibt es auch einen Yast, der ohne graphische Oberfläche auskommt, er kann als root mit dem Befehl
aufgerufen werden. Zwar ohne Maus, aber mit den Pfeiltasten geht es auch und die Funktionen sind die selben.
OK, nun kann ich nur noch SuSE selbst zitieren:
"Have a lot of Fun"
Greetz,
RM
P.S. Und noch was. Du hast es selbst wieder hinbekommen, meinen Glückwunsch dafür
.
Operation gelungen, Patient lebt.
----> Closed
