OpenSLX

== Hardware-Erkennung auf DXS ==

Zentrale Komponente der automatischen Konfiguration ist eine Hardware-Erkennung. Diese übernimmt die weitgehende Einrichtung des Systems. Derzeit werden Teile des Knoppix-Mechanismus ('''hwsetup''' und ''libpci.so'') hierfür benutzt:

  * X-Server (ermitteln des notwendigen Treibermoduls für Xorg (landet innerhalb des Initialramfs in ''/etc/sysconfig/xserver'')

  * Laden der Audio-Module

  * Bestimmen des Plattencontrollers und angeschlossener Platten

  * USB-Setup

  * Cardbus-Setup

Dateien der Hardwareerkennung innerhalb des Initramfs:

{{{

initrd-stuff/lib

initrd-stuff/lib/libpci.so

initrd-stuff/lib/libpci.so.2

initrd-stuff/bin

initrd-stuff/bin/hwsetup

initrd-stuff/bin/ddcprobe

initrd-stuff/usr

initrd-stuff/usr/share

initrd-stuff/usr/share/hwdata

initrd-stuff/usr/share/hwdata/MonitorsDB

initrd-stuff/usr/share/hwdata/usb.ids

initrd-stuff/usr/share/hwdata/pci.ids

initrd-stuff/usr/share/hwdata/Cards

initrd-stuff/usr/share/hwdata/pcitable

}}}

'''hwsetup''' (Siehe hierfür [http://debian-knoppix.alioth.debian.org/sources]) bestimmt in erster Linie die zu ladenden Module. Sie werden anhand der ''pci.ids'' bzw. von ''pcitable'' erkannt. Diese Datei steht ständig aktualisiert unter [http://pciids.sourceforge.net/pci.ids] zur Verfügung.

Das Xorg-Setup wird mittels ''pcitable'' und ''Cards'' bestimmt, wobei der Sting "Card:ATI Radeon Mobility X600" (hinter Card) zu den Einträgen in der ''Cards'' passen muss, da sonst nur der "vesa" Treiber ausgewählt wird. Auf diese Weise lässt sich auch die ''pcitable'' (kommt aus dem Redhat "hwdata" Paket, derzeit Version 0.98) mit neueren Einträgen erweitern oder spezielle Konfigurationen (abweichende Treiber) einzelner Karten in ''Cards'' angeben. Hierfür wurden zwei Dateien eingeführt: ''pcitable.local'' und ''Cards.local'' wo alle Ergänzung drin landen sollten, die noch nicht in den ''offiziellen Dateien'' enthalten sind. (Auf die Dauer wäre gut zu wissen, wo die Dateien gepflegt werden, um Updates zu bekommen und eigene Ergänzungen upstream)

Wenn bestimmte Devices nicht in der ''pcitable'' stehen, wie bspw. "ata_piix", dann wirft das '''hwsetup''' diese auch nicht aus, womit sie nicht geladen werden:

{{{

...

0x8086  0x2582  "Card:Intel 915"

0x8086  0x2592  "Card:Intel 915"

0x8086  0x2653  "ata_piix"      "Intel Corp.|82801FBM Serial ATA Storage Controller"

0x8086  0x2772  "Card:Intel 945"

0x8086  0x2792  "Card:Intel 915GM"

0x8086  0x27a2  "Card:Intel 945"

...

}}}

Das waren die notwendigen Anpassungen für verschiedene Thinkpads, so dass die IDE-Module korrekt geladen und der X-Server richtig konfiguriert wird.

Die Datei ''Cards'' wird von verschiedenen X11-Konfiguratoren benutzt, wobei die Version, die bei SuSE/10.2/Xorg dabei ist, ordentlich alt aussieht (die Datei ist ein Witz/Relikt, da scheint auch nix mehr zu passieren). Derzeit scheint Version 1.178 die aktuellste zu sein, die Version 1.161 aus dem o.g. Redhat Paket ist wohl älter. Leider bekommt man nicht wirklich raus, wo die Datei eigentlich gepflegt wird :-( (clever auch, dass da keiner ein Datum reinschreibt)

Die MonitorsDB ist derzeit nicht im Einsatz ...

=== Einbau kommerzieller X-Treiber ===

Letzteres könnte der Ansatzpunkt sein, um kommerzielle X-Server für bestimmte Grafikkarten auszuwählen. Ein typischer Eintrag für eine Karte(nklasse) sieht so aus:

{{{

NAME ATI Radeon (generic)

CHIPSET R100

DRIVER radeon

# koennte ersetzt werden durch

NAME ATI Radeon (generic)

CHIPSET R100

DRIVER fglrx

}}}

Evtl. kann man diese Datei anpassen oder bei der Treiberauswahl je nach Vorhandensein "radeon" durch "fglrx" ersetzen. Ähnliches sollte auch mit "nv" und "nvidia" möglich sein.

Frage hierbei ist, welcher Weg sinnvoller ist: Eine Liste mit Devices lokal pflegen, für die die kommerziellen Treiber zum Einsatz kommen sollen (nicht alle Karten funktionieren mit den Treibern vernünftig) oder es generell in einer der o.g. Dateien festlegen und dabei den Kartentyp möglichst genau angeben (als nicht gerade auf "generic" verweisen).

Das Ganze ist nicht trivial, da mehrere Komponenten aus Kernel-Modulen, X-Server- und X-Client-Bibliotheken zusammenspielen müssen. Einen Überblick zur aktuell laufenden Konfiguration gibt '''glxinfo''':

{{{

name of display: :0.0

display: :0  screen: 0

direct rendering: Yes

server glx vendor string: SGI

server glx version string: 1.2

server glx extensions:

[ ... ]

client glx vendor string: SGI

client glx version string: 1.4

client glx extensions:

[ ... ]

OpenGL vendor string: Tungsten Graphics, Inc

OpenGL renderer string: Mesa DRI Intel(R) 945GM 20050225 x86/MMX/SSE2

OpenGL version string: 1.3 Mesa 6.5.1

OpenGL extensions:

[ ... ]

}}}

Dieses Beispiel zeigt ein System mit Intel i945 Chipset, welches das Kernel DRI verwendet. Das ist der freundliche Fall, da alles Open Source und mit der Distro bereits zur Verfügung gestellt. Wenn man die non-GPL Treiber von ATI und NVidia einsetzt, sollte in den drei Feldern etwas anderes stehen. ATI:

{{{

ATI

}}}

NVidia

{{{

}}}

ATI verwendet die Kernel-DRI-Infrastruktur, NVidia hingegen nicht.

== Device-Zugriff ==

Nur zum Teil ist Hardware fest mit der Maschine verbunden: Mittels USB, Firewire, SCSI, ... lassen sich Geräte auch nachträglich anschliessen oder wieder abklemmen. Unabhängig davon sollte dem Benutzer des Desktops (GUI die sich direkt auf die Maschine bezieht an der er sitzt - sonst gibts noch ganz andere Probleme) Zugriffsrecht auf die Hardware erhalten (und andere bspw. remote angemeldete Benutzer nicht).

Das Einbinden der Hardware regelt inzwischen "udev", die später möglichen Zugriffe werden von verschiedenen Diensten verwaltet.

=== SuSE10.2 ===

http://forgeftp.novell.com/resmgr/web/ ist die Homepage vom "resmgrd". Dort hat der Maintainer auch ein Bild der Zusammenhänge gezeichnet [http://forgeftp.novell.com/resmgr/web/#id2484325]

Wie glich im ersten Satz klargestellt wird, ist '''resmgr''' heute keine Resource Manager mehr. Diese Aufgaben werden von Skripten erfüllt, die der '''resmgr''' beim Login des Nutzers aufruft.

So sorgt ''/etc/resmgr.conf.d/99-desktop.conf'' zum Beispiel dafür, dass alle Nutzer mit "tty=:*" der Resmgr-Klasse (!= UNIX-Gruppe) "desktop" (definiert in ''/etc/resmgr.conf'') hinzugefügt werden.

''/etc/resmgr.conf.d/90-desktop-console.conf'' realisiert die Anbindung an PolicyKit. Der Datei ist direkt entnehmbar, welche ''/usr/bin/polkit-resmgr-*'' Skripte bei der An- oder Abmeldung ausgeführt werden.

Ebenso verhält es sich mit ''/etc/resmgr.conf.d/91-hal-resmgr.conf'' ...