Category: Linux

freedesktop.org ist das Standardisierungsprojekt um Desktopeinstellungen unter Linux für alle (Mainstream)Desktops zu vereinheitlichen. Gemeint sind v.a.

• KDE
• Gnome
• XFCE

Dies betrifft bspw. das Anlegen eines Menüs unter KDE, was man bei einem Wechsel auf Gnome immer noch sehen möchte.

Das Projekt hatte mit diesen Bestrebungen Erfolg – entscheiden sind dabei die XDG (vom Namensvorgänger der Organisation: X Desktop Group).

$XDG_DATA_HOME (default: $USER/.local/share ) 

$XDG_CONFIG_HOME (default: $USER/.config )

$XDG_DATA_DIRS (default: /usr/local/share:/usr/share )

$XDG_CONFIG_DIRS (default: /etc/xdg )

Die beiden letztgenannten Verzeichnisse sind die globalen, in denen Default- oder Fallbackeinstellungen abgelegt werden. Die beiden erstgenannten sind die Benutzereinstellungen.

Wichtig bei allen XDG-kompatiblen Desktops ist die Fähigkeit, die Reihenfolge der Verzeichnisorte auszuwerten, sowie die Voreinstellungen der Umgebungsvariablen bei Nichtvorhandensein zu kennen.

Kommerzielle Interessen unterschiedlicher Hersteller verhinderten in der Vergangenheit erfolgreich ein UNIX OS – stattdessen kochte jeder UNIX Hersteller sein eigenes Süppchen…. bis es verkochte.

Obwohl die Grundideen die gleichen waren und POSIX zumindest noch Sourcekompatibilität gewährleistete, gab es keine Binärkompatibilität und somit keinen UNIX Massenmarkt.

Das Resultat ist bekannt. Ausser Sun Solaris und IBM AIX, die sich in Server-Nischenmärkten noch halten könnten, sind alle Anbieter verschwunden (oder verschwinden gerade)

Damit dieses Schicksal Linux erspart bleibt, wurde vor einiger Zeit die Linux Standard Base gegründet. Diese ist unter der Linux Foundation angesiedelt. Das Projekt wird innerhalb des Linux Developer Network Portals gehostet.

http://ldn.linuxfoundation.org/lsb

LSB ist mittlerweile ein vollwertiger ISO Standard: ISO/IEC 23360

Der Standard schreibt Interfaces vor, die für die Entwicklung vorhanden sein müssen, sowie Libraries mit Ihren zugehörigen Symbolen (teilw. auch Versionierung) für die Entwicklung und zur Laufzeit.

Um breitmöglichste Akzeptanz und Kompatibilität zu erreichen setzt die LSB auf schon vorhandene Standards auf:

• POSIX
• Single UNIX Specification (SUS)
• C++ ABI
• System V ABI
• PAM
• X11
• freedesktop.org

Ab Version 3.0 stellt die LSB Rückwärtskompatibilität zur Verfügung – somit laufen LSB 3.0 zertifizierte Produkte auch auf einem LSB 3.1,3.2 oder 4.0 System. Daraus lässt sich folgern, dass Interfaces nur noch dazukommen, aber nicht mehr entfernt werden dürfen. Eine Beseitigung von Interfaces darf nur noch nach Kennung einer Deprecation über drei Major Versions erfolgen.

Die wichtigsten von der LSB zur Verfügung gestellten Tools sind:

• Linux Application Checker
• LSB Database Navigator
• LSB Build Tools

Äusserst wichtig ist das Analysieren der verwendeten Symbole in Shared Libraries oder Binaries. Eine eigenen Überblick verschafft man sich am besten mit dem Kommandotool objdump ,z.B. mit:

objdump --private-headers /usr/lib/libstdc++.so.6

SONAME bestimmt im Suffix die Hauptversion der Library, gegen die gelinkt wird (d.h. Binaries die gegen die C++ Library linken, tun das gegenüber Version 6 und nicht etwa 6.0 oder gar 6.0.5)

Nach dem Dynamic Section Block kommt dann der Version definitions Bereich, in dem die Symbol Versionen gelistet sind. In dieser Datei sind bspw. alle Symbol Information GLIBCXX der Versionen 3.4.0 – 3.4.8 vorhanden.

Danach folgt schliesslich der Bereich Version References in dem die benötigten Symbolinformation der gelinkten Libraries aufgelistet sind.

Der Linux Application Checker analysiert die Symbole in den Shared Libraries. Die strikte Überprüfung hat zur Folge, dass nur Libraries in die LSB aufgenommen werden können, welche die Abwärtskompatibilität der LSB respektieren.

Einen kompletten Überblick über Libaries, deren Symbole, Interfaces und Kommandotools welche den Standard abdeckt, liefert der sog. LSB Navigator. Es handelt sich dabei um eine Informationsdatenbank, die neben den o.g. Informationen auch noch Herkunft und Versionierung aufführt.

Mit dem neuen, verbesserten LSB ist es mittlerweile möglich mehrstufig portabel zu Programmieren, je nach dem ob einem nur ad-hoc oder zertifizierte Portabilität wichtig ist. Nachdem man allg. Portabilitätsgrundsätze beachtet hat, wären die jeweiligen Stufen:

1. Minimalportabilität durch Application Checker gewährleisten
2. Gesteigerte Portabilität durch die LSB Build Tools
3. Maximale Portabilität durch ein LSB Zertifikat

Wenn alle Tage neue Features eingeführt werden, Buzzwords inflationär auftauchen, alte Gewohnheiten nicht mehr gelten  und dadurch Probleme bei der täglichen Arbeit entstehen wird es mal wieder Zeit sich einen Überblick über den Stand der Technik zu verschaffen.

Wie jeder weiss ist Linux nur der Betriebssystemkern. Alle graphischen Anwendungen, sei es das komplette Desktopsytem wie KDE oder Gnome, als auch einzelne Anwendungen, wie Grafikprogramme oder Spiele benötigen ein X-Window System.

X.Org ist unter Linux die Referenzimplementierung dieses Systems und liegt derzeit in der Version 7.4 vor. Die X.Org Foundation sah sich ursprünglich nur für X-Standards verantwortlich, während XFree86 das Projekt war, dass die eigentliche Implementierung mit dem xserver als Kernbestandteil, zur Verfügung stellte.
Die Entwicklung im XFree86 Projekt war allerdings recht träge und führte dazu, dass der Innovationsabstand zwischen X-Windows auf UNIX Systemen gegenüber MS Windows und Mac OS X immer grösser wurde. Als im Jahr 2003 dann Streitigkeiten über eine neue Lizenz aufkeimten, zogen viele Entwickler die Notbremse und gründeten die neue X.Org-Stiftung die nun ebenfalls eine X-Window Implementation herausbrachte.
Innerhalb kürzester Zeit erschien X.Org 6.8 auf Basis von XFree86 4.4, welches dann nacheinander von allen Distributionen als Standard X-Windows System installiert wurde.

Erstes Ziel war die Modularisierung um die Grafiktreiberprogrammierung zu erleichtern und eine ausbaufähige Grundlage für zukünftige Modernisierungen zu schaffen. Dieses Ziel wurde mit X.Org 7.0 erreicht.

Mit dem Aufkommen der Composite Window Manager einerseits und dem Eintreten von Intel als GPU Hersteller andererseits kam eine für dieses Projekt ungekannte Dynamik ins Spiel. Dafür sind jetzt eine Reihe von Begriffsklärungen notwendig:

xserver

Während X.Org die Agglomeration aller am X-Windows System beteiligten Komponenten ist, also inkludierte Grafiktreiber, Keyboard Treiber, X-Video Erweiterung, stellt der xserver die zentrale Komponente des Systems dar.
Mit erscheinen von X.Org 7.4 wurde xserver in Version 1.5.2 mitgeliefert. Im Februar 2009 erschien dann aber xserver 1.6.0 ohne ein gleichzeitiges Minor Update von X.Org. Der neue xserver integriert sich stattdessen in X.Org 7.4 und stellt neue Features, allen voran DRI2 bereit.

Direct Rendering Interface (DRI)

Komponenten, die es Applikationen erlauben, innerhalb des X-Window Systems, die Video Hardware direkt, unter Umgehung des xservers, anzusprechen.

Die Beteiligten Komponenten sind:
– Kerneltreiber (Direct Rendering Manager, DRM) der eine Schnittstelle zur Grafikkarte bereitstellt
– Userland Treiber innerhalb des MESA Projektes.

Seit 2000 (XFree86 4.0) war DRI1 die Major Revision, welches OpenGL Applikationen veranlasst direkt auf den Framebuffer zu zeichnen. Mit Erscheinen des xservers 1.6 wurde DRI2 released. Dies erlaubt jetzt die Umleitung auf ein Offscreen Memory, so dass der Compositing Manager verschiedene Ströme zusammen verarbeiten kann. DRI2 erfordert aber ein neues Grafik-Speichermanagement, names GEM.

Derzeit unterstützen alle Open-Source Treiber sowie der proprietäre AMD/ATI Grafiktreiber DRI1. Intel unterstützt seit der Intel Grafiktreiberversion 2.6 auch DRI2, benötigt aber damit GEM und implizit damit mindestens Kernel 2.6.28.

Der proprietäre nVIDIA Grafiktreiber hat ein völlig eigenständiges Direct Rendering Konzept welches im Kerneltreibermodule realisiert wird.

MESA

Mesa ist eine Open Source 3D Grafikbibliothek welche eine generische OpenGL Implementation zur Verfügung stellt.

Eine OpenGL Anwendung linkt dabei gegen /usr/lib/libGL.so.X

Mesa sorgt dafür, dass diese Datei ein softlink zur MESA (OpenGL) Bibliothek darstellt. Weiterhin stützt sich diese Bibliothek entweder auf eine passende DRI Bibliothek der Grafikkarte – und damit direktes (hardwareunterstütztes) Rendering oder er fällt auf indirektes (softwaregestütztes) Rendering zurück.

Da der proprietäre nVIDIA Treiber die DRI Architektur nicht unterstützt, muss allein schon deshalb der softlink von /usr/lib/libGL.so.X auf die eigene OpenGL Biblitohek zeigen, welche die OpenGL Kommandos dann in Hardwarebefehle umsetzen kann.

Memory Management / GEM

Bis xserver 1.6 haben ausnahmslos alle Grafiktreiber die Verwaltung des Grafikspeichers selbst implementiert.
Mit DRI2 wird jetzt erstmals – mit dem Graphics Execution Manager (GEM) – ein generischer Memory Manager für GPU’s vom Kernel (ab 2.6.28) bereitgestellt. Er kontrolliert den Ausführungskontext und managt NUMA auf modernen Grafikkarten. Verschiedene Applikationen können nun GPU Ressourcen teilen ohne GPU state changes selber verwalten zu müssen.
GEM wird derzeit nur vom Intel Treiber 2.6.0 verwendet.

X Rendering Extension (XRender)

Stellt eine Komponente für Porter-Duff Image Compositing und Alpha-Blending bereit. Gedacht war diese Erweiterung v.a. für Antialiased Schriften, wird aber auch für alle möglichen Desktop Effekte genutzt. XRender stützt sich massgeblich auf die 2D Beschleunigungsarchitektur von X.Org ab.

Unter den KDE4 Systemeinstellungen kann man wählen, ob die Desktop Effekte via OpenGL (also DRI, oder nVIDIA Direct Rendering) oder XRender ausgeführt wird.

2D Beschleunigung

Während mit DRI+MESA bzw. nVIDIA’s eigener Architektur, die 3D Funktionalität bereitgestellt wird, gibt es im 2D Bereich eine eigene Subkomponente.
Seit 1996 exisitert mit dem Modul XAA (XFree86 Acceleration Architecture) eine Treiberarchitektur die es ermöglicht auf die 2D Hardwarebeschleunigung von GPU’s zuzugreifen.
Da XAA viele 2D Operationen sowie XRender nicht mehr genügend beschleunigte und zusätzlich erhebliche Probleme mit Compositing Window Manager hat (siehe xVideo) wurde mit X.Org 7.0 EXA als Übergangslösung bis zum vollständigen 3D Desktop vorgestellt. EXA sollte schlank sein und XRender so gut wie möglich unterstützen. Mittlerweile unterstützen viele Grafiktreiber dieses Modul.
Ganz neu ist UXA, eine EXA Reimplementation , entwickelt von Intel & Tungsten Graphics, unter Zuhilfenahme von GEM.

nVIDIA unterstützt defaultmässig direkt die hardwarebeschleunigung der XRender Extension und damit die 2D Befehle.

X Video extension (Xv/XVideo)

Video Ausgabe Mechanismus des X-Window Sytems. Haupt Usecase ist die Skalierung von Videowiedergabe in der Video Controller Hardware, bspw. für Vollbilddarstellung.
Wenn allerdings die Compositing Erweiterung des Window Managers eingestellt ist, werden Programme die Xv in Kombination mit XAA benutzen –  wie VLC – sofort mit folgender Meldung terminieren:

X11 error: BadAlloc (insufficient resources for operation)

Grund dafür ist, dass der XAA Beschleuniger kein Mechanismus beherscht um Pixmaps vom Systemspeicher in das Video RAM zu laden.

X Resize and Rotate Extension (XRandR)

Erlaubt es X clients dynamisch X Screens zu vergrößern/verkleinern und zu rotieren. Generell geht es darum die Display Charakteristik zu verändern, ohne den xserver neu starten zu müssen.
XRandR unterstützt (derzeit) nicht Multi-Screens, bei denen ein WindowManager mehrere Screens verwaltet, die allerdings nicht durchgängig sind. Xinerama Mode wird dagegen unterstützt. Bei diesem Mode spannen mehrere Monitore einen grossen virtuellen Screen auf. Dieser Mode heisst bei nVIDIA TwinView und kann über das nVIDIA eigene Setting Tool angewählt werden.
Da Xinerama/TwinView einen grossen virtuellen Screen aufspannt, benötigt man dadurch wesentlich mehr VRAM. Auch wenn die Menge an verfügbarem VRAM stark gestiegen ist, muss man sich im klaren sein, dass bei eingeschaltetem Antialiasing der Memory sehr schnell ausgeschöpft sein wird (siehe Full Screen Antialiasing)

XRandR lag lange Zeit in Version 1.2 vor und wurde mit xserver 1.6 auf Version 1.3 upgedatet. Neu ist u.a. das Panning Feature.
XRandr lässt sich mit dem gleichnamigen (kleinschreibung beachten) Kommandotool bedienen. Ein Generisches GUI oder die Integration in die bekannten Desktop Systeme – Gnome und KDE – lässt auf sich warten. Einzelne Features lassen sich aus GPU Settings Applikationen der Hersteller bedienen, so bspw. TwinView mittels nvidia-settings.

X Input Extension

Zuständig für Einrichtung und Abfrage von Eingabegeräten. Mit xserver 1.6 wurde X Input 1.5 vorgestellt, welches neben Vereinfachungen auch Predictable Pointer Acceleration einführt, welches verbesserte und beschleunigte Darstellung des Mauszeigers bietet.

Gallium 3D

Eines der vielversprechendsten Projekte innerhalb des X-Window System seit langen. Unter der Federführung von Tungsten Graphics, welche im Auftrag von Intel deren Grafiktreiber erstellt, entsteht langfristig ein neuer Layer anstatt der MESA<->DRI Kombination.

Das Gallium API kann als Input unterschiedliche Grafikbibliotheken – OpenGL, Direct3D.. – verarbeiten und hat nur noch ein backend, den sog. State Tracker.
Grafikkartentreiber müssen nur noch diesen State-Tracker verarbeiten – bisher muss für jeden Grafikkartentreiber ein angepasstes mesa-DRI Modul geschrieben werden. Zudem benutzt Gallium3D unter Linux auch das Kernel Memory Management – GEM – wobei Gallium selber plattformneutral ist.
Mit einem dummy-Treiber lassen sich sogar Ergebnisse von nicht vorhandener GPU-Hardware simulieren.
Ob dieses Modul tatsächlich in den Produktiveinsatz kommt und ev. sogar über die Grenzen von X.Org/Linux sich durchsetzt kann derzeit noch nicht abgeschätzt werden.

Kernel Mode Settings

Dies ist die Bestrebung die bisher im Userland des xservers angesiedelten Modecodes in den Linux Kernel zu transferieren.
Neben der wiederholten Redundanzvermeidung wird es substantielle Verbesserungen geben:

• Verbesserte (oder erstmals verlässlich eingeführte) Unterstützung für Suspend und Resume
• Verlässliches Virtual Terminal (VT) Switching
• Flickerfreies booten / einloggen in die Desktop Umgebung

Diese Featureset wird seit Kernel 2.6.29 angeboten und wird erstmals von der Intel Treiber Serie 2.6.x genutzt (Einstellungsmöglichkeit)

X.Org erlebt derzeit seine aufregendste – der Enduser eventuell seine nervigste – Zeit. Probleme gibt es derzeit mit

• Instabilität des Intel Treiber 2.6 mit UXA
• Ring of Death Probleme des Intel Treibers 2.x mit X.Org 7.4 und EXA
• nVIDIA’s 2D Beschleunigung unter Composite Window Manager
• Generell 3D Performance auf Composite Window Manager

Sollten sich die Beteiligten nicht irrational verhalten, wird X.Org wahrscheinlich als bestes Window System auf dem gesamten Desktop Markt hervorgehen.

Als ich einige Sondertasten auf meiner Cherry Marlin Tastatur unter Linux zum Laufen kriegen wollte, merkte ich erst dass auch dieses Modell Out-Of-The-Box unterstützt wird. Mann muss dazu aus dem Tastaturauswahlmenü (KDE,Gnome oder auch YaST...) das Modell

Cherry Blue Line CyBo@ard (alternate option)

anwählen, dann sind alle Sondertasten vorhanden und können auf bestimmte Aktionen gemappt werden.

Hintergrund sind für die Marlin Tastatur passende Einträge in der Datei

/usr/share/X11/xkb/symbols/inet 

 // Cherry Blue Line CyBo@rd (alternate option)
partial alphanumeric_keys
xkb_symbols "cherrybluea" {
    include "inet(media_nav_common)"
    key <I21>   {       [ XF86Calculator        ]       };
    key <I32>   {       [ XF86HomePage          ]       };
    key <I5F>   {       [ XF86Standby           ]       };
    key <I6C>   {       [ XF86Mail              ]       };
    ....

Diese Internetkeys sind hexadezimal kodierte Werte (nach dem I) welche sich aus dem keycode der Taste (mit xev ermittelbar) – 128 ergeben.

Beide Filesysteme sind virtuelle in-memory Filesysteme (siehe mount Kommando), die den Status des Systems reflektieren.

 /sys ist das neuere der beiden und ist mit Kernel 2.6 eingeführt worden. Ursprünglich nur gedacht um eine Geräteabbildung für Powermanagement Systeme zu bieten, wurde sysfs zum universellen Abbild von kobject Instanzen, dem Herz des Kernel 2.6 Devicemodels.

 /sys bietet eine saubere Hierachie, auf dem heute schon alle Powermanagement relevanten Programme aufbauen und wird sukzessive /proc ablösen. Es ist vom Userspace erreichbar und verspricht Kontinuität.

/proc ist ein eher unstrukturiertes Verzeichnis in dem sich allemöglichen Informationen bzgl. Prozessen und Geräte befindet. Im Gerätebereich hingegen werden Informationen sukzessive im Hinblick auf /sys verschwinden (so schon geschehen mit ACPI und USB Infos).

Wichtig hingegen ist immer noch /proc/sys – ausgehenden von diesem Basisverzeichnis lassen sich alle darunterliegenden Kernelparameter mit dem sysctl Kommando verändern.

Dieses Kommando darf man allerdings nicht mit dem Systemcall sysctl verwechseln, welches unter Linux auf der Abschussliste steht, da die Wartung quasi nicht mehr möglich ist und die Verwendung wohl gegen Null tendiert.

Der Fortschritt des KDE Projektes ist unverkennbar. Mit der neuesten Minor-Release 4.2 wurden viele Ecken geschliffen, Probleme gelöst und unter anderem das neue Powermanagement System powerdevil etabliert.

Um es mal ganz deutlich zu sagen: KDE 4.2 ist optisch das beste was es gerade auf dem Desktop Markt gibt – durch seine Konfigurationsmöglichkeiten übertrifft es Mac OS X Leopard, auch wenn das Problem der Grundkonfiguration seitens der Distributoren noch nicht gegessen ist.

Der Snapshot zeigt schon einige Highlights. Das Dashboard mit den sog. Plasma Widgets ist immer sicht- und bedienbar – nicht nur bei Aktivierung. Die Konsole ist transparent, das Rendering der Windows streichelt die Augen. Eine Aufzählung der KDE Windows Manager Eigenschaften sprengt aber den Rahmen..

..vor allem weil ich über das neue Powermanagement System sprechen wollte.

Hier der Basiseinstellungsdialog mit 2 Profile, die ich anlegen musste: Akku und Performance.

Im Bereich Profile ändern, stellt man Verhaltenswerte der Profile ein, bspw. die Helligkeit des Monitors…

.. kann aber auch bei Aktivierung des Profils – z.B. durch ziehen des Steckers – eigene Skripte auslösen.

Dies nutzte ich um einige Page Cache Werte anzupassen. Die Anregung dafür gaben mir die on-the-fly Tipps der powertop Ausgabe. Die Problematik diese Werte umzustellen lassen ist, dass Sie die Kernelkonfiguration zur Laufzeit betreffen und diese Änderungen nur von root vorgenommen werden können. Ein Shell Skript darf zudem nicht mit dem suid Bit markiert werden, so dass der billigste Trick nicht greift!

Die Lösung ist, dass ich ein Skript im Homeverzeichnis des Users anlegte, welches mit sudo das eigentlich Skript aufruft. Mit visudo gab ich dem User die Rechte dies zu tun. Die drei erforderlichen Einträge lauten folgendermassen:

1. Das Skript im User Home Verzeichnis

(für Akku Profil)

#!/bin/bash

sudo /usr/local/bin/sys_akku.sh

(für Performance Profile)

 #!/bin/bash

sudo /usr/local/bin/sys_performance.sh

2. Das Kernel Steuerungsskript

(für Akku Profile)

#!/bin/bash
/sbin/sysctl vm.dirty_writeback_centisecs=6000
/sbin/sysctl vm.dirty_expire_centisecs=6000
/sbin/sysctl vm.laptop_mode=1

(für Performance Profil)

 #!/bin/bash
/sbin/sysctl vm.dirty_writeback_centisecs=500
/sbin/sysctl vm.dirty_expire_centisecs=3000
/sbin/sysctl vm.laptop_mode=0

3. visudo Einträge

SETANYUSERHERE ALL=NOPASSWD:/usr/local/bin/sys_akku.sh
SETANYUSERHERE ALL=NOPASSWD:/usr/local/bin/sys_performance.sh

Die Werte sind ev. noch nicht optimal, ergeben aber bei powertop Messungen verbesserte Laufzeiten.

Habt Spass!