Xorg 7.4 in den FreeBSD Ports
- Ersteller Kamikaze
- Erstellt am
Ich habe das neue X.org nun auch auf meinem Notebook. Erstmal Danke für die Hinweise von Kamikaze, darüber wurden mir schonmal die einige Ärgernisse erspart (Ich oute mich hiermit als UPDATING-Ignorierer).
Ich habe nun ein Problem: Ich weigere mich, bisher noch weitgehend erfolgreich, in meinen Augen unnötigen Krempel zu installieren. In diese Gruppe gehören für mich auch hal und dbus. Nun stellte ich fest, dass x11-driver/synaptics verschwunden ist, wofür dann x11-driver/xf86-input-synaptics auftauchte. Alleine die Namensänderung wäre mir natürlich vollkommen Wurst, nur bringt der neue synaptics-Treiber eben hal und dbus als Abhängigkeiten mit. Somit habe ich also nun libsynaptics installiert und auf den xf86-input-synaptics verzichtet.
Mein Touchpad funktioniert im grossen und ganzen auch, allerdings kann ich damit nun nicht mehr scrollen. Die EInträge in der xorg.conf sind die selben wie vorher mit dem "alten" synaptics.
Kann ich diese Funktion nun auch ohne hal und dbus akzeptieren zu müssen erhalten, und wenn ja was muss ich hier ändern?
Ach und: Ich bevorzugte bisher den X.org-Synaptics gegenüber dem in FreeBSD vorhandenen Treiber, weil ich zum einen auf dem Notebook immer X starte (und wenn ich doch mal nur die Konsole starte, benötige ich dort keine Maus/Touchpad) und gerne sowohl Touchpad als auch eine externe USB-Maus benutze. Das geht afaik nur über X.org. Ich lasse mich aber gerne korrigieren und belehren.
Ich habe nun ein Problem: Ich weigere mich, bisher noch weitgehend erfolgreich, in meinen Augen unnötigen Krempel zu installieren. In diese Gruppe gehören für mich auch hal und dbus. Nun stellte ich fest, dass x11-driver/synaptics verschwunden ist, wofür dann x11-driver/xf86-input-synaptics auftauchte. Alleine die Namensänderung wäre mir natürlich vollkommen Wurst, nur bringt der neue synaptics-Treiber eben hal und dbus als Abhängigkeiten mit. Somit habe ich also nun libsynaptics installiert und auf den xf86-input-synaptics verzichtet.
Mein Touchpad funktioniert im grossen und ganzen auch, allerdings kann ich damit nun nicht mehr scrollen. Die EInträge in der xorg.conf sind die selben wie vorher mit dem "alten" synaptics.
Kann ich diese Funktion nun auch ohne hal und dbus akzeptieren zu müssen erhalten, und wenn ja was muss ich hier ändern?
Ach und: Ich bevorzugte bisher den X.org-Synaptics gegenüber dem in FreeBSD vorhandenen Treiber, weil ich zum einen auf dem Notebook immer X starte (und wenn ich doch mal nur die Konsole starte, benötige ich dort keine Maus/Touchpad) und gerne sowohl Touchpad als auch eine externe USB-Maus benutze. Das geht afaik nur über X.org. Ich lasse mich aber gerne korrigieren und belehren.
zzz
man zzz
Genau wie ich. Resultat ist ein seit Tagen unbenutzbares weil kaputt-upgedatetes System.
Das kann noch heiter werden.
Genau wie ich. Resultat ist ein seit Tagen unbenutzbares weil kaputt-upgedatetes System.
Das kann noch heiter werden.
Ich installiere meist auf ein vorher sauber geputztes System (update also im grunde nicht wirklich, sondern installiere alle Ports neu), daher habe ich recht selten echte Probleme und ein nicht funktionierendes Scrollen mit dem Touchpad finde ich zwar etwas ärgerlich aber dann doch eher wenig dramatisch.
Bei einem Update des Basissystems gucke ich vorher allerdings doch nach was da auf mich zukommt und was es u.U. zu berücksichtigen gibt.
Nein, das geht prima über sysmouse. Bei dem Touchpad in meinem Notebook, geht das Scrollen über sysmouse out of the box, ohne irgendwelche Einstellungen oder besondere Treiber. Ich vermute, das Pad spielt direkt auf Firmwareebene am rechten Rand Mausrad.
zzz
man zzz
Auf meinem Athlon XP ist das leider nicht so ohne weiteres (bzw. in akzeptabler Zeit) möglich...
Hast Du dann bei eingesteckter USB-Maus diese auch zur Verfügung oder beides oder nur eines? Ich erinnere mich das es damit hier Probleme gab weswegen ich eben den X.org-Treiber einsetze.
Edit: Habe mir die Frage gerade mal selbst beantwortet und es einfach ausprobiert. Ich kann beide nutzen, gleichzeitig. Scrollen am Touchpad geht hier aber nicht aus der Box raus, wobei es da ja einen Wikieintrag bei FreeBSD gibt... Also mal den angebrochenen Nachmittag nutzen und testen was geht.
Edit 2: Im Wiki steht leider nur zum horizontalen Scrollen was drin, Vertikal würde mir ja reichen...
Zuletzt bearbeitet:
Ist hier gerade auch so eingerichtet, Scrollen mit dem Touchpad geht hier aber wie erwähnt nicht.
kmh
Well-Known Member
Also ich kan bisher über den neuen Xorg-Server leider nichts gutes sagen...
Das Update als solches lief mit den Hinweisen in UPDATING recht mühelos über die Bühne. Doch seitdem häufen sich bei mir die Probleme.
Als erstes viel mir auf, sobald ich mich unter KDE3/4 abgemeldet habe und eigentlich der KDM wieder erscheinen sollte, friert das System ein, manchmal startet er dann automatisch neu, ein paar mal musste ich aber auch die Reset-Taste drücken.
Ich habe darafhin den X-Server manuell gestartet per 'startx'. Der Server läuft und lässt sich auch normal beenden. Wenn ich aber nun mittels 'startx' den Server noch einmal starte, friert das System ein und startet automatisch neu.
Als Treiber habe ich den 'radeonhd' sowie 'ati' verwendet.
Hier ist die config: http://bsdforen.pastebin.com/ma91310b
Als Grafik-Karte nutze ich eine RadeonHD4850. Vor dem Update lief das System einwandfrei.
Hat jemand eine Idee?!
Edit:
Ich scheine nicht der einzige zu sein der dieses Problem hat "http://bugs.freedesktop.org/show_bug.cgi?id=19765"
Das Update als solches lief mit den Hinweisen in UPDATING recht mühelos über die Bühne. Doch seitdem häufen sich bei mir die Probleme.
Als erstes viel mir auf, sobald ich mich unter KDE3/4 abgemeldet habe und eigentlich der KDM wieder erscheinen sollte, friert das System ein, manchmal startet er dann automatisch neu, ein paar mal musste ich aber auch die Reset-Taste drücken.
Ich habe darafhin den X-Server manuell gestartet per 'startx'. Der Server läuft und lässt sich auch normal beenden. Wenn ich aber nun mittels 'startx' den Server noch einmal starte, friert das System ein und startet automatisch neu.
Als Treiber habe ich den 'radeonhd' sowie 'ati' verwendet.
Hier ist die config: http://bsdforen.pastebin.com/ma91310b
Als Grafik-Karte nutze ich eine RadeonHD4850. Vor dem Update lief das System einwandfrei.
Hat jemand eine Idee?!
Edit:
Ich scheine nicht der einzige zu sein der dieses Problem hat "http://bugs.freedesktop.org/show_bug.cgi?id=19765"
Zuletzt bearbeitet:
Deine xorg.conf hat in der Section "Module" Sachen drin stehen, die in meiner nicht drin sind und da wohl auch nicht mehr sein sollen. Ich habe hier ebenfalls eine Radeon im Rechner und es tut alles wie es soll. Hast Du die xorg.conf nach update des X.org neu erstellt oder angepasst? Ein paar Sachen sollen da jetzt anders sein (siehe erstes Post vom Kamikaze).
xGhost
OpenBSD Freack
abend
Bei mir ging das UPDATE eigentlich gar nicht. Es hat mir die Packages Konsistenz Kaput gemacht. Es gab so boese pkg_info fehler. So habe ich nun alle Ports deinstalliert und teilweise neu installiert.
Nun habe ich aber ein Riesen Problem. Meine i915 GK funct nicht mehr. Im moment bin ich mit vesa "unterwegs". Der xorg driver intel-2.5.1 funktioniert sofern nicht mehr, dass nur noch ein schwarzes Bild kommt, und dann funktioniert gar nichts mehr. Ein Fehler aus dem X.org kann man auch nicht entnehmen. Das ist mit dem alten xorg.conf so wie mit dem neuen.
Kann man wieder auf intel-2.4.x zurueck updaten?
Das tastatur layout funktioniert auch noch nicht.
Gruss
ghost
Bei mir ging das UPDATE eigentlich gar nicht. Es hat mir die Packages Konsistenz Kaput gemacht. Es gab so boese pkg_info fehler. So habe ich nun alle Ports deinstalliert und teilweise neu installiert.
Nun habe ich aber ein Riesen Problem. Meine i915 GK funct nicht mehr. Im moment bin ich mit vesa "unterwegs". Der xorg driver intel-2.5.1 funktioniert sofern nicht mehr, dass nur noch ein schwarzes Bild kommt, und dann funktioniert gar nichts mehr. Ein Fehler aus dem X.org kann man auch nicht entnehmen. Das ist mit dem alten xorg.conf so wie mit dem neuen.
Kann man wieder auf intel-2.4.x zurueck updaten?
Das tastatur layout funktioniert auch noch nicht.
Gruss
ghost
FreeBSDuser
Well-Known Member
xGhost: Ich hab auch ne 915, funzt alles super. Probier doch mal den Kernel upzudaten vielleicht hat sich ja das Kernelmodul geändert.
xGhost
OpenBSD Freack
Nein, es hat sich kein Kernel Modul geaendert. So etwas aendert sich ja sowieso nur alle neue REALESE und nicht per sicherheits update?
Welchen xf86-video-intel version hast du?
Ich will hier nicht "sysadminmässig" daherlabern... "never change a running System".. blahblah, aber wenn hier scheinbar so viele direkt nach Erscheinen eines neuen Port ein Update wagen, warum meldet sich keiner zum Testen aber so viele zum Meckern wenn dann was nicht passt? Bezugnehmend auf ein Post von miwi (und er hat nicht gesagt was ich jetzt sage) darf sich bitte niemand wundern, wenn er zum Betatester wird. Scheinbar ist es nur so möglich Ports wirklich zu prüfen. Und auch ich muss mir da an die Nase fassen und mein bevorzugtes System unterstützen, seien es Bugreports, Tests, Dokumentation oder was auch immer.
xGhost
OpenBSD Freack
bla, mehr kann ich jetzt zu deinem scheiss nicht sagen.
A:
Ich habe das Update gemacht, da ich dies schon lange nicht mehr gemacht habe, leider waren da ploetzlich xorg 7.4 enthalten. Das hab ich nicht gesehen.
B:
In einem Forum gilt der Austausch. Ich moechte mich hier gerne austauschen um den Fehler finden zu koennen. Zumal vielleicht jemand gerade das selbe problem hat. Wenn ich genug info habe, kann ich das problem fixen. Ich habe nicht um eine Loesung gefragt.
greets
Nehm ich erstmal so hin.
War ja auch überraschend. Dennoch gilt ja das dauerhaft gepredigte UPDATING lesen. Wer das primär nicht tut muss es nachholen.
Und nun zu obigem. Auch ich darf hier mitteilen was ich denke. Ich habe meine Situation auch schon dargestellt. Ich habe, ab vom Synapticstreiber, keine Probleme mit dem Update. Ich nutze auf einem Rechner den radeonhd und auf einem anderen den nvidia-blob. Auf beiden Rechner habe ich die xorg.conf neu erstellt und ein wenig überarbeitet. Läuft wunderbar.
Laut verschiedenen Quellen, z.b. auch dem ersten Post dieses Threads, sind da zu viele Einträge drin. Versuch doch mal wie es ohne "record" und "xtrap" in der Section "Module" aussieht. Meine aktuelle xorg.conf (auch mit radeonhd, den ganzen Synaptics-Kram habe ich mal rausgeworfen) lege ich zur Ansicht mal hier ab (mit wenigen Änderungen ist das die von "X -configure" neu erstellte xorg.conf).
Edit: Ach und... Auch wenn KDM oder sonst ein Login-Manager dich verlässt sollte ein Resetknopf nicht nötig sein. Versuch dann besser mal per <Strg> + <Alt> + <F2> (oder F3, F4...) auf eine andere tty zu kommen, dich dort einzuloggen und das System sauber neu zu starten.
Edit: Ach und... Auch wenn KDM oder sonst ein Login-Manager dich verlässt sollte ein Resetknopf nicht nötig sein. Versuch dann besser mal per <Strg> + <Alt> + <F2> (oder F3, F4...) auf eine andere tty zu kommen, dich dort einzuloggen und das System sauber neu zu starten.
Zuletzt bearbeitet:
Ich muss einmal etwas gestehen: Ich habe in knapp 13 Jahren FreeBSD nicht einmal UPDATING gelesen. Ich stehe auf dem Standpunkt "Augen zu und durch", entweder es klappt oder es klappt nicht. Wenn es klappt ist gut, wenn es nicht klappt ist es auch gut. Das manuelle Wiedereinrenken ist meist deutlich weniger aufwändig als die von offizieller Seite empfohlenen Kompilier-Orgien. Allerdings habe ich inzwischen zu mindestens halbwegs den Durchblick darüber, wie dies Autobreak-Geraffel eigentlich funktioniert, soweit dies möglich ist.
Was X.org betrifft, kann ich im Moment nur den Kopf schütteln. Xorg 7.4 ist bis jetzt der Tiefpunkt. Früher hatte X.org ein sauberes, zuverlässiges Buildsystem. imake mochte veraltet sein, aber es ist zwischen 1996 und 2007 niemals auch nur ein einziges Update schief gegangen. Aber das war ja nicht mehr gut genug und von allen Buildsystemen dort draußen (cmake, scons, jam) musste man ausgereichnet Autobreak nehmen. Dieses Schrottsystem funktionierte noch nie, weder unter Linux noch unter BSD. Es greift ständig irgendwelche Abhängigkeiten, die es meint haben zu müssen, der Paketmanager aber nicht sieht. Es nutzt irgendwelche rumliegenden Libs, nur weil sie dort sind. Dadurch entstehen zwangsläufig zwei unterschiedliche Sichtweisen auf die Welt, die des Paketmanagers und die vom Autobreak. Irgendwann kommt dann das dicke Updates - sei es Gnome, sei es Xorg, beides geht regelmäßig schief - und es rächt sich. Der Paketmanager baut nicht genug neu, da er irgendwelche obskuren Bibliotheken und deren Nutzung durch Autobreak gar nicht sieht. In der Folge fliegt alles im die Ohren und das System ist total zernudelt. Unter Linux passiert dies genauso wie unter BSD, die meisten Nutzer sehen es nur nicht, da sie fertige Pakete nutzen, welche in sauberen Clustern gebaut wurden. Da die Tinderbox immer saubere Bäume baut, sehen die FreeBSD-Committer den Ärger auch nicht. Und selbst wenn sie es könnten, da Autobreak auf jedem System andere Abhängigkeiten greift, würde es schlicht nichts bringen.
Aber auch davon abgesehen bringt mir Xorg noch die Ader auf meiner Stirn zum Platzen. Speicherlecks ohne Ende, ein Sieb ist dagegen dicht. Mit Xorg 7.4 ist es ein wenig besser geworden, aber weit ab des Optimums. Nein, man baut statt Fehlerkorrekturen Klick-Bunti ein. Früher gab es eine funktionierende Beschleunigungsarchitektur, diese hieß XAA. War nicht mehr gut genug, wurde durch EXA ersetzt. Was ist das Ende vom Lied? XAA hat stark gelitten, ist langsamer und neigt zu Artefakten. EXA führt innerhalb von 2 Minuten reproduzierbar zum Crash des X-Server. randr mag eine tolle Sache sein, unbestritten. Aber auf einem Rechner kann ich allein durch den Aufruf des Kommandos X abschießen. Bei dem anderen muss ich X neustarten, wenn ein Spiel oder so die Auflösung verstellt, da strg-alt-+ nicht mehr funktioniert und randr in dem Fall nicht greift. Dazu immer mehr Automagie. Auf einem Rechnr funktionierte mit Xorg 7.4 das Keyboard nur, wenn ich beim Tippen die Maus bewegte. Kommentar der Entwickler war "Kauf dir nenn USB-Keyboard und nutz Linux". Toll. Am Ende konnte ich das Problem selbst lösen. Ich könnte hier noch weitermachen, von vermurkster Automagie, von Fehlern und so weiter. Aber lassen wir das.
Das sollte mal gesagt sein. Jeder der Probleme mit X.org hat, hat mein volles Verständnis. Und ganz ehrlich, was bei Person A funktioniert, kann bei Person B immer noch explodieren. Das haben die letzten Monate mehrfach gezeigt.
Was X.org betrifft, kann ich im Moment nur den Kopf schütteln. Xorg 7.4 ist bis jetzt der Tiefpunkt. Früher hatte X.org ein sauberes, zuverlässiges Buildsystem. imake mochte veraltet sein, aber es ist zwischen 1996 und 2007 niemals auch nur ein einziges Update schief gegangen. Aber das war ja nicht mehr gut genug und von allen Buildsystemen dort draußen (cmake, scons, jam) musste man ausgereichnet Autobreak nehmen. Dieses Schrottsystem funktionierte noch nie, weder unter Linux noch unter BSD. Es greift ständig irgendwelche Abhängigkeiten, die es meint haben zu müssen, der Paketmanager aber nicht sieht. Es nutzt irgendwelche rumliegenden Libs, nur weil sie dort sind. Dadurch entstehen zwangsläufig zwei unterschiedliche Sichtweisen auf die Welt, die des Paketmanagers und die vom Autobreak. Irgendwann kommt dann das dicke Updates - sei es Gnome, sei es Xorg, beides geht regelmäßig schief - und es rächt sich. Der Paketmanager baut nicht genug neu, da er irgendwelche obskuren Bibliotheken und deren Nutzung durch Autobreak gar nicht sieht. In der Folge fliegt alles im die Ohren und das System ist total zernudelt. Unter Linux passiert dies genauso wie unter BSD, die meisten Nutzer sehen es nur nicht, da sie fertige Pakete nutzen, welche in sauberen Clustern gebaut wurden. Da die Tinderbox immer saubere Bäume baut, sehen die FreeBSD-Committer den Ärger auch nicht. Und selbst wenn sie es könnten, da Autobreak auf jedem System andere Abhängigkeiten greift, würde es schlicht nichts bringen.
Aber auch davon abgesehen bringt mir Xorg noch die Ader auf meiner Stirn zum Platzen. Speicherlecks ohne Ende, ein Sieb ist dagegen dicht. Mit Xorg 7.4 ist es ein wenig besser geworden, aber weit ab des Optimums. Nein, man baut statt Fehlerkorrekturen Klick-Bunti ein. Früher gab es eine funktionierende Beschleunigungsarchitektur, diese hieß XAA. War nicht mehr gut genug, wurde durch EXA ersetzt. Was ist das Ende vom Lied? XAA hat stark gelitten, ist langsamer und neigt zu Artefakten. EXA führt innerhalb von 2 Minuten reproduzierbar zum Crash des X-Server. randr mag eine tolle Sache sein, unbestritten. Aber auf einem Rechner kann ich allein durch den Aufruf des Kommandos X abschießen. Bei dem anderen muss ich X neustarten, wenn ein Spiel oder so die Auflösung verstellt, da strg-alt-+ nicht mehr funktioniert und randr in dem Fall nicht greift. Dazu immer mehr Automagie. Auf einem Rechnr funktionierte mit Xorg 7.4 das Keyboard nur, wenn ich beim Tippen die Maus bewegte. Kommentar der Entwickler war "Kauf dir nenn USB-Keyboard und nutz Linux". Toll. Am Ende konnte ich das Problem selbst lösen. Ich könnte hier noch weitermachen, von vermurkster Automagie, von Fehlern und so weiter. Aber lassen wir das.
Das sollte mal gesagt sein. Jeder der Probleme mit X.org hat, hat mein volles Verständnis. Und ganz ehrlich, was bei Person A funktioniert, kann bei Person B immer noch explodieren. Das haben die letzten Monate mehrfach gezeigt.
troll
Well-Known Member
Jungs, ihr macht mir Mut. Ich hab seit der Aufhebung des freezes keine Updates mehr gefahren, weil es dann erfahrungsgemäss zu Schwierigkeiten kommt. Übrigens zu genau den Schwierigkeiten, in die Neulinge reinrennen, wenn sie durch die Meldung zum Erscheinen eines neuen Release mal testen wollen.
OK, ich hab zwei Systempartitionen, die identisch sind und nach nem fehlgeschlagenen Update kann ich immer noch die Andere booten. Jetzt mal hierzu eine Frage:
Ist es möglich das komplette Update(der ports) innerhalb einer chrootumgebung zu fahren?
Der Vorteil liegt auf der Hand, man könnte das Update in der nicht gebooteten Systempartition fahren und erst booten, wenn man sich einigermassen sicher ist, dass es läuft.
OK, ich hab zwei Systempartitionen, die identisch sind und nach nem fehlgeschlagenen Update kann ich immer noch die Andere booten. Jetzt mal hierzu eine Frage:
Ist es möglich das komplette Update(der ports) innerhalb einer chrootumgebung zu fahren?
Der Vorteil liegt auf der Hand, man könnte das Update in der nicht gebooteten Systempartition fahren und erst booten, wenn man sich einigermassen sicher ist, dass es läuft.
zzz
man zzz
Das ist auch mein Eindruck. In Verbindung mit dem auch sehr tollen Gnome 2.24 Update habe ich mir mein System sauber zerlegt. Ich nutze FreeBSD seit 4.0 und solche Probleme hatte ich bisher noch nie. Ich schätze ich werde jetzt doch alle Ports neu bauen, dafür muss ich den Rechner erst mal irgendwo hin verfrachten wo er meine Nachtruhe nicht stört. Vielleicht mache ich auch gleich eine komplette Neuinstallation, das Update von 7.1 Beta auf Release stünde bei mir auch noch an. Echt Windows-like...
hippodriver
Well-Known Member
Xorg hängt eben an Linux. Und Linux geht Richtung Massenkompatiblität; Ubuntu läßt grüßen. Ohne Automagie kann man im Massenmarkt keinen Blumentopf gewinnen. Das Ende vom Lied wird sein, daß Xorg auf 95% aller Linux-Maschinen automatisch funktioniert und auf allen anderen Rechnern garnicht.
Bei ArchLinux kam der neue xorg server schon vor Wochen und, obwohl Linux ja die Zielplattform von Xorg ist, gab es genausoviel Ärger wie hier.
Generell scheint Portabilität bei Xorg keine hohen Stellenwert mehr zu haben. Ständig soll irgendwas in den Linux kernel verlagert werden (DRI2, GEM, Wayland, Xegl). Dabei waren doch die platformunabhängigen Treiber eine Stärke. Die Zukunft von X11 unter *BSD sieht nicht gerade rosig aus.
Bei ArchLinux kam der neue xorg server schon vor Wochen und, obwohl Linux ja die Zielplattform von Xorg ist, gab es genausoviel Ärger wie hier.
Generell scheint Portabilität bei Xorg keine hohen Stellenwert mehr zu haben. Ständig soll irgendwas in den Linux kernel verlagert werden (DRI2, GEM, Wayland, Xegl). Dabei waren doch die platformunabhängigen Treiber eine Stärke. Die Zukunft von X11 unter *BSD sieht nicht gerade rosig aus.
xGhost
OpenBSD Freack
Vielleicht habe ich auch nur überreagiert. War gestern ganz schön gestresst. Aber wenn das gegen mich gerichtet war, dann meine ich dies immer noch ernst.
Ich habe in zwischen den intel treiber zum laufen bekommen. Ich habe zuerst den i915 von 2.4.3 nach 2.5.1 portiert. Das hat nichts gebracht. Dann habe ich mal module deaktiviert. Die Maus funct mehr schlecht wie recht, aber das ist mir im moment sch*** egal.
Mit diesen Einstellungen lauft es aber im Moment:
Code:
Section "Module"
Load "extmod"
Disable "record"
Load "dbe"
Disable "glx"
Disable "GLcore"
Load "xtrap"
Disable "dri"
Load "freetype"
Disable "type1"
EndSectionIch denke GLX ist das Problem. Könnte aber auch DRI sein.
Wer hat ne i915? Kann das mir jemand bestätigen?
Gruss
Ghost