OpenSLX

Für NVidia gibts noch ein spezielles Problem: Die Devices /dev/nvidia0 und /dev/nvidiactl müssen für Nutzer zugreifbar sein. Das geht auch noch bei SuSE10.1 schief, wenn Nutzer nicht in der Gruppe "video" sind. U.U. müsste man das in /etc/udev.d/rules.d/* geeignet anpassen ...

NVidia macht komische Sachen mit dem Modulen, ein

echo -e "# nvidia stuff added by $0 in [[InitRamFS]]\nKERNEL==\"nvidia*|nvidiactl*\",\
GROUP=\"video\",MODE=\"0666\"" > /mnt/etc/udev/rules.d/10-nvidia-devperms.rules

Sowohl die NVidia als auch die ATI-Komponenten sollten unter Ubuntu/Gentoo/SuSE10.2 zur Verfügung gestellt werden. Bei letzterem ist ATI schon eingerichtet, aber anscheinend ist der Treiber nicht ganz i.O.

In diesem Zuge auch mal TVout für NVidia testen ...

Es gibt einen passenden Schalter für die TVout-Nummer (autom. Erkennung ist etwas schwierig) in der machine-setup:

# set tvout feature for certain graphic cards - not needed for average systems
# "yes" (then PAL is used) or tv standard as expected by card driver
#tvout="yes" 

Siehe jetzt auch XorgServer! Dort bitte alle Erkenntnisse ergänzen bzw. Fehler korrigieren.

Eine mögliche modulare Lösung für die Einbindung von Non-OSS-Treibern könnte wie folgt angegangen werden:

• Zusätzliche Komponente (Skript) bereitstellen, die von slxos-setup getriggert werden kann. Diese sollte das ATI und/oder NVidia-Zeugs aus dem Netz ziehen, entpacken und dann im Chroot des jeweiligen Vendor-OS kompilieren. Wäre also erst am Ende von slxos-setup sinnvoll. Insgesamt sollte es minimal-invasiv bleiben, also das mit dem Verlinken (nächster Punkt) nur machen, wenn man das Modul explizit aktiviert.

• Vorschlag wäre, zur Vereinfachung der Vorgänge im Stage3 (wenn kein UnionFS, AUFS zur Verfügung steht) im Filesystem für die 3D-Client und Server-Bibliotheken (siehe XorgServer) diese auf /var/X11R6/lib/<einheitlicher-name> zu linken.

• Im Stage3 würde man dann mit hwautocfg nachsehen, was für eine Grafikkarte installiert isthat und danach dann Checks durchlaufen lassen, dass alles da ist, wenn man ATI oder NVidia macht:
  • Kernelmodul laden
  • Überprüfen, ob die passenden Server-Module und Bibliotheken da sind
  • Checken, dass das Zeugs auch mit der Hardware läuft

• Hier sollte es so sein, dass das Open Source Treiber Fallback nur tätig werden muss, wenn das Stage1-Modul am Start war. Eleganterweise sollte man das am Anfang der Graka/3D Entscheidung checken, ob überhaupt das Stage1-Modul aktiv war. (Minimalinvasiv, also nichts am Vendor-OS-Filesystem ändern, wenn nicht unbedingt nötig)

Bleibt die Frage, wie die verschiedenen Treiber (ATI, NVidia, (Matrox), ...) ins Filesystem eingebunden werden. Hier nutzen neuere Gentoo's /usr/lib/opengl (oder so ähnlich). Dann wäre das Aufgabe des slxos-setup-Moduls (siehe dazu auch #135) dieses noch ins Client-FS einzubauen. Alternative wäre, es zusätzlich zu mounten (Aufwand, weiterer Export) oder es per ConfTGZ zu transportieren (liegt es im RAM des Clients) ...

Mein Vorschlag wäre momentan, den Graka-Kram als ein unabhängiges SLX-Plugin zu implementieren. Ein solches Plugin würde Funktionalität in Stage1 sowie Stage3 bereitstellen:

Der Stage1-Teil des Plugins hätte nichts mit slxos-setup zu tun, sondern würde erst über die Datenbank aktiviert, also per slxconfig. Bei Aktivierung sorgt das Plugin dann selbst (über Nutzung der OpenSLX::OSSetup Perl-Module) dafür, dass die benötigten Pakete installiert werden (oder eben kopiert, falls die entsprechende Distro keine entsprechenden Pakete bereitstellt). Die benötigten Dateien sollten an eine dezentrale Stelle im Vendor-OS Filesystem gekippt werden, z.B. nach /opt/openslx/plugins/<name-des-graka-plugins>. Nur so ist gewährleistet, dass das Vendor-OS nicht gleich "Kaputtgespielt" wird.

Unter /etc/opt/openslx/plugins könnte das Plugin dann die Konfigurationsdatei(en) mit den benötigten Infos (ATI ja nein, NVidia ja/nein, etc) hinschreiben und außerdem noch ein OpenSLX-Runlevelskript an eine zu definierende Stelle packen, welches das eigentliche Setup in Stage3 übernimmt.

Init in Stage3 findet dann eben das Runlevel-Skript für das Graka-Plugin und startet es, dieses wiederum schaut sich die Konfiguration in /etc/opt/openslx/... an und nimmt die für den aktuellen Client benötigten Änderungen vor. Also z.B. für einen Client mit ATI-Karte den ATI-Treiber einrichten (am besten über Symlinks, weil das am wenigsten Speicher kostet) sowie das Kernelmodul laden.

Wichtig bei diesem Modell ist vor allem, stets darauf zu achten, dass es einen generischen Weg von slxconfig bis zur Stage3 gibt, so dass einerseits beliebige Dateien und Konfigurationen an das jeweils passende Runlevel-Skript in Stage3 durchgeschleust werden können, ohne dass die eigentlichen Stage3-Skripte irgendetwas über ein Plugin wissen muss.
Alles was init wissen sollte, ist, wo die Plugin-Runlevel-Skripte stehen könnten und in welcher Reihenfolge sie gestartet werden müssen (letzteres kann man ja ganz einfach wieder per alphabetischer Sortierung vorgeben, siehe init.d).

Zur struktuellen Umsetzung siehe jetzt auch ModularExtensions ...

Unterschiede NVida, MESA:

• /usr/lib - NVidia überschreibt libGLcore und libGL mit eigenen Dateien
• /usr/lib/xorg/modules/drivers - für NVidia kommt nvidia.so Modul hinzu
• /usr/lib/xorg/modules/extensions - NVidia entsorgt die libGLcore und überschreibt die libglx.so
• Kernelmodul

Milestone V4.1.90 deleted