X Server mag meinen R52 nicht (mehr)

worel

Well-Known Member
Hi!

Hatte auf meinem IBM R52 dazumals FreeBSD 6.2 mit der damaligen Paketversion von Xorg drauf. (weiß jetzt ned mehr was das für ne version war)
Schön und gut, klappte wunderbar, Maus, Tastatur sowie die eingebaute Radeon M300 wurden per firegl treiber angesprochen.

Jetzt habe ich nach längerem wieder FreeBSD, diesmal 7.1 mit der xorg version aus den ports (7.4) installiert. Jo, xorgconfig durchgejagt, zuerst mal mit dem vesa treiber gestartet. Keine Maus, keine Tastatur. Hm. In der Konsole klappt alles prima, sowohl maus als auch tastatur. Dann "x -configure" probiert. Tatsächlich schreibt er mir ein xorg.config file. Das schaut auch plausibel aus, es wird auch der radeon treiber reingeschrieben. Nur mit diesem automatisch generiertem File kommt nix außer schwarz. Muss die Kiste dann immer abwürgen, nichts geht mehr.

Versteh es nicht, mit 6.2 lief alles super, leider hab ich die alte Config nicht mehr. Und jetzt klappt abgesehen vom radeon treiber für die M300 (ist der firegl Treiber gekickt worden?) zusätzlich ned mal mehr maus und tastatur unter vesa...

Wo setz ich da an?
 
Da scheint hal die Finger im Spiel zu haben.

Hast du diesen Thread Xorg 7.4 in den Ports schon gründlich studiert?

Bei mir ist es aktuell immer noch so, dass ich X nur einmal starten kann, bei 2. Mal friert das System komplett ein.

mousaka
 
Hab mir den Fred jetzt mal im Schnelldurchlauf angesehen.
Blöde Frage, aber warum macht man sowas, diese heftigen Änderungen?
Bringt das irgendwem etwas?

Naja, hilft nix...
 
Das Problem war/ist, dass der Portstree von August bis Dezember (oder so ähnlich) im Slush-Status war und darum mehrere grosse Änderungen (KDE 4.2, Xorg 7.4, ... ) verzögert wurden. Jetzt wird mit Nachdruck der Rückstand aufgeholt und vielleicht so massive Änderungen etwas voreilig freigeschaltet.

Besonders im Falle von Xorg 7.4 zeigt sich aber auch, dass einige Unix-Applikationen vorallem für Linux entwickelt werden und ander Unix-Derivate eher zu kurz kommen (Stichwort hal). Ausserdem ist es meist ein Teufelskreis, dass Software die noch nicht im offiziellen Ports-Baum ist, zu wenig Tester findet, so dass wiederum die Qualität darunter leidet und einige (schlimme) Fehler darum erst (zu) spät entdeckt werden.
In letzten Punkt kann ich mich selbst auch an der Nase nehmen.;)

mousaka
 
Last edited:
ich denke auch, daß da ausreichend lamentiert wurde und kann auch nicht verstehen, wieso man sich da dermaßen auf Hal stützt und es einem damit ja beinahe aufzwingt. Für mich war der stets eine nette Nebensache, so ein wenig ein Spielzeug, das aber auch nicht zu sein brauchte. Nun Wird so getan, als sei er ausgereift, funktionsbereit und weit verbreitet, ja, gerne gesehen.
Wie auch immer.

Mein Vorschlag bei deinem Fehler ist aber, erst mal die Fehlermeldungen des X-Servers anzusehen. DIe solltest du bei Versagen erhalten und auch in der /var/log/Xorg.(nummer).log nachlesen können. Erst hierdurch kannst du sehen, was dein Xserver nicht wollte. Manche Dinge darfst du auch ignorieren.
pit@syo ~:-> grep EE /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(II) Loading extension MIT-SCREEN-SAVER
(EE) RADEONHD(0): RHDHdmiInit: unknown HDMI output type
(EE) config/hal: couldn't initialise context: (null) ((null))
(EE) USB-Keyboard: cannot open "/dev/ukbd0"
(EE) PreInit failed for input device "USB-Keyboard"
(EE) config/hal: NewInputDeviceRequest failed
(EE) USB-Keyboard: cannot open "/dev/ukbd0"
(EE) PreInit failed for input device "USB-Keyboard"
(EE) config/hal: NewInputDeviceRequest failed
zeigt etwa solche EE-Einträge bei mir, die ich ignoriern kann, weil ja scheinbar alles geht (außer vielleicht KDE42).
Es kann nämlich gut sein, daß dein X-Servr sehr wohl funktioniert und läuft, nur ein Bild erzeugt, das eine Auflösung hat, die dein Monitor nicht leistet und dieser deshalb einfach dunkel schaltet. Da könnte es dann schon genügen, eine geeignete Einstellung zu finden.
 
Was mich verwundert ist, wozu eine Abstraktionsschicht gut ist, wenn sie bloß eine Plattform unterstützt. Denn sein wir mal ehrlich, HAL unter FreeBSD ist ein Haufen Mist. Auf meinem System macht es komische Dinge im CAM-Layer, die eine sofortige Panic auslösen. Alles andere funktioniert auch nicht gerade prickelnd.

Ist es nicht normalerweise das Ziel von Abstraktion mehrere unterliegende Schichten zu verdecken um sie einheitlich unterstützen zu können? Nun. HAL ist nur mit dem Linux-Kernel tauglich. X könnte also genauso gut direkt mit dem Linux-Kernel reden. Das wäre genau so FreeBSD-kompatibel wie HAL.

Was ist verdammt noch mal das Entwicklungsziel von diesen HAL-Typen?
 
Moin,

Was mich verwundert ist, wozu eine Abstraktionsschicht gut ist, wenn sie bloß eine Plattform unterstützt. Denn sein wir mal ehrlich, HAL unter FreeBSD ist ein Haufen Mist. Auf meinem System macht es komische Dinge im CAM-Layer, die eine sofortige Panic auslösen. Alles andere funktioniert auch nicht gerade prickelnd.

Ist es nicht normalerweise das Ziel von Abstraktion mehrere unterliegende Schichten zu verdecken um sie einheitlich unterstützen zu können? Nun. HAL ist nur mit dem Linux-Kernel tauglich. X könnte also genauso gut direkt mit dem Linux-Kernel reden. Das wäre genau so FreeBSD-kompatibel wie HAL.

Was ist verdammt noch mal das Entwicklungsziel von diesen HAL-Typen?

War es nicht einmal das Ziel der POSIX-Schnittstelle, eine Betriebssystem unabhängige Ebene einzuziehen? Ich verstehe angesichts eben dieser POSIX-Schnittstelle die Einführung von HAL (und DBUS und Policy) überhaupt nicht.

Kein Wunder, dass die Applikationen immer weiter aufgeblasen werden und immer schlechter funktionieren (Gnome-Evolution kann nicht richtig mit IMAP4 und LDAP umgehen).
Hoffentlich versteigen sich die Entwickler nicht mal dazu, System-Daemonen von HAL abhängig zu machen.

Wahrscheinlich wollen die Linux-Jünger der UNIX-Welt zeigen, was in ihnen steckt...

Viele Grüße

JueDan
 
Ich unternehme den Versuch meinem Unmut an einem anderen Ort Luft zu machen. http://forums.freebsd.org/showthread.php?t=2289

Ich habe mich dort immer wieder über Linux-bashing beschwert, aber für HAL-bashing bin ich jederzeit zu haben. Ich frage mich wie das Zeug mein System zu 'ner Panic bringt, es hat überhaupt nicht die Zugriffsrechte, ich hab's mit su -m haldaemon ausprobiert.
 
das HAL Dilemma ergibt sich vielleicht wirklich aus dem Linux Dilemma direkt. Ich weiß nicht, ob ich das jeweils richtig verstanden habe, denn ich kenne mich nicht gut genug aus damit, aber ich sehe die Entwicklung nun ja schon eine ganze Zeit lang und daraus ergibt sich für mich ein Bild.

Der Kernel abstrahiert grundsätzlich die Hardware.
Nicht jedoch bei der Grafik. Hier wird der Grundsatz schon für den X-Server aufgeweicht, der ja die Graka direkt angeht.
Der X-Server greift auf zusätzliche Geräte zu, die grundsätzlich wieder durch den Systemkern abstrahiert werden. Dazu wird ein Eintrag in einer /dev vorgenommen.
Linux nahm einen /proc auf, der von plan9 inspiriert ist. FreeBSD kann auch einen /proc, der aber ist unterschiedlich zu dem Linux /proc und in Linux ist er auch nicht einheitlich sondern abhängig von Kernelversion und System. Die /dev unter einem Linux geriet durch vorbelegte Einträge zu einem unüberschaubaren und nicht zu regelnden Gewächs. Im /proc konnten tatsächliche Ereignisse ausgelesen werden. Die eigentliche /dev wurde durch ein udev ergänzt, was vielleicht mal hätte Ordnung bringen können, doch weil viele vieles anders machten, schwebt das noch immer.
So hat ein Linux schon mehere Systeme, die Rückmeldungen zu den Geräten und Systemprozessen liefern. Unterschiedliche Programme nutzen das unterschiedlich. Man könnte auch sagen: ein ziemliches Durcheinander!
Hier war eine Idee, dieses zu vereinheitlichen und vielleicht auch andere Unixe in einen gleichen Rahmen zu führen, vielleicht angebracht. Hal ist ein Dämon, der alles andere als einfach funktioniert und die komplette Abstraktion des Systemes über ein hochkomplexes Melde- und Leitungssystem realisieren will. Ich habe das nie wirklich verstanden, was die machen, aber die nutzen auch dbus und die policityKit und die wieder auch die consoleKit. Einmal werden eine Art .conf genommen, um Geräte zu klassifizieren und Ereignisse zu bestimmen, dann werden die Dienste genutzt, diese Geräte zu erkennen und zu behandeln und dem System wieder bekannt zu machen. Hal sieht also nicht in der /proc direkt nach, es braucht diesen /proc aber scheinbar auch. Linux und FreeBSD und vermutlich alle anderen Systeme auch unterscheiden sich hier und so muß es entweder für jedes System einen unterschiedlichen Hal geben, oder die .confes müssen alles enthalten und richtig zuweisen, eben abstrahieren. Hal pflegt Einträge für alles, für das komplette System und alle Geräte und es kommt im Grunde genommen der Idee des /proc sehr nahe, leider aber auf recht undurchsichtige Weise. Es ist nun ein System, das neben und über den anderen, etablierten Meldesystemen liegt und für zusätzliche Verwirrung sorgen kann.
Mein Eindruck ist, daß die Hal Leute tatsächlich nur eine bestimmte Linux-Distribution nutzen und ihr System hier wirklich testen. Es wäre auch eine wirklich sehr große Anstrengung, den Hal tatsächlich an alle Systeme anzupassen.

Es ist aber doch absolut unvernünftig, wenn sich nun die X-Server Leute auf solch ein System verlassen, das ganz eindeutig gar nicht für die unterschiedlichen Plattformen funktioniert, auf denen ihr X laufen soll.
Daß dabei FreeBSD noch ganz gut wegkommt, kann jeder in den .confes (man verzeihe, daß ich die richtigen Namen immer vergesse) gesehen werden: hier gibt es sehr oft Einträge für Linux und FreeBSD, also für nichts anderes! Das zeigt ja wohl schon, daß nicht alle Systeme auf Hal setzen können.
 
Hallo,

warum einfach, wenn kompliziert auch geht...

Der Kernel abstrahiert grundsätzlich die Hardware.
Nicht jedoch bei der Grafik. Hier wird der Grundsatz schon für den X-Server aufgeweicht, der ja die Graka direkt angeht.
Der X-Server greift auf zusätzliche Geräte zu, die grundsätzlich wieder durch den Systemkern abstrahiert werden. Dazu wird ein Eintrag in einer /dev vorgenommen.
Da stellen sich mir - wahrscheinlich anderen auch - aber sofort folgende Fragen:
(*) Bis XOrg 7.3 funktionierte es auch ohne hal. Warum?
(*) Jeder Kernel stellt einen Maus-, Tastaturtreiber und einen Treiber für den direkten Hardware-Zugriff zur Verfügung. Diese Treiber lassen sich doch einfach in xorg.conf eintragen oder abhängig vom Betriebssystem hart kodieren. Wieso nutzt man das nicht?

Linux nahm einen /proc auf, der von plan9 inspiriert ist. FreeBSD kann auch einen /proc, der aber ist unterschiedlich zu dem Linux /proc und in Linux ist er auch nicht einheitlich sondern abhängig von Kernelversion und System. Die /dev unter einem Linux geriet durch vorbelegte Einträge zu einem unüberschaubaren und nicht zu regelnden Gewächs. Im /proc konnten tatsächliche Ereignisse ausgelesen werden. Die eigentliche /dev wurde durch ein udev ergänzt, was vielleicht mal hätte Ordnung bringen können, doch weil viele vieles anders machten, schwebt das noch immer.
So hat ein Linux schon mehere Systeme, die Rückmeldungen zu den Geräten und Systemprozessen liefern. Unterschiedliche Programme nutzen das unterschiedlich. Man könnte auch sagen: ein ziemliches Durcheinander!
Hier war eine Idee, dieses zu vereinheitlichen und vielleicht auch andere Unixe in einen gleichen Rahmen zu führen, vielleicht angebracht.

Dann sollen die "Linuxer" erstmal ihren Saustall aufräumen und nicht versuchen, den anderen UNIXen ihren Stempel aufzudrücken.
Das ganze riecht für mich danach: Wir Linux-Entwickler als Maß der Dinge haben das so gebaut, der Rest der Welt hat uns zu folgen.

JueDan

PS: Das soll kein Bashing sein, sondern einfach nur Kritik
 
Die Zeit für konstruktive Kritik ist vorbei. Hier ist blinder, wütender Zorn angesagt. Der zweck von HAL ist X auf allen Plattformen außer Linux unbenutzbar zu machen.
 
Um nicht falsch verstanden zu werden: an anderer Stelle habe ich mich fast wortwörtlich so geäußert, wie ihr das hier auch von euch gebt und beschreibt. Es ist keineswegs etwa so, daß ich diese Entwicklung gut heißen möchte.
Es erscheint mir lediglich aus meinem Blinkwinkel plausibel, daß Linuxer so auf Hal und Konsorten abfahren. Die können so was brauchen. Und die Entwicklungsgeschichte an sich scheint mir nahezu symptomatisch für das Geschehen in OpenSource und deshalb auch tolerabel. Jedenfalls so lange, wie es dabei um ein Spielzeug geht, das man haben kann, aber nicht haben muß.
Die X-Server Leute machen meiner Meinung nach hier einen Fehler und leider scheint es mir so, daß ich sagen möchte: wieder mal!
Der X-Server soll doch niemals Plattformspezifisch geraten. Immerhin gibt es sogar X-Server für Microsoft Systeme und es ist keine Frage, daß es heute eine der systemübergreifenden Grundanwendungen überhaupt darstellt, vielleicht vergleichbar mit einem TCP/IP Stack. Stell dir vor, ifconfig würde erst mal bei Hal nachfragen müssen (durchaus gar nicht so weit hergeholt, dieses Beispiel).
Also, selbst mit einem funktionierenden Hal, würde ich diese Entwicklung derzeit unglücklich finden.

Vielleicht aber auch eine andere Sicht.
Wenn ein Kernel die Abstraktion der HW nicht leistet, kann doch ein allgemein verfügbarer HAL durchaus an Sinn gewinnen?
Ich halte davon immer noch nichts, denn ich bin Anhänger von OpenSource und denke, daß ladbare Module einen Kernel erweitern und diese Module alle Information über die Hardware beinhalten sollten und daß es bei Bedarf auch möglich sein muß, diese Module in den Kernel direkt zu kompilieren (also nicht ladbar). Ob dies immer alles offen bleiben muß, ist dabei eine andere Frage, aber ich halte das für eine gute Technik und sehe, anders als viele anderen, keine Notwendigkeit für andere Modelle.
Die schönsten Theorien über Verwendung von reinen Microkerneln laufen allerdings ein wenig anders und verlangen dann Systeme, die dem Kernel helfen die passenden Module zu finden und zu laden und dies nicht als eigentlichen Kernprozess auszubilden.
Hal ist dafür nicht geeignet, aber vielleicht ein Ansatz?

Wie gesagt, ich sehe einen groben Fehler bei den X-Server Leuten und versuche nur, die Wut nicht gegen die Hal-Leute aufwallen zu lassen, die eher weniger verantwortlich für solche Entscheidungen sind.
Ich sehe das allerdings auch so, weil es in der Vergangenheit schon mehrfach ein Verhalten der X-Leute gab, das in eine weniger tragbare Richtung zielte. Manchmal denke ich, die Entwicklung zu Xorg hat nicht viel gutes gebracht.

Nebenbei: KDE42 sehe ich auch in diesem Licht. Es setzt voll auf neue Möglichkeiten von X und auf einen laufenden Hal. Mir gefällt diese Entwicklung einfach nicht. Schade, daß ich nicht besser darüber bescheid weiß und kompetenter dagegen anstänkern kann.
 
Es ist nicht nur HAL. Ich möchte hier nicht den nächsten Ausraster über X.org bekommen, denn mein Herz kann das bald nicht mehr ab. Aber HAL ist nur ein Symptom, nicht die Ursache. Irgendwann im letzten Jahr hatten die Jungs vom X.org eine Idee. Sie wollten dem System erlauben mehrere Zeigegeräte parallel zu verwenden, oder anders gesagt, verschiedenen, voneinander unabhängige Mauszeiger, welche auch verschiedene Fenster im Fokus halten können und so. Ob das nun sinnvoll ist oder nicht, wollen wir hier nicht diskutieren. Im gleichen Schritt wollten sie die Funktionalität einbauen, dass man Eingabegeräte zur Laufzeit von X.org einstecken kann und das Ding nicht neu starten muss. Ähnlich wie es schon dank randr - wenn es denn mal funktioniert, was es hier auf einem Rechner sogar tut - schon mit Monitoren geht. Daran war starker Druck durch die Ubuntu-Suse-Connection (also die großen Desktop-Distros) schuld. Diese finden, sie können dem Standard-DAU nicht erklären, dass X.org nur eine Anwendung ist und man diese für Änderungen an der Umgebung halt neu starten muss. Unter FreeBSD waren diese Neustarts übrigens nie nötig, man kann dank kbdmux(4) und moused(1) schon seit Jahren Geräte einstecken und sie funktionieren einfach. Auch mehrere Tastaturen und Mäuse parallel. Linux allerdings hat solche Mechanismen leider nur in Form besserer, meist nicht funktionierender Hacks.

Also begann man zu entwicklen - man mag es auch als "frickeln" zu bezeichnen - und das Ergebnis war evdev. evdev ist ein Eingabetreiber für X.org, welcher es erlaubt im Betrieb EIngabegeräte hinzuzufügen, auch wenn das Betriebssystem darunter diese nicht eingenständig mischt. Auch kann man mit ihm mehrere Mauszeiger haben, wie oben erklärt. Simpel gesagt ersetzt evdev also xf86-input-keyboard und xf86-input-mouse. Leider hat Linux nun nur inotify, durch welches man nicht erkennen kann, ob Geräte angeschlossen wurden oder nicht. FreeBSD und OS X implementieren diese Funktionalität als ein Teil von kqueue(2). An diesem Punkt kommt HAL in das Spiel. HAL pollt(!) auf /dev/input/*, in /proc und in /sys. Sobald ein Gerät angeschlossen wird, tauchen da durch udev erstellt die Devicenodes auf. udev ist auch so ein Thema, wo man nur den Kopf schüttelt, aber darüber will ich mich nun nicht aufregen. HAL erkennt diese Devicenodes und teilt es seinen Konsumenten mit. Das ist auch evdev in X.org. Der saugt das Gerät ein und es funktioniert. Theoretisch

Einmal davon abgesehen, das weder wir FreeBSDler, noch Solaris und auch (fast) alle anderen Unixe diesen Hack mit HAL brauchen, gewinnen wir auch sonst nichts. Denn evdev arbeitet auf dem Linuxisms /dev/input/, wo jedes Eingabegerät ca. 5 Devicenodes erstellt, deren Ausgaben im Userland verrührt werden müssen. Auf /proc, auf /sys und was weiß ich sonst noch wo. Kurz um, evdev ist nicht portabel. Wir dürfen den Fallout in Form von HAL durchleiden, aber auf der anderen Seite schneiden uns die X.org-Frickler durch ihre Linuxzentriertheit von den daraus resultierenden Verbesserungen(?) ab. Gleiche Entwicklungen sind in immer mehr Bereichen zu sehen, begonnen beim ekligen "Kernel Mode Setting" - warum muss der Kernel die Auflösungen der Grafikkarte für X.org umschalten können? Das widerspricht so ziemlich vollständig der Idee hinter Unix. Wenn X.org ein Anwendungsprogramm ist, soll es das gefälligst selbst machen, tat es due letzten 25 Jahre ja auch. Und aufhören tut es beim Dbus. Warum noch ein (nicht wirklich funktionierendes) IPC-Framework, fischig oben auf das System raufgeklatscht?
 
Vielleicht eine dumme Frage:
Die FreeBSD-Foundation ist doch auf der Suche noch Projekten die finanziell unterstützt werden sollen, falls sie für das Projekt wichtig sind.
Ich weiss aber zu wenig, um abzuschätzen, in wie weit sich mit bezahlter manpower eine Lösung finden lässt. Jemand finden müsste man auch noch.

In meinen Augen erfordert die aktuelle Situation ein Eingreifen seitens des FreeBSD-Projekts, da es wohl kaum Anstrengungen von den Entwicklern von Xorg oder hal etc. geben wird die aktuellen Umstände zu ändern.

Eine gut funktionierende graphische Oberfläche gehört imho auh zu einem soldien Betriebssystem, selbst wenn es den Schwerpunkt auf die Server-Seite legen will.

mousaka
 
Moin,

Daran war starker Druck durch die Ubuntu-Suse-Connection (also die großen Desktop-Distros) schuld. Diese finden, sie können dem Standard-DAU nicht erklären, dass X.org nur eine Anwendung ist und man diese für Änderungen an der Umgebung halt neu starten muss. Unter FreeBSD waren diese Neustarts übrigens nie nötig, man kann dank kbdmux(4) und moused(1) schon seit Jahren Geräte einstecken und sie funktionieren einfach. Auch mehrere Tastaturen und Mäuse parallel. Linux allerdings hat solche Mechanismen leider nur in Form besserer, meist nicht funktionierender Hacks.
Dann frage ich mich, warum die anderen Distributionen wie RedHat und Mandriva usw. oder die anderen Unixe hier nicht interveniert haben. Schließlich sind Ubuntu und Suse nicht das Maß der Dinge, auch nicht in der Linux-Welt.

... [Beschreibung HAL, evdev] ...

Oh mein Gott...:eek:

Einmal davon abgesehen, das weder wir FreeBSDler, noch Solaris und auch (fast) alle anderen Unixe diesen Hack mit HAL brauchen, gewinnen wir auch sonst nichts. [...] Wir dürfen den Fallout in Form von HAL durchleiden, aber auf der anderen Seite schneiden uns die X.org-Frickler durch ihre Linuxzentriertheit von den daraus resultierenden Verbesserungen(?) ab.
Da kann ich beim besten Willen keine Verbesserungen erkennen. :)

Gleiche Entwicklungen sind in immer mehr Bereichen zu sehen, begonnen beim ekligen "Kernel Mode Setting" - warum muss der Kernel die Auflösungen der Grafikkarte für X.org umschalten können? Das widerspricht so ziemlich vollständig der Idee hinter Unix.

Linux entwickelt sich immer zu einem Windows: Der gleiche Saustall, die gleichen Probleme, Lizenz-Abartigkeiten (keine Diskussion darüber!) usw.

Wenn X.org ein Anwendungsprogramm ist, soll es das gefälligst selbst machen, tat es due letzten 25 Jahre ja auch. Und aufhören tut es beim Dbus. Warum noch ein (nicht wirklich funktionierendes) IPC-Framework, fischig oben auf das System raufgeklatscht?

Viele Linux-Entwickler - ich verallgemeinere hier der Einfachheit mal - haben POSIX nicht verstanden, so scheint es mir.

Mal so eine Idee - ich weiß nicht, ob es möglich ist:
Wie weit sind eigentlich XFree86 und XOrg vom Entwicklungsstand auseinander? Ist es nicht möglich im Rahmen der FreeBSD-Foundation und/oder Google - Summer of Code ein Projekt anzustoßen, welches XFree wieder in *BSD und Solaris integriert?

Viele Grüße

JueDan
 
Naja, Red Hat ist an der X Foundation meines Wissens nach beteiligt. Sie sind also sicherlich nicht unschuldig. Die anderen Linuxe ganz sicher auch nicht. Aber es sind Suse und Ubuntu, die man in Sachen Desktop-Krams immer an forderster Front sieht und die sich für den "Eyecandy" und die Automagie einsetzen. Die anderen sind eher Nutznießer, welche ihren Vorteil daraus ziehen aber nicht direkt die treibenden Kräfte sind. Woher der Wind bläßt ließ sich recht gut am Kurztest von Heise von Debian 5 erkennen. Ich gebe zu, ich mag persönlich Debian nicht sonderlich (keine Diskussion!), aber es ist hier ein gutes Beispiel. Als eher konservatives Linux hat es auch einen konservativen Desktop, der aber einfach funktioniert. Wenig Klickibunti, nicht den allerneusten, eh nur halb funktionierenden Kram. Was ist das Ende von Lied? Es wird darauf rumgehakt, wie altbacken Debian doch ist und wie ungeeignet für den Desktopeinsatz. Daran erkennt man, selbst wenn Red Hat und co. die aktuellen Entwicklungen nicht gutheißen mögen, sie können sich nicht dagegen stellen, außer sie wollen in die Ecke der sehr konservativen Distros gerückt werden.

Sie sind nicht so weit auseinander, wie man denken mag. X.org hat an den Grundlagen des Systems kaum was geändert, sie eher kaputt gemacht anstatt sie zu verbessern. XFree86 hat weitgehend unbeachtet von der Welt die Treiber immer aktuell auf dem gleichen Stand wie X.org gehalten, sinnvolle Neuerungen übernommen und selbst weiterentwickelt. Kurz gesagt ist XFree86 ein X.org ohne den ganzen kaputtgefrickelten Krams und es baut nach wie vor weitgehend problemlos unter FreeBSD. Leider integriert es nicht mehr mit den Ports. Der Weg zurück oder wenigstens XFree86 parallel zu X.org ist recht simpel, wenn man den EInbau in das Portframework mal rauslässt. Leider sind da zwei Probleme. Einmal die beknackte Lizenz, die uns den ganzen Ärger erst eingebrockt hat. Und dann die Gefahr, dass XFree86 durch fehlende Manpower (es sind nicht viele Entwickler übrig) und andere Designziele in absehbarer Zeit völlig inkompatibel zu X.org sein wird. X.org entwickelt sich nämlich immer mehr in Richtung X12R1, was sich aber in der Versionsnummer leider nicht wiederspiegelt. Stabile ABIs sind in der Linuxwelt bekanntlich nicht gern gesehen, man sieht in ihnen einen Nachteil... Dinge wie die Compositemanager, EXA Beschleunigung, DRI2 und so wird es XFree86 nie geben und sobald sie durch Anwendungen vorausgesetzt werden (KDE 4 tut das teilweise sogar schon, meine ich) ist der Hahn zugedreht.

EDIT: Für FreeBSD 2.2(!) bis 7 liegt XFree86 sogar in fertigen Paketen auf dem FTP-Server - ftp://ftp.xfree86.org/pub/XFree86/4.8.0/binaries/
 
Last edited:
Diese Diskussion müsste eigentlich in einem internationalen Forum geführt werden. Ich bin dafür, dass wir das mal wieder auf die Mailingliste geben. Auch wenn das beim letzten mal viel Ärger gemacht hat, es hat doch etwas bewegt und mit FreeBSD 7.1 haben wir meiner Meinung nach die ersten Früchte geerntet.

Xorg sollte unter FreeBSD auf SysMouse, KBDmux und devd aufbauen um dynamisch Geräte ein- und auszubinden.

Mehrere Mauscursor auf einmal benötigt man eigentlich nur für Multitouch-Anwendungen. Dafür müssen neue Lösungen her meiner Meinung nach, mit Unterstützung für Drucksensitivität. Denn nachdem ich mal so ein IPhone ausprobiert habe, finde ich das Multitouch-Zeug nicht wirklich toll. Der einzige richtige Anwendungszweck den ich sehe sind kooperative Anwendungen an (sehr) großen Bildschirmen. Dann wäre es auch sinnig eine Maus an eine Tastatur zu binden und Multifocus zu unterstützen.

Dieses Pairing sollte aber meiner Meinung nach der Kernel vornehmen, der Erkennen kann, dass die Maus am USB-Port der Tastatur angeschlossen ist. Alternativ müsste man eine Lösung im BlueTooth-Stack finden. Und es sollte ausschließlich manuell einzurichten sein, da es doch eher eine Ausnahmeanwendung ist.
 
Das Problem ist, welche Mailingliste? FreeBSD ist kaum zuständig, da gab es erst einen großen X.org Heulthread über mehrere Listen[1][2] und der allgemeine Tenor ist eher dahingehend, dass man auch nur das verwurstet, was die Drittanbieter liefern. Stimmt ja auch. Man ist selbst darüber sehr frustriert, was X.org abzieht, kann allerdings kaum etwas machen. Außer vielleicht auf X.org verzichten, was aber breiten Teilen der Desktopnutzern kaum zu erklären sein dürfte. Versuchen könnte man es bei X.org selbst. Aber da scheint Robert Noland der einzig vernünftige Mensch zu sein, welcher auch gleichzeitig FreeBSDler ist und daher wiederum die Probleme eh schon kennt.

1: http://lists.freebsd.org/pipermail/freebsd-current/2009-January/002826.html
2: http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/048064.html
 
Dank wscons tuts auch in NetBSD® und Derivaten wunderbar ohne… was bin ich froh,
daß es XFree86® noch gibt.

Aber kernel-based mode switching hat schon einen Reiz… immerhin kann man so dem
X-Server den Hardwarezugriff verbieten bzw. auf reine User-Rechte einschränken… und
wenn man im ddb(4) landet, sieht man was. Eventuell sogar eine bessere Lösung als
ein VESA Framebugger. Fraglich ist nur, mit welchen Karten das dann laufen wird, ob es
Regressionen gibt, und dergleichen.

Aber das ganze glib, GNOME, HAL, dbus, … Geraffels nervt echt, und das obwohl OpenBSD
jemanden im X.org-Board sitzen hat.
 
Hehe, aber die unmöglichkeit der HAL-Config liegt mehr an der Umsetzung als an der Syntax, meiner Meinung nach. Die Leute haben sich echt bemüht es besonders kompliziert und advanced zu machen. freedesktop.org sollte mal nen XML-subset für Configs rausbringen, in dem Nichts bis auf ein, zwei atomare Konstrukte verwendet werden darf. XML an sich ist ja nicht schlecht, nur wenn alle es einfach irgendwie machen bringts keinem Etwas.
 
Back
Top