Xorg 7.4 in den FreeBSD Ports

Ich hatte einen 3-D Performance Einbruch von ca. 75% in Quake3. Nachdem ich auf XAA umgeschaltet habe, läuft es wieder wie vorher. Seltsam, denn bisher konnte ich mit dem Intel-Treiber keinen Unterschied zwischen EXA und XAA ausmachen.

--- edit ---
Ach ja, seit den Updates Gestern (was war das noch mal?) funktioniert xv nicht mehr. mplayer spuckt nur noch: "X11 error: BadAlloc (insufficient resources for operation)0.2% 0 0 99%" aus. vlc geht auch nicht.

Ich muss den Composite Manager abschalten um Videos zu sehen.
 
Zuletzt bearbeitet:
Ach ja, seit den Updates Gestern (was war das noch mal?) funktioniert xv nicht mehr. mplayer spuckt nur noch: "X11 error: BadAlloc (insufficient resources for operation)0.2% 0 0 99%" aus. vlc geht auch nicht.

Ich muss den Composite Manager abschalten um Videos zu sehen.

Ich werde das auch mal testen sobald ich diese Programme wieder installiert habe.
 
Den X-Server kann ich leider nur noch einmal mit Control-Alt-Backspace abschießen und mit startx neu starten. Beim zweiten Abschießen hängt sich der Rechner auf. Kein Netzwerk, keine Tastatur, nur das Hintergrundbild bleibt auf dem Bildschirm. Da hilft nur die Reset-Taste. Das Ganze mit dem xf86-video-intel-2.5.1 Treiber.
 
Hmm, ich habe wieder auf EXA umgeschaltet. Anders als gestern ist die EXA Performance jetzt nur noch 1% schlechter als XAA, dafür geht composite & xv wieder zusammen.

Ich glaube Gestern Abend habe ich noch ein intel-update eingespielt. Da muss irgendetwas in EXA broken gewesen sein, denn ich habe schon immer EXA mit Intel verwendet, da das von Anfang an genau so schnell wie XAA lief.
 
Ich hab xf86-video-intel-2.5.1, habe den -STABLE Kernel und mein System hab ich vor 2 tagen aufgesetzt.

@Yamagi, ich kann größtenteils zustimmen, über das Update auf Xorg 7.4 hab ich kein HEADSUP gesehen, kann sein, dass ich blind bin, aber so ein zentrales update sollte vorher allgegenwertig angekündigt werden und nicht einfach heimlich committed werden. Bei mir ist ausser dem blöden HAL Problem nichts schiefgegangen. Ich hoffe ja auf Wayland, muss gleich mal nachschauen was der macht.

Ich sehe die Ursache für dieses Durcheinander in der scheinbaren Modulatrität von Xorg, die mit 7 eingeführt wurde, offensichtlich aber nicht alles wesentlich Problemloser macht.

Dieser Vorfall lässt sich auch in zwei Teile teilen, einmal ist Xorg ein Wursthaufen und wird nicht besser und zweitens ist die Aufnahme in die offiziellen Ports nicht sehr flüssig gelaufen.
 
Den X-Server kann ich leider nur noch einmal mit Control-Alt-Backspace abschießen und mit startx neu starten. Beim zweiten Abschießen hängt sich der Rechner auf. Kein Netzwerk, keine Tastatur, nur das Hintergrundbild bleibt auf dem Bildschirm. Da hilft nur die Reset-Taste. Das Ganze mit dem xf86-video-intel-2.5.1 Treiber.

Teste mal die Modul Einstellungen aus dem Post #50
Das hat bei mir geholfen, nur das es noch nicht optimal ist...

/// EDIT ///
Was hat es mit diesem DRM im FreeBSD Kernel auf sich?
Muss man einen patch einspielen?
 
Zuletzt bearbeitet:
Yamagi schrieb:
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.
Dito. Bin zwar noch keine 13 Jahre dabei aber ansonsten kann ich das unterschreiben ;)

Insgesamt:
Ich warte einfach auf Pakete und bügel dann neu drauf. Das ist mir hier alles zu doof ;)

Nein, aber mal ehrlich. Ich finde Xorg bewegt sich eigentlich in die richtige Richtung. Modularisierung ist schonmal ein gutes Konzept, soweit es denn funktioniert. Dass sich jeder Mensch über Compositing aufregt und es als Klickibunti abtut verstehe ich nicht ganz.
Ich meine, fast jeder User hat eine OpenGL-fähige Grafikkarte die 99% der Zeit rumidelt. Warum sollte die nicht die Darstellung unterstützen und die CPU entlasten?

Klar, man kanns mit dem Compositing auch wieder übertreiben, so dass kein Geschwindigkeitsvorteil draus erwächst sondern nur ein "Gewaber", aber das ist ja dann jedem selbst überlassen. Gerade mit E17-Bling habe ich aber eigentlich gute Erfahrung gemacht.

Insgesamt, denke ich sollte man hier vielleicht auch ein bisschen die Schuld beim FreeBSD-Projekt suchen. Erst hat man ein halbes Jahr die Ports eingefroren um dann ein System zu veröffentlichen wo notwendigerweise die Pakete sofort veraltet waren und die Leute gezwungen wurden zum Nutzen der Ports, in die dann auf einmal tausende neue Versionen aufgenommen wurden (da sich über sechs Monate ja einiges anstaut).
Ist doch klar, dass dann was nicht passt.
 
troll schrieb:
Ist es möglich das komplette Update(der ports) innerhalb einer chrootumgebung zu fahren?
Ja, das geht. Unter zwei Bedingungen: Im Chroot muss sich ein komplettes FreeBSD befinden und es muss ein /dev innerhalb des Chroot gemountet sein. Das ist es gar kein Problem.
 
Natürlich war der lange Freeze so eine Sache und ich schrieb auch schon an anderer Stelle, dass man sowas in Zukunft vielleicht vermeiden sollte. Aber das ist eine Entscheidung, die die Port-Committer treffen müssen und ich leider nicht kann :)

Florent Thoumie sagte übrigens, dass man in Zukunft keine X.org Superupdates mehr machen wird. Stattdessen sollen neue Teilkomponenten aktualisiert werden, sobald sie Seitens des Herstellers verfügbar sind. Ab das nun aber wirklich Ärger vermeidet oder die gleiche Menge Ärger besser verteilt, wird die Zeit zeigen müssen.

Meine Aussage dort oben, die ja nun zu einiger Diskussion geführt hat, war übrigens nicht so gemeint, dass X.org generell Murks wäre. An sich ist der Weg schon richtig, aber die Umsetzung ist im Moment eine einzige Katastrophe. Bevor man tolle Neuerungen einbaut, müsste die Grundlage erst einmal stimmen. Also einen Kern ohne Speicherlecks, ein funktionierendes Build-System. Nicht blind drauf los frickeln, mit Plan vorgehen. Vielleicht, diese radikalen Änderungen, erst einmal in einem separaten Entwicklunsgzweig ausprobieren und nicht gleich ins Prdouktivsystem fummeln, was zu immer neuen Verspätungen (Xorg 7.4 war ja sehr verspätet) und abenteuerlichen Fehlern auf dem Rücken der Kunden führt. Und, was mir persönlich wichtig ist, wenn man schon Automagie einbaut, dann bitte Wege dokumentieren, wie man sie abschaltet. Und vor allem es so konstruieren, dass sie abschaltbar bleibt, was im Moment zum Glück ja (noch) der Fall ist.
 
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.

Ich habe mal ein paar Module raus geworfen, keine Änderung.
Wie ich oben schon sagte, es hilft NUR der Reset Knopf der Rechner ist praktisch tod nach einem zweiten Start des X-Servers. Auch per ssh ist kein Blumentopf mehr zu gewinnen....

Aber schön zu hören das hier auch andere eine ziemlich dicke Ader am Hals haben bezüglich des Updates.....
 
Ich habe mal ein paar Module raus geworfen, keine Änderung.
Wie ich oben schon sagte, es hilft NUR der Reset Knopf der Rechner ist praktisch tod nach einem zweiten Start des X-Servers. Auch per ssh ist kein Blumentopf mehr zu gewinnen....

Aber schön zu hören das hier auch andere eine ziemlich dicke Ader am Hals haben bezüglich des Updates.....

Nur aus dem xorg.conf nehmen bringt nichts.
Du musst es disablen. Siehe post # 50
Diese automanie giltet leider auch für die Module...
 
@XGhost:

Habe ich auch explizit gemacht, aber wie gesagt, es hat nichts gebracht. Ich bin inzwischen auf den Vesa treiber umgestiegen.

Kann ich zwar nur mit niedriger Auflösung meinen Monitor betreiben aber dafür wenigstens stabil.
 
Ich bin jetzt auf STABLE hoch gegangen. Keine Abstürze mehr beim X-Server-Abschießen.
Natürlich hat's mir davor bei einem freeze das Dateisystem zerlegt. Der background fsck stiegt mit kernel panic in ufs_freeblock, oder so ähnlich, aus. Das hat mir noch ne Session im Single User Mode eingepracht. Aber jetzt ist alles wieder tip top.
 
Also bei mir Funktioniert nur GLX nicht mehr.
DRM habe ich folglich auch deaktiviert so wie Composite.

Mal schauen ob es eine neuere Version von GLX gibt.
Und die Symapthics maus funktioniert noch nicht nicht wie
vorher.
 
GLX/DRM tut bei mir eigentlich - bis auf linux apps. Auch das hauseigene glxinfo in /compat liefert
Error: Unsupported depth 0... exiting
Soweit ich das sehe, verwendet die fc6 noch veraltete xlibs (6.8.2_5) und das stößt sich am neuen xorg? Ich hab keine Ahnung wie die zusammenspielen, aber wenn das das Problem ist, kann man auf eine Lösung wohl erstmal ein paar Monate warten ... oder händisch versuchen die libs zu ersetzen.
Ist das so korrekt oder bin ich auf dem falschen Dampfer?
 
deutsche Tastatur per HAL

Nach einem Upgrade auf 7.4 hat bei meinem Laptop fast alles funktioniert, nur ein Problem - deutsche Tastatur wollte nicht.

Hab es über das Anfummeln der HAL-Autoerkennung dann hinbekommen:

HAL-Policy für Tastatur kopieren:
Code:
cp /usr/local/share/hal/fdi/policy/10osvendor/10-x11-input.fdi /usr/local/etc/hal/fdi/policy/

Policy anpassen:
File "/usr/local/etc/hal/fdi/policy/10-x11-input.fdi" die beiden Zeilen einfügen:
Code:
      <merge key="input.xkb.layout" type="string">de</merge>
      <merge key="input.xkb.variant" type="string">nodeadkeys</merge>

Vollständig sieht das dann so aus:

Code:
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keyboard">
      <!-- If we're using Linux, we use evdev by default (falling back to
           keyboard otherwise). -->
      <merge key="input.x11_driver" type="string">kbd</merge>
      <merge key="input.xkb.layout" type="string">de</merge>
      <merge key="input.xkb.variant" type="string">nodeadkeys</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.x11_driver" type="string">evdev</merge>
      </match>
    </match>
  </device>
</deviceinfo>

Nun klappt alles wunderbar, die ServerFlags konnte ich wieder abschalten. Mit Automagie an meine ich läuft alles sogar etwas flüssiger.
 
Hi,
ich wollte nal fragen ob es xorg 7.4 irgendwo als Package gibt.
Diverse Suchmaschienen wollten mir nichts geben.
Ich hoffe ihr könnt mir helfen :)
 
Habe mich nun auch mal an das xorg Update herangewagt, und es lief ohne Probleme durch.
Nun geht sogar mein Dualscreen wieder :)
 
Are you using Linux?

Code:
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keyboard">
      [COLOR="Orange"]<!-- If we're using Linux, we use evdev by default (falling back to
           keyboard otherwise). -->[/COLOR]
      <merge key="input.x11_driver" type="string">kbd</merge>
      <merge key="input.xkb.layout" type="string">de</merge>
      <merge key="input.xkb.variant" type="string">nodeadkeys</merge>
      [COLOR="Orange"]<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">[/COLOR]
        [COLOR="Red"]<merge key="input.x11_driver" type="string">evdev</merge>[/COLOR]
      </match>
    </match>
  </device>
</deviceinfo>
Mit der von Dir verwendeten HAL-Policy werden "unamerikanische" Tastaturen auf meinem Rechner weiterhin nicht akzeptiert:
Code:
$ less /var/log/Xorg.0.log.old
[snip]
(**) Option "XkbRules" "xorg"
(**) AT Keyboard: XkbRules: "xorg"
(**) Option "XkbModel" "pc105"
(**) AT Keyboard: XkbModel: "pc105"
[COLOR="Red"](**) Option "XkbLayout" "us"
(**) AT Keyboard: XkbLayout: "us"[/COLOR]
(**) Option "CustomKeycodes" "off"
(**) AT Keyboard: CustomKeycodes disabled
(II) XINPUT: Adding extended input device "AT Keyboard" (type: KEYBOARD)
[snip]
:belehren: Erst wenn ich den evdev-Linuxtreiber rausschmeiße:
Code:
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keyboard">
           <!-- If we're using FreeBSD, we use kbd by default -->
           <merge key="input.x11_driver" type="string">kbd</merge>
        <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
               string="FreeBSD">
           <merge key="input.xkb.layout" type="string">de</merge>
           <merge key="input.xkb.variant" type="string">nodeadkeys</merge>
        </match>
    </match>
  </device>
</deviceinfo>
geht's:
Code:
$ less /var/log/Xorg.0.log
[snip]
(**) AT Keyboard: XkbRules: "xorg"
(**) Option "XkbModel" "pc105"
(**) AT Keyboard: XkbModel: "pc105"
[COLOR="Lime"](**) Option "XkbLayout" "de"
(**) AT Keyboard: XkbLayout: "de"[/COLOR]
(**) Option "XkbVariant" "nodeadkeys"
(**) AT Keyboard: XkbVariant: "nodeadkeys"
(**) Option "CustomKeycodes" "off"
(**) AT Keyboard: CustomKeycodes disabled
(II) XINPUT: Adding extended input device "AT Keyboard" (type: KEYBOARD)
[snip]
:D
 
Gibt es inzwischen eine Methode bei der man den XServer verwenden kann und gleichzeitig HAL? Es gab ja unendlich viel (widersprüchliches) zu dem Thema.

Ich hab HAL jetzt doch mal aktiviert, weil einige Dinge das wollen und da ist immernoch alles kaputt (alles reagiert *viel* langsamer, Tastatur-Inputs erst nach Bewegung der Maus etc).

Ich habe in der xorg.conf:
Option "AllowEmptyInput" "False"

Ohne das gehen bei mir Tastatur und Maus auch nicht (ich dachte zumindest das soll gefixt sein?).
 
Zurück
Oben