GerBra schrieb
mentalo schrieb
(EE) Silicon MotionUnknown EDID version 128
Ich vermute, dass es an der neuen Version des Treibers liegt, die gleichzeitig mitgekommen ist. Weiß jemand Rat?

Ist das eine SiS-Grafikkarte? Also xf86-video-sis ?
nein, ich benutze das xf86-video-siliconmotion module

EDIT:
Wenn ich versuche, die Version des Modules zu downgraden kommt:
(EE) module ABI major version (2) doesn't match the servers version (4)
(EE) Failed to load module "siliconmotion" (module requirement mismatch), 0)
(EE) No drivers available.
@mentalo: Sind das alle EE bzw WW Einträge im Xorg.0.log?
Ich finde auf die schnelle nichts zur Fehlermeldung und zum xorg-Modul nichts in den Foren.
Hast du auch mal ganz ohne xorg.conf versucht, also xorg.conf umbenennen?

Wenn keine weiteren, erhellenden Fehlermeldungen zu finden sind dann würde ich an deiner
Stelle einen Bugreport schreiben. Als Ausweich-Treiebr kannst du ja immer noch den vesa nehmen.
@GerBra
ja, das sind alle Fehlermeldung (die üblichen RGBpath etc. hatte ich schon vorsorglich beseitig)

Ganz ohne xorg.conf war eine gute Idee, da startet er zumindest, nur mit falscher Auflösung. Aber das schaffe ich sicherlich noch zu beheben.
Muss nur schauen, ob ich so auch die Touchscreen-Funktionalität hinkriege.
Nun, ganz ohne xorg.conf muß ja nicht sein, war ja nur zum testen. Lege dir halt ein Xorg.0.log
beiseite von einem Start wo es funktioniert.
Dann würde ich deine xorg.conf vornehmen und beim Device erstmal alle Option abschalten.
Auch die Bildschirmauflösungen/Monitor-Sektionen, vielleicht gibt es Probleme durch die Auflösung
in der xorg.conf definiert (und die ja ohne conf ja auch nicht auf Anhieb klappt).
Ich vermute - kurz gesagt 😉 - einfach einen (jetzt) falschen EIntrag in deiner xorg.conf.
Du kannst dir mit Xorg -configure ja auch mal eine erstellen lassen....
also folgende Szenarien, weshalb ich hoffe, dass ich nicht grad einfach zu blöd bin, eine xorg.conf zu schreiben:

-Xorg mit vesa starten funktioniert - starte ich ohne xorg.conf wird siliconmotion zwar als treiber erkannt, aber verworfen. (entweder weil es nicht zum xserver passt (1.5) oder weil "(EE) Silicon MotionUnknown EDID version 128" (1.6)
Xorg.0.log (siliconmotion 1.5):
(==)Matched siliconmotion for the autoconfigured driver
....
(EE) module ABI major version (2) doesn't match the servers version (4)
(EE) Failed to load module "siliconmotion" (module requirement mismatch), 0)
danach läd er vesa

- Xorg.0.log mit siliconmotion 1.6 installiert ohne xorg.conf
(==)Matched siliconmotion for the autoconfigured driver
....
(EE) Silicon MotionUnknown EDID version 128
...
(WW) SiliconMotionxf86UnMapVidMem: cannot find region for [0xb78a5000,0x2000000]
(WW) Silicon MotionUnable to estimate virtual size
...
Fatal server error:
AddScreen/SreenInit failed for driver 0
siliconmotion in meine alte xorg.conf einzutragen oder in eine mit Xorg -configure erstellte, bringt die selben Fehler.
@mentalo
Schreibe da einen Bugreport zu, mit den gewonnen Informationen.
(EE) module ABI major version (2) doesn't match the servers version (4)
klingt mir stark danach als wäre dieses Treiber-Modul nicht aus/für den aktuellen X.Org gebaut.
  • [gelöscht]

Also hallo erstmal 🙂
Ich hab wie ihr alle X geupdated, nachm neustart hats zwar brav meine programme gestartet, maus und tastatur hamm jedoch nemme funktioniert.
Gut, mit Zenwalk-Livecd den autostart innen runlevel 3 geändert.
denn nach bissl sinnlosem rumgespiele und rumprobiere den kernel neu installiert, nvidia neu installiert und ne neue xorg.config mit nvidia gebaut.
folge davon: x wollte nemme starten (iwas wegen type1 und bla). gut, kumpels befragt und in des x config-file folgendes rein:
Section "ServerFlags"
Option "AutoAddDevices" "False"
EndSection
gut. x hat gestartet, jetzt aber mit nem black screen und maus und tastatur haben nach wie vor nicht funktioniert (was mich btw. dazu nötigte immer den pc neuzustarten wenn ich probiert hab x zu starten).
die zeilen wieder auskommentiert, alles was gejammert hat auskommentiert in der x config. dann hab ich beim probiern folgenden fehler bekommn:
segfault at 4 ip....
und den 4 mal hintereinander, immer bissl verschieden.
okay hab ich mir gedacht, kernel nochmal neu (wegen dem nvidia-kernelmod den ich benutzt hab statt dem paket aus den repos (was davor ja auch nicht ging) und per X konfigurieren. Also mit X -configure ne xorg.conf gebaut, probiert, wieder diverse fehler mit freetype etc.
Diese wieder alle auskommentiert, was wieder zum ersten fehler führte (btw. kein backtrace sondern aus dmesg|tail rausgelesen):
segfault at 4 ip....
wenn ich
Section "ServerFlags"
Option "AutoAddDevices" "False"
EndSection
wieder reinschrieb hatt ich des gleiche problem wie davor, x startet zu nem schwarzen bildschirm ohne tastatur und maus.
Weiß jemand vielleicht, wie ich X wieder herrichten kann?
Viele Grüße und danke im voraus,
Jon

(btw. ich finds blöd daß mr neuerdings für X hal starten muß ^^)
Jon schrieb (btw. ich finds blöd daß mr neuerdings für X hal starten muß ^^)
Nein, muß man nicht. Es gibt genug User die sagen: Input hotplugging brauche ich nicht, habe ich
nie gebraucht. Die also dieses Feature nicht nutzen (wie man es abstellt steht im Wiki-Beitrag im
Initial-Posting hier im Thread).
Die auch sagen: ich habe eine wunderbar funktionierende xorg.conf, was soll ich jetzt in
ungewohnten xml-Files rumeditieren müssen.

Zu den evtl. anderen Problemen: als erste Anlaufstelle solltest du immer in die /var/log/Xorg.0.log
schauen. Und wenn du weitere Hilfe brauchst: ein paar mehr Angaben wenigstens zur Grafikkarte
und Treiber wären dann für Helfer sinnvoll.
Also ich habs nu auch mal probiert. In der .fdi Datei hab ich 'us' durch 'de' ersetzt.
Hal und X neugestartet, und was ist? Immernoch us Layout :/
Du mußt ja auch hal neu starten.
Hab ich doch... steht doch oben
Hal und X neugestartet
Ich habe kurzzeitig das Update von 7.3 zu 7.4 vorgenommen. Ich möchte ja nicht zynisch klingen, aber ich sehe keinerlei verbesserungen, ganz im gegenteil.
Nachdem scheinbar jeder so erpicht darauf ist, auf die xorg.conf zu verzichten, würden mich die Gründe interessieren.
Ich meine, dass Xorg neuestens auf HAL setzt, wäre ja dahingehend noch zu verkraften, dass man den ganzen Müll abschalten kann.
Wo liegt der Vorteil, aus einer zentralen (zugegeben etwas kryptischen) config-file, viele kryptische xml-configs (xml mag ja ganz nett sein, allerdings für config-files IMHO das Allerletzte), die man ohne Einlesen nicht einmal findet.

Um kurz meine Erfahrungen zu schildern: Nach dem Update waren Maus und Tastatur weg (wunderbar, nicht?), HAL lief allerdings. Die Auflösung war anstatt 1280x800 auf 1360xirgendwas eingestellt (ohne grafische Beschleunigung, intel treiber). xorg.conf ignorierte jegliche Auflösungsangaben sehr gelassen.
Tastatur und Maus waren zu laufen zu kriegen (allerdings ohne Sondertasten/Maustasten), Trackpoint funktioniert nach wie vor nicht (auch nach den Anleitungen im Wiki). Nach etwas einlesen kam ich drauf, dass fehlende grafische Beschleunigung "völlig normal" sind mit den intel Treibern, da TTM entfernt wurde und GEM erst mit dem Kernel 2.6.28 kommt (traumhaft...).

Mein Fazit: Furchtbar.
Nachdem ich vor kurzem das letzte kernelupdate downgraden musste, da es ebenfalls die intel treiber zerschießt, bin ich etwas lästig. Ich habe keine Lust, mir nach jedem Update das System zu knallen, um dann stundenlang herumzufrickeln, nur um zu sehen, dass ich aufgrund irgendeines Bugs ohnehin wieder downgraden muss.
Ein absolutes Ärgernis, genauso wie xorg-7.4

Aber ich bin für alles offen, wenn mir jemand erklären kann, welchen Sinn es hat, alles auf autodetection zu schalten (und wie gut die unter Linux funktioniert, erlebe ich schon seit vielen Jahren, besonders gestern) und statt einer config viele configs mit furchtbarer Syntax in die /etc zu verstreuen...

So long,
ein verärgerter User
Moin Jungs,

ich habe seit dem Xorg Update ein Problem mit merkwürdigen "Grafikfehlern", und zwar das Fenterinhalte nach Öffnen zumeist gar nicht sichtbar sind, erst wenn ich mit der Maus drüberfahre!
z.B. Homeordner nach Öffnen leer, ich klick rein oder fahr drüber, dann tauchen langsam die Ordner auf, das selbe auch bei Texten!
Das geht mir total auf den Keks! Ich habe eine nVidia Geforce 8600MGT mit dem neusten Treiber am laufen, klappte vorher auch wunderbar! Das Problem liegt bei Compiz, da es bei Metacity icht auftritt, doch vor dem Update funktionierte Compiz reibungslos, an den Einstellungen hab ich nix verändert!
Wenn ich jedoch bei den Compiz-Options "Indirect Rendering" einstelle, tritt das Problem ebenfalls nicht auf, allerdings sehr zu Lasten der Performance!
Jemand von euch ähnliche Probleme oder Lösungen? Bin für jede Hilfe dankbar!

Xorg.conf:
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 1.0  (buildmeister@builder58)  Tue Nov  4 17:18:57 PST 2008

Section "ServerLayout"
    Identifier     "X.org Configured"
    Screen      0  "Screen0" 0 0
EndSection

Section "Files"
    ModulePath      "/usr/lib/xorg/modules"
    FontPath        "/usr/share/fonts/misc"
    FontPath        "/usr/share/fonts/100dpi:unscaled"
    FontPath        "/usr/share/fonts/75dpi:unscaled"
    FontPath        "/usr/share/fonts/TTF"
    FontPath        "/usr/share/fonts/Type1"
EndSection

Section "Module"
    Load           "xtrap"
    Load           "glx"
    Load           "dbe"
    Load           "extmod"
    Load           "freetype"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Monitor Vendor"
    ModelName      "Monitor Model"
EndSection

Section "Device"
    Identifier     "Card0"
    Driver         "nvidia"
    VendorName     "nVidia Corporation"
    BoardName      "GeForce 8600M GT"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Card0"
    Monitor        "Monitor0"
    SubSection     "Display"
        Viewport    0 0
        Depth       24
    EndSubSection
EndSection
Hi,
also bei mir hat alles einwandfrei geklappt mit der Umstellung auf 7.4.
Allerdings habe ich den Eidruck, dass bei mir der intel-Treiber etwas langsamer läuft als vorher,
meine ati graka läuft aber auf jedenfall besser.
Allerdings sehe ich die ganze Sache ählich kritisch wie mic.ragnara:
Wo geht die Reise hin? Ich will die Kontrolle über mein System haben, (unter anderem) deswegen
nutze ich Linux. Wenn immer mehr automatisiert wird ist das der Kontrolle nicht grade zuträglich, vor allem wenn die config-files immer schwieriger zu durchschauen sind. Also ich kenne meine Hardware
und weiss welche Treiber ich in eine xorg.conf eintragen muss, da sträubt sich mir das Fell wenn ich mich
durch config-files im xml-Format quälen muss um herauszufinden was ich wie ändern muss um das gewünschte Ergebniss zu erhalten. Ausserdem finde ich es unmöglich den X-server von Hal abhängig zu
machen (ich meine keine Paket-Abhängigkeiten), dies deckt meiner Meinung nach nicht mit unserem KISS-Prinzip für das ich Arch so liebe. Sinnvoller hätte ich es von den Xorg Entwicklern gefunden, die Hal-Unterstützung einzubauen aber standardmässig zu deaktivieren. So hätten diejenigen die automatische Hardware-Erkennung nutzen wollen sich diese einrichten können und alle anderen hätten ganz normal auf xorg.conf setzn können.
Wenn die Entwicklung auch in anderen Bereichen in diese Richtung läuft muss ich mir in zwei bis drei Jahren vielleicht überlegen wieder zu Windows zu wechseln, denn bis auf den Open-source Gedanken würden sich beide Systeme dann meiner Meinung nach nicht besonders unterscheiden.
Moin,

wollte folgenden Hinweis loswerden.

Nach dem Xorg-Update ist es scheinbar mit ATI/AMD Grafikhardware, welche auf der Chipgeneration RV300 basiert, nicht möglich eine lauffähige Kombination vom aktuellen Xorg + Catalyst Treiber zu konfigurieren.

Der aktuelle Catalyst hat scheinbar einen Bug, wodurch die Unterstützung für RV300 Hardware defekt ist.
https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/284408

Ältere Treiber arbeiten aber nicht mit dem aktuellen Xorg zusammen. Zumindest sind das meine Erfahrung vom gestrigen Tag...

Gruß
Verzweiflung.
Ich fange mal langsam an, wird ein bischen länger um es korrekt zu erklären:

Ich habe 3 Archlinux Boxen, 2 im Büro, 1 zu Hause, alle weitgehend gleich
konfiguriert. Am 1.12. das Update.
Den einen Rechner im Büro habe ich für HAL konfiguriert. Wie im Netz aufgeschnappt, einfach die xorg.conf gesichert, gelöscht und X gestartet.
Alles gut, kein Problem, Maus und Tastatur sind da.
Den zweiten Rechner im Büro ohne HAL, also mit den "Ignorier"-Schaltern.
Alles gut, kein Problem, Maus und Tastatur sind da.
Jetzt der Kampf zu Hause. Bis heute läuft die Maus nicht.
Grafikkarte ist R128, Maus ist eine einfache Logitech Maus mit Wheel.
Zuerst mit HAL versucht. xorg.conf gelöscht.
HAL und dbus laufen, Server startet sogar in höherer Auflösung als bisher...
keine Maus, keine Tastatur.
Nachgeforscht. Durch Zufall gemerkt, das der Kernel-evdev-Treiber nicht automatisch lädt. (Hier auf dem Büro Rechner ist er nach dem booten mit lsmod zu sehen).
Habe dann den evdev Kerneltreiber aus purer Verzweiflung mit modprobe geladen.
Server startet, juhu, Tastatur geht wenigstens (ich kann mir den 127sten
Rechner-reset sparen). Maus geht nicht.
In der Xorg.0.log und mit hal-device sind sowohl Tastatur als auch Maus zu
sehen, Tastatur an /dev/input/event1, Maus an /dev/input/event0.
Warum lädt der Kernel-Evdev nicht automatisch?
(btw wie ist eigentlich der Zusammenhang von Kernel-evdev und Xorg-evdev?)
Wie auch immer, Maus geht nicht. OK. Da ich eh nicht gewillt bin, 6 weitere YAD's (Yet Another Demon [tm]) laufen zu lassen, nur um Maus und Tastatur zu managen, entschliesse ich mich den Xserver nun auch ohne HAL zu konfigurieren, also mit meiner alten xorg.conf und den "Ignorier-Schaltern" (nenn ich jetzt einfach so). Startet, Tastatur geht, KEINE Maus.
Habe vorsichtshalber die Maus per Knoppix-CD getestet um 100% auszuschliessen,
das die Maus an sich evt. kaputt ist. Nein, die ist heil, und ich kriege sie nicht mehr ans laufen.
Bin jetzt mittlerweile echt verzweifeltl. Habe alles gecheckt, doppelt gecheckt, alles probiert, alles 3 mal überdacht.
Weiss nicht mehr weiter, weiss nicht mehr wo ich noch ansetzen soll.

Am 1.12. gabs ja auch ein Kernel-Update. Ist da evt. irgendwas schief gelaufen?
Das habe ich noch nicht gecheckt. Merkwürdig finde ich, das dieses evdev-kernel-modul nicht automatisch lädt. Das tut es hier auf der Büro-Box, aber nicht zuhause. Habe noch mal gecheckt, Pakete sind identisch bei den beiden Rechnern. Ich baue mir noch mal einen eigenen Kernel, wenn das nichts bringt, ist Schluss mit lustig. 3 Tage um eine Maus ans laufen zu bringen sind zuviel.
Ich brauche Eure Ideen...Danke.

[edit] vergessen zu erwähnen: Maus ist über PS2 angeschlossen.
natürlich auch mit USB probiert, geht auch nicht.
@Jonny Mulandros
Welche Version der nvidia Treiber verwendest du?
pacman -Q | grep nvidia

@StAlphonzo
Nein, der X-Server/X.org ist nicht von hal abhängig. Es geht (bei den meisten Post hier im Thread) nur
um einen teil von X, nämlich die automatische Erkennung von Eingabegeräten. X.Org bzw die neue
Version "lediglich" darauf zu beschränken wäre kurzsichtig IMHO.
Und: du hast Kontrolle über dein System. Sonst hättest du ja kene Möglichkeiten gehabt, das alte
Verhalten wieder herzustellen.
KISS hat nichts mit (jetzt) evdev Ja oder Nein zu tun. Ein Pfeiler von ArchLinux ist, immer die neuste,
stabile Version einer Software bereitzustellen. Und das ist X.Org 7.4. Warum sich die Entwickler für
Feature xyz entscheiden haben ist erstmal deren "Ding". Und ich bin mir sicher: es gibt sicher viele
Menschen die über dieses eine Feature (evdev) nun jubeln (z.B. Laptop-User, die sich oft zwischen
mobil, Docking-Stations mit unterschiedlichen Eingabegeräten bewegen.)

Allgemeiner Rant:
Ich finde, Jan (JGC) als Maintainer von X.Org hat einen klasse Job gemacht. Sowohl auf archlinux.org
wie auch hier haben wir, denke ich, frühzeitig und gut den Usern Hilfestellung bei der Umstellung
gegeben. Wer sich (wir haben zum Glück wenige Einzel-Threads zum neuen X.org) die Probleme mal
ansieht: sicher 80% betreffen die Tastatur/Layout-Umstellung (halt eine Besonderheit in DE) und
auch evtl. notwendigen Umstellungen in KDE/Gnome.
Auch bin ich mir sicher, das die Umstellung für mind. 90% der User recht problemlos (unter Beachtung
der Hinweise) funktioniert hat - die melden sich hier natürlich nicht.
Auch sollte ein kurzfristig nicht funktionierendes X Arch-User eigentlich nicht vor unlösbare Probleme
stellen - und tut es in der Mehrzahl wohl auch nicht.
Wer z.B. die Umstellung von statischem /dev auf udev mitgemacht hat wird sich erinnern: auch dort
war nicht alles von Anfang an problemlos (und bei udev waren viel systemnähere Dinge betroffen als
X). Mittlerweile gibt es sicher wenige, die vom Vorteil udev nicht überzeugt sind.
Ich persönlich kann nur sagen: Ich bin vom neuen X.Org sehr angetan, sehe insgesamt einige
Verbesserungen die sich bei mir positiv niederschlagen.
gretel schrieb Warum lädt der Kernel-Evdev nicht automatisch?
(btw wie ist eigentlich der Zusammenhang von Kernel-evdev und Xorg-evdev?)
Wie auch immer, Maus geht nicht. OK. Da ich eh nicht gewillt bin, 6 weitere YAD's (Yet Another Demon [tm]) laufen zu lassen, nur um Maus und Tastatur zu managen, entschliesse ich mich den Xserver nun auch ohne HAL zu konfigurieren, also mit meiner alten xorg.conf und den "Ignorier-Schaltern" (nenn ich jetzt einfach so). Startet, Tastatur geht, KEINE Maus.
Habe vorsichtshalber die Maus per Knoppix-CD getestet um 100% auszuschliessen,
das die Maus an sich evt. kaputt ist. Nein, die ist heil, und ich kriege sie nicht mehr ans laufen.
Bin jetzt mittlerweile echt verzweifeltl. Habe alles gecheckt, doppelt gecheckt, alles probiert, alles 3 mal überdacht.
Weiss nicht mehr weiter, weiss nicht mehr wo ich noch ansetzen soll.
Hattest du bei den Versuchen (ohne evdev/hal, mit alter xorg.conf) evtl. noch das evdev-Modul
geladen und war evtl. hal nicht neu gestartet?
Versuche mal (in der xorg.conf)
Option "AutoEnableDevices" "false"
wegzulassen. Und sicherstellen: evdev ist nicht geladen, hal ist ohne geladenes evdev Modul gestartet.
Und poste dann mal deine xorg.conf und das Xorg.0.log (das Log bitte als Dateiupload, nicht einfach
reinposten). Und mache doch bitte einen extra Thread dafür auf, damit wir das hier rauskriegen.

Kernel würde ich im ersten Moment ausschließen, wobei du ja recht einfach ein Downgrade machen
könntest statt neu zu bauen (sollte ja noch in /var/cache/pacman/pkg liegen).
Und ja: das evdev Modul sollte durch udev eigentlich automatisch geladen werden (wie bei deinem
anderen Rechner ja auch). Alternativ wäre evtl. ein Eintrag in rc.conf->MODULES möglich, aber du
willst es ja auch ohne evdev versuchen/haben.
Hmm, heut geht auf einmal alles wie geschmiert. Auch schön.
GerBra schrieb @Jonny Mulandros
Welche Version der nvidia Treiber verwendest du?
pacman -Q | grep nvidia
Sitze grad in der Uni, kann den Befehl also jetzt nicht ausführen, hab aber die 177.81 oder so ähnlich, funktionierte bisher problemlos!
Diese Darstellungsfehler machen mich ganz kirre, da ich aber sonst mit dem neuen Xorg keine ernsthaften Probleme habe, würde ich auch nicht so gerne downgraden!

Kann es sein, dass Compiz so seine Probleme mit dem neuen Xorg hat.
Gibts hier noch jemanden, der solche oder ähnliche Phänomene erlebt hat?