Xfce4 in FreeBSD
- Ersteller Sloop
- Erstellt am
pit234a
Well-Known Member
kannst du bestimmen/unterscheiden, ob dein Monitor abschaltet, weil er nicht mit dem (womöglich richtigen) Bild klarkommt, oder ob deine GraKa kein passendes Bildsignal liefert, weil womöglich die Unterstützung fehlt oder sie vielleicht einen Defekt hat?
Hattest du es mal ohne xorg.conf probiert?
pit234a
Well-Known Member
BTW:
wenn ich HAL und DBUS nutze und dann vielleicht auch noch eines der mächtigen DEs, wie im oben verlinkten Bereich im Handbuch beschrieben, in welcher Reihenfolge werden dann die einzelnen Konfigurationen (Maus, Tastatur... oder auch sonstige Einstellungen zu X) eigentlich abgearbeitet oder anders gefragt, wann kommt welche denn einer anderen in Gehege?
Dazu habe ich zwar eine gewisse Vorstellung und diese auch bei passender Gelegenheit hier schon mal wiedergegeben, aber es wäre sicher gut, dies mal zusammengefasst uns berufenem Munde dargestellt zu bekommen.
Am Beispiel Tastatur:
Die wird ja für das System (direkt im Kernel?) schon konfiguriert (was im Single-User Modus wirkt). Dann über die rc.conf, sobald diese geladen wird, also grundsätzlich für den Multi-User-Level. Dann startet aber auch schon HAL und DBUS. Doch das System scheint nun seine Konfiguration nicht zu ändern, sondern erst der X-Server wird dann die Konfiguration von HAL zu nutzen, sofern keine abweichende Konfiguration in der xorg.conf vorhanden ist. Hier kann nun wiederum das Ergebnis von HAL vollkommen ignoriert werden, und/oder es kann ein eigener Wunsch realisiert werden. Was hat den Vorrang bei einem Konflikt? Und wenn dann schließlich das Setting eines DE hinzukommt, was überschreibt dieses eigentlich? Denn dieses Setup wird ja nicht an den X-Server zurück vererbt (nicht bei KDE3) und es wirkt auch nur innerhalb der Sitzung des DEs.
Ich fragte deshalb weil es sich so verhält:
wenn ich den schwarzen Hintergrund erhalte (durch den Treiber radeon) dann sehe ich nach dem X start wirklich nur den Pfeil. Wenn ich rechtsklick irgendwo ausführe, dann öffnet sich das fluxbox Menü nur so, daß die Menüschrift zu sehen ist. Kein Rahmen, sonst nix. Egal was ich nun auswähle aus diesem Menü, dsa Menü verschwindet nicht. Stattdessen kann ich an beliebigen anderen Stellen klicken und erneute mit dem Klick solche Menüs öffnen. Das Verhalten ist nicht normal, soviel ist sicher. Es sieht dann aus, als ob Grafikfehler vorhanden wören. Deswegen hat mich das so lange aufgehalten. Ich dachte schwarz wäre normal, was es ja auch ist wie ich nun erfahren habe.
fakt ist nur in meinem Falle --> der Treiber macht nicht das was er soll auf meinem System. Ich habs aufgegeben, nachdem ich nun tagelang mit verschiedenen Treibern und sogar dem neuesten Xorg 7.7 rumgekämpt habe. ATI scheint wirklich nicht so das Wahre für dieses System zu sein, schade. Außer VESA kann ich es nicht zum Laufen kriegen, traurig aber wahr.
wenn ich den schwarzen Hintergrund erhalte (durch den Treiber radeon) dann sehe ich nach dem X start wirklich nur den Pfeil. Wenn ich rechtsklick irgendwo ausführe, dann öffnet sich das fluxbox Menü nur so, daß die Menüschrift zu sehen ist. Kein Rahmen, sonst nix. Egal was ich nun auswähle aus diesem Menü, dsa Menü verschwindet nicht. Stattdessen kann ich an beliebigen anderen Stellen klicken und erneute mit dem Klick solche Menüs öffnen. Das Verhalten ist nicht normal, soviel ist sicher. Es sieht dann aus, als ob Grafikfehler vorhanden wören. Deswegen hat mich das so lange aufgehalten. Ich dachte schwarz wäre normal, was es ja auch ist wie ich nun erfahren habe.
fakt ist nur in meinem Falle --> der Treiber macht nicht das was er soll auf meinem System. Ich habs aufgegeben, nachdem ich nun tagelang mit verschiedenen Treibern und sogar dem neuesten Xorg 7.7 rumgekämpt habe. ATI scheint wirklich nicht so das Wahre für dieses System zu sein, schade. Außer VESA kann ich es nicht zum Laufen kriegen, traurig aber wahr.
pit234a
Well-Known Member
Es könnte auch mal sein, dass du dich verrennst.
Es ist ja nicht so, dass man aus der Frage eines Threadstarters unbedingt erkennen könnte, auf welchem Niveau diese gestellt wird. Bei mir sieht man immer leicht, dass ich furchtbar unwissend bin. Bei dir sieht man im Laufe der Zeit, dass du eher ein Freak bist, der sich sehr gut auskennt. Das sieht man nicht bei den ersten Fragen und das sieht man gar nicht bei den Antworten, die du gibst. Allenfalls kann man es vermuten, weil du vieles ignorierst, doch das bleibt eine vage Vermutung, die auch auf Ignoranz beruhen könnte.
Wenn du dich von meinen Antworten also unterhalb deiner Würde getroffen fühlst, verstehe ich das und weil ich das sicher falsch eingeschätzt habe, entschuldige ich mich auch gerne bei dir.
Es bleiben mir aber einige Ungereimtheiten übrig, die ich als ungeklärt betrachten möchte.
Wieso sollte ein Fluxbox automatisch starten?
Wie du das beschreibst, muss das nun ja vermutet werden.
Wenn ich mich recht entsinne, startet mit X überhaupt nichts weiter und gar nichts automatisch, wenn keine .x* Dateien (ich finde hier auf der Tastatur nicht die Wellenlinie, die für das Heimatverzeichnis des Users steht) vorhanden sind. Dann startet quasi der pure X-server ohne irgendeinen Fenstermanager oder ein DE. Da öffnet dann keine Maustaste ein Menü. Und da ist (im normal-Mode (der mir etliche Flüche entlockt hat)) ein schwarzer Bildschirm zu sehen. Schwarz in schwarz.
Mit der Option -retro kann dann auch das frühere Rautenmuster erzeugt werden. Von weitem betrachtet sieht das aus, wie ein grauer Hintergrund. Doch wieder ohne jeden WM etc. Kein Mausklick bringt ein Untermenü.
Der X-Server zu diesem Test startet mit X. Nicht mit startx.
Versteh mich nicht falsch, wenn du das alles richtig machst und darüber berichtest, wird davon deine Graka nicht besser unterstützt, als bislang und vermutlich liegst du mit deiner Bemerkung richtig, dass es nicht damit geht, aber aus deinen Antworten auf die zahlreichen Empfehlungen in diesem Thread geht da nichts Genaues hervor, das bleibt für Leser auf der Suche nach Antworten reichlich dubios.
Du kannst ein solches Verhalten erleben, wenn du nicht den passenden Treiber gewählt hast oder, wenn der Treiber nicht richtig funktioniert oder, wenn dein Monitor defekt oder zu empfindlich ist oder die Graka einen Schuss hat oder....
Ich fände es sehr hilfreich und ich bin inzwischen auch entsprechend neugierig, wenn du da genauer herausfinden könntest, was die Ursache ist und uns davon auch berichten würdest.
Je nach HW (ich kenne mich auch damit nicht aus), kann ich jedenfalls die Kritik an ATI gegenüber NVIDEA nicht aus eigener Erfahrung nachvollziehen. Ich nutze kein 3D. Für mich ist ein Bildschirm einfach flach und braucht nur 2D. Die einzige NVIDEA, die ich jemals in einem PC hatte, zeigte Ausfransungen an vertikalen Linien bei längerem Betrieb, die meine ältere ATI nicht zeigte. Deshalb kaufte ich mir damals wieder eine ATI, außerdem die einzige, die ich bekommen konnte, die ohne zusätzliche Stromversorgung auskam und deshalb noch in meinen PC passte. Dass die Darstellung immer optimal sei, will ich nicht behaupten, aber ein X-Server läuft damit grundsätzlich und überhaupt und stellt weitaus mehr dar, als einen schwarzen Bildschirm. Und das galt bisher auch für alle anderen älteren Graka, meist ATI oder INTEL, die ich mit FreeBSD probierte.
Ein solch totales Versagen, wie du es nun festgestellt hast, habe ich noch nie erlebt.
Das will nichts weiter bedeuten. Es soll nur meine Neugierde erklären und den Wunsch, besser klar zu sehen, wo genau denn das Problem liegt.
Vielleicht findest du ja die Zeit dafür...
Hallo Pit,
es tut mir leid, wenn ich oft vergesse, Sachen aufzuschreiben oder auf bestimmte Punkte zu antworten. Ich bin zu jener Zeit wahrscheinlich so auf einen bestimmten Arbeitspunkt fixiert, dass ich diesen detailliert beschreibe, dafür andere Fragen unbeantwortet lasse. Das ist nicht meine Absicht, und schon gar nicht Ignoranz. Irgendwann davor hattest du mir ja auch empfohlen es erstmal mit fluxbox zu probieren, bevor ich mit xfce weitermache, und deinen Tip habe ich beherzigt. Das war auch 'ne gute Idee, definitiv. Falls das also so rüberkam, tut mir sorry. Ich lese mir übrigens ALLE Antworten durch, auch deine liebe Pit
Vergessen wir mal die Geschehnisse aus andren Freds und trinken erst mal ein virtuelles Bierchen zusammen ... *bier_reich_und_anstoss* ^-^
Zu dem Problem und meinen Erfahrungen. Du hast das alles korrekt geschildert und ich verstehe jetzt auch, warum du deine Zweifel hast. Wie du es beschrieben hast ist alles korrekt, kein Zweifel. Als ich meine Ergebnisse weiter oben postete, dann meinte ich das auch wirklich so. Wenn ich natürlich nur den X starte, oder nur den X -config test dann krieg ich natürlich auch nur den leeren Hintergrund (ob schwarz oder grau sei mal dahingestellt) und den Mauszeiger. So sehe ich schonmal, ob meine Maus reagiert und keine extremen Grafikfehler zu sehen sind. Zu den Anfängen (erste Schritte) mit X dachte ich an jener Stelle immer, dass mein X quasi funktioniert, aber das ist leider nicht so.
Um das weiter zu testen, benötige ich einen WM. Anfangs hatte ich ja den xfce, jetzt habe ich den fluxbox den ich erstmal zum Testen nutze. Zur Info: ich habe alle Pakete runtergehauen, alles komplett deinstalliert. Und ganz von Anfang begonnen. Ich nutze jetzt den neuen Paketmanager und installiere die Pakte mit "pkg". So muss ich nicht selbst bauen und lange warten. Mein Versionsstand ist also der aus der pkg-repo.
Natürlich habe ich meine ~/.xinitrc so editiert, dass ich überhaupt auch fluxbox sehen kann. Das mache ich mit dem simplen Eintrag "exec fluxbox" in dieser xinitrc Startdatei. Sonst steht in dieser Datei nichts drin. Wenn ich also startx eingebe, dann startet mein X-Server und daraufhin der fluxbox-wm.
Und da Bilder mehr als tausend Worte sagen, habe ich das für euch mal abfotografiert, damit ihr es euch besser vorstellen könnt. Meine config habe ich einmal erstellt, und nach /etc/X11/xorg.conf kopiert. Zur Fehlerausgrenzung starte ich dbus und hald NICHT über die rc.conf, das heißt sie laufen definitiv nich (mit status überprüft!). Dafür habe ich in meine /etc/X11/xorg.conf den Eintrag AutoAddDevices auf False gesetzt. Funktioniert auch alles brav, und ich hab Tastatur+Mouse im X. Hier nun die Bilder mit dem zuvor ausgeführten Befehl als Überschrift...
"X -config /root/X11/xorg.conf" ohne (!) vorhandene ~/.xinitrc und in der xorg.conf steht als Treiber=radeon
"startx", Treiber=radeon, ohne ~/.xinitrc. Durch das default startx Skript wird also dadurch der twm gestartet mit den drei Konsolenfenstern und der Uhr oben rechts. Man sieht hier jetzt schon deutlich, dass etwas mit der Grafik nicht stimmt, auch die Uhr ist nicht zu sehen. Die Fensterleisten sehen auch falsch aus.
Jetzt drück ich mal auf dem schwarzen Hintergrund die linke Maustaste und es erscheint das TWM-Menü. Jedoch ohne Ränder, und auch dann wenn ich die linke Maustaste wieder loslasse. Das Menü brennt sich an dieser Position quasi ein, und überall wo ich einen erneuten Linksklick ausführe, brennt sich das Menü ein. Wie das dann aussieht, sieht man hier:
Jetzt verändere ich in meiner xorg.conf den Treiber auf Vesa. Und siehe da, alles funktioniert so wie es soll. Der TWM arbeitet korrekt, die Fenster werden korrekt angezeigt und die Uhr ist auch sichtbar.
Jetzt versuche ich das Ganze mit fluxbox statt dem twm. Dazu erstelle ich eine ~/.xinitrc und schreibe dort hinein "exec fluxbox". Das Ergebnis ist dann, dass durch den Aufruf des Skriptes "startx" nicht mehr der twm zu sehen ist, sondern als letzte Instanz der "fluxbox" wm. Der Treiber ist momentan noch auf VESA gestellt. Das sieht dann so aus:
man sieht die untere Leiste, und ich kann mich rechtsklick das Fluxbox-Menü öffnen. Schaut alles gut aus bis hierher.
Und jetzt schalte ich wieder auf den Treiber radeon um und das Problem wird deutlich:
==> schwarzer Bildschirm! keine untere Leiste zu sehen, und rechtsklicks zeigen mir nichts an.
Mein Fazit: es liegt wohl ganz klar am Treiber, das habe ich doch durch diese Tests ganz eindeutig feststellen können.
Was ich mit ATI meinte ist folgendes. Ich bin nicht generell gegen ATI, im Gegenteil. Ich bin eigentlich eher Befürworter für ATI wenns um 3D geht. Ich besitze selbst auch eine 'kräftige' ATI-Karte in meinem Hauptrechner. Bei diesem FreeBSD-System handelt es sich um ein Testsystem, und da ist nunmal diese ATI Radeon HD 2600 Pro AGP verbaut. Da ich das Internet durchforstet habe ist mir nach Durchlesen sehr vieler Beiträge aufgefallen, dass vor allem ATI-Karten schwer konfigurierbar sein KÖNNEN (!). Das impliziert nicht die Aussage, dass die ATIs generell nicht laufen, sondern das bedeutet einfach nur, dass es zu Komplikationen kommen kann. Das Problem habe nicht ich erfunden, sondern es ist präsent. Auch in diesem Forum wurde schon darüber diskutiert. Wie ich ja schon sagte. Ich habe es auch mit dem neuesten Xorg-Server probiert und KMS, DRM aber das hat erst recht nicht hingehauen. Das war doch schon eher experimentell, da der Treiber anders angesprochen wird.
Aus diesem Grunde sagte ich, bin ich am verzweifelnd aufgeben :-) Wie es wohl aussieht muss ich mich mit VESA begnügen, es sei denn jemand hätte mir noch ein paar nette Ratschläge zu bieten, die ich dankend entgegennehme.
Nochmals an ALLE Beteiligten, recht herzlichen Dank für eure freundliche Unterstützung. Das weiß ich wirklich zu schätzen! Und sorry, falls ich mal vor lauter Schreiben und "Auf-Ein-Problem-Fixiert-Sein" vergesse, auf eine bestimmte Frage explizit einzugehen. Ich hoffe jetzt durch die Bilderdarstellung, daß ihr das Problem verstanden habt.
Danke und Grüße,
Sloop.
es tut mir leid, wenn ich oft vergesse, Sachen aufzuschreiben oder auf bestimmte Punkte zu antworten. Ich bin zu jener Zeit wahrscheinlich so auf einen bestimmten Arbeitspunkt fixiert, dass ich diesen detailliert beschreibe, dafür andere Fragen unbeantwortet lasse. Das ist nicht meine Absicht, und schon gar nicht Ignoranz. Irgendwann davor hattest du mir ja auch empfohlen es erstmal mit fluxbox zu probieren, bevor ich mit xfce weitermache, und deinen Tip habe ich beherzigt. Das war auch 'ne gute Idee, definitiv. Falls das also so rüberkam, tut mir sorry. Ich lese mir übrigens ALLE Antworten durch, auch deine liebe Pit
Vergessen wir mal die Geschehnisse aus andren Freds und trinken erst mal ein virtuelles Bierchen zusammen ... *bier_reich_und_anstoss* ^-^Zu dem Problem und meinen Erfahrungen. Du hast das alles korrekt geschildert und ich verstehe jetzt auch, warum du deine Zweifel hast. Wie du es beschrieben hast ist alles korrekt, kein Zweifel. Als ich meine Ergebnisse weiter oben postete, dann meinte ich das auch wirklich so. Wenn ich natürlich nur den X starte, oder nur den X -config test dann krieg ich natürlich auch nur den leeren Hintergrund (ob schwarz oder grau sei mal dahingestellt) und den Mauszeiger. So sehe ich schonmal, ob meine Maus reagiert und keine extremen Grafikfehler zu sehen sind. Zu den Anfängen (erste Schritte) mit X dachte ich an jener Stelle immer, dass mein X quasi funktioniert, aber das ist leider nicht so.
Um das weiter zu testen, benötige ich einen WM. Anfangs hatte ich ja den xfce, jetzt habe ich den fluxbox den ich erstmal zum Testen nutze. Zur Info: ich habe alle Pakete runtergehauen, alles komplett deinstalliert. Und ganz von Anfang begonnen. Ich nutze jetzt den neuen Paketmanager und installiere die Pakte mit "pkg". So muss ich nicht selbst bauen und lange warten. Mein Versionsstand ist also der aus der pkg-repo.
Natürlich habe ich meine ~/.xinitrc so editiert, dass ich überhaupt auch fluxbox sehen kann. Das mache ich mit dem simplen Eintrag "exec fluxbox" in dieser xinitrc Startdatei. Sonst steht in dieser Datei nichts drin. Wenn ich also startx eingebe, dann startet mein X-Server und daraufhin der fluxbox-wm.
Und da Bilder mehr als tausend Worte sagen, habe ich das für euch mal abfotografiert, damit ihr es euch besser vorstellen könnt. Meine config habe ich einmal erstellt, und nach /etc/X11/xorg.conf kopiert. Zur Fehlerausgrenzung starte ich dbus und hald NICHT über die rc.conf, das heißt sie laufen definitiv nich (mit status überprüft!). Dafür habe ich in meine /etc/X11/xorg.conf den Eintrag AutoAddDevices auf False gesetzt. Funktioniert auch alles brav, und ich hab Tastatur+Mouse im X. Hier nun die Bilder mit dem zuvor ausgeführten Befehl als Überschrift...
"X -config /root/X11/xorg.conf" ohne (!) vorhandene ~/.xinitrc und in der xorg.conf steht als Treiber=radeon
"startx", Treiber=radeon, ohne ~/.xinitrc. Durch das default startx Skript wird also dadurch der twm gestartet mit den drei Konsolenfenstern und der Uhr oben rechts. Man sieht hier jetzt schon deutlich, dass etwas mit der Grafik nicht stimmt, auch die Uhr ist nicht zu sehen. Die Fensterleisten sehen auch falsch aus.
Jetzt drück ich mal auf dem schwarzen Hintergrund die linke Maustaste und es erscheint das TWM-Menü. Jedoch ohne Ränder, und auch dann wenn ich die linke Maustaste wieder loslasse. Das Menü brennt sich an dieser Position quasi ein, und überall wo ich einen erneuten Linksklick ausführe, brennt sich das Menü ein. Wie das dann aussieht, sieht man hier:
Jetzt verändere ich in meiner xorg.conf den Treiber auf Vesa. Und siehe da, alles funktioniert so wie es soll. Der TWM arbeitet korrekt, die Fenster werden korrekt angezeigt und die Uhr ist auch sichtbar.
Jetzt versuche ich das Ganze mit fluxbox statt dem twm. Dazu erstelle ich eine ~/.xinitrc und schreibe dort hinein "exec fluxbox". Das Ergebnis ist dann, dass durch den Aufruf des Skriptes "startx" nicht mehr der twm zu sehen ist, sondern als letzte Instanz der "fluxbox" wm. Der Treiber ist momentan noch auf VESA gestellt. Das sieht dann so aus:
man sieht die untere Leiste, und ich kann mich rechtsklick das Fluxbox-Menü öffnen. Schaut alles gut aus bis hierher.
Und jetzt schalte ich wieder auf den Treiber radeon um und das Problem wird deutlich:
==> schwarzer Bildschirm! keine untere Leiste zu sehen, und rechtsklicks zeigen mir nichts an.
Mein Fazit: es liegt wohl ganz klar am Treiber, das habe ich doch durch diese Tests ganz eindeutig feststellen können.
Was ich mit ATI meinte ist folgendes. Ich bin nicht generell gegen ATI, im Gegenteil. Ich bin eigentlich eher Befürworter für ATI wenns um 3D geht. Ich besitze selbst auch eine 'kräftige' ATI-Karte in meinem Hauptrechner. Bei diesem FreeBSD-System handelt es sich um ein Testsystem, und da ist nunmal diese ATI Radeon HD 2600 Pro AGP verbaut. Da ich das Internet durchforstet habe ist mir nach Durchlesen sehr vieler Beiträge aufgefallen, dass vor allem ATI-Karten schwer konfigurierbar sein KÖNNEN (!). Das impliziert nicht die Aussage, dass die ATIs generell nicht laufen, sondern das bedeutet einfach nur, dass es zu Komplikationen kommen kann. Das Problem habe nicht ich erfunden, sondern es ist präsent. Auch in diesem Forum wurde schon darüber diskutiert. Wie ich ja schon sagte. Ich habe es auch mit dem neuesten Xorg-Server probiert und KMS, DRM aber das hat erst recht nicht hingehauen. Das war doch schon eher experimentell, da der Treiber anders angesprochen wird.
Aus diesem Grunde sagte ich, bin ich am verzweifelnd aufgeben :-) Wie es wohl aussieht muss ich mich mit VESA begnügen, es sei denn jemand hätte mir noch ein paar nette Ratschläge zu bieten, die ich dankend entgegennehme.
Nochmals an ALLE Beteiligten, recht herzlichen Dank für eure freundliche Unterstützung. Das weiß ich wirklich zu schätzen! Und sorry, falls ich mal vor lauter Schreiben und "Auf-Ein-Problem-Fixiert-Sein" vergesse, auf eine bestimmte Frage explizit einzugehen. Ich hoffe jetzt durch die Bilderdarstellung, daß ihr das Problem verstanden habt.
Danke und Grüße,
Sloop.
pit234a
Well-Known Member
Aih, Sloop.
Das mit dem Bier ist eine hervorragende Idee, die ich nicht virtuell belasse! Wenn ich später nur noch lalle, weißt du nun also den Grund. Prost.
X ist fast immer ein Problem für mich gewesen. Es hat mir immer Angst gemacht, vor jeder Installation sah ich das als große Hürde und freute mich, wenn ich dann endlich bunte Bilder sah. Die Erleichterung war meist so groß, dass ich gar nicht mehr genau verstehen wollte, was ich da gemacht habe und nur mit dem Ergebnis zufrieden war. So lernt man es natürlich nicht und das hatte ich auch nie wirklich vor. Computer und Betriebssysteme interessieren mich nicht wirklich.
Was ich also nun sage, ist eine Art Essenz aus vielen Installationen in der Vergangenheit und ohne viel Grundlagen-Wissen. Details muss ich immer nachlesen.
Ich finde, du hast noch einige Chancen und kannst vielleicht noch mehr probieren. Evtl vertust du aber viel Zeit und findest keine Lösung. Es könnte durchaus so eine Monitor-Anpassungs-Schwierigkeit sein. Es kommt mich aber komisch vor, die Reaktion würde ich auch erst mal auf Treiber/Konfiguration schieben (jetzt, wo ich es sehe und verstehe danke dafür und deine gesamte Erklärung)
Was ich nun schreibe, steht nicht in der Reihenfolge, in der ich das selbst versuchen würde. Überflieg das mal zunächst und entscheide dann selbst.
Zunächst zum Treiber.
Wenn du in /usr/ports/x11-drivers hineinsiehst, findest du einige ati Treiber und darunter mehrere für radeonhd Karten. Früher waren da (glaube ich jedenfalls mich zu erinnern) zu jedem Treiber in der pkg-descr eine ganze reihe an Beispiel-Karten mit Namen aufgeführt. Nun habe ich kurz hineingesehen und finde nur dürftige Information.
Alleine, du kannst direkt sehen, dass es Treiber für radeonhd gibt und eine devel-version. Außerdem, das sieht man nicht sofort, gibt es einen Treiber xf86-video-ati und hier findet man in der pkg-plist dann auch Module für radeonhd. Es ist der Treiber, den ich nun für mich ausgesucht habe und mit meiner aktuellen Graka betreibe. Ich weiß, dass ich zuvor schon andere probiert hatte, ich weiß nicht mehr, wieso ich nun ausgerechnet bei diesem geblieben bin. Zumindest scheint er keine echten Nachteile gehabt zu haben.
Da könntest du also schon noch einige Versionen probieren, bevor du endgültig auf VESA setzt.
An dieser Stelle einen Einwand, der mir vielleicht Schelte einbringen wird: bei einigen Systemen erlebte ich es, dass die gleichen Programme, Xorg oder die Treiber, als Pakete leider nicht funktionierten und ich dafür dann eigens aus den Ports bauen ließ. Das waren damals FreeBSD7er und es bezog sich auf zwei PCs. Was die Ursache war, weiß ich nicht. Es bleibt unvergessen für mich und ich kann nicht sagen, ob das damals eine spezielle Sache war oder ein allgemeines Verfahren sein könnte, einen fehler auszuschließen.
Dann zu deiner xorg.conf und mit oder ohne HAL.
Hal ist Mist, ist mein Standpunkt und war es schon, als er in der Linux-Welt eingeführt wurde. Leider haben die Xorg-Menschen und viele andere darauf gesetzt und uns damit eine Entscheidung aufs Auge gedrückt, die sich bei manchen Systemen sehr nachteilig auswirkte, denn Hal funktioniert durchaus nicht immer, wie das mal angedacht war.
Sehr oft funktioniert er aber und bei den letzten Installationen, die ich machte, habe ich es nun zunächst aus purem Interesse immer zunächst vollkommen ohne xorg.conf probiert und stattdessen die Automagie von Hal genutzt.
Hal und dbus ausschalten sind gute Tips und zur Fehlersuche ist es hilfreich, dies mal zu tun. Da es aber bei dir keinen Erfolg ohne brachte, würde ich es gerade mal mit HAL und dbus und ohne xorg.conf probieren. Bei mir funktionierte es zu über 80 Prozent aller PCs direkt mit X und ohne eine xorg.conf und den X -configure Schritt. Das ist einen Versuch wert. Bei mir habe ich später fast immer doch wieder eine xorg.conf benutzt, weil ich einfach wusste, wie ich da bestimmte Einstellungen realisieren konnte, die ich erst hätte suchen müssen, um sie in den Hal-Konfigurationen zu realisieren. Also, eher aus Faulheit hielt ich dann an dem gewohnten fest und ignorierte die Möglichkeiten, die HAL eigentlich dafür anbietet. Grundsätzlich gibt es weitreichende Möglichkeiten, die ich nie richtig verstanden habe (weiter oben versuchte ich dazu auch mal eine Frage, wie die einzelnen Funktionen so zusammen oder gegeneinander arbeiten).
Es ist dabei eine weitere Erfahrung, auf wenigen Systemen basierend, dass der Automagismus von Hal präziser arbeitete, als X -configure.
Damit gibt es nun ja schon eine ganze Reihe an weiteren Möglichkeiten, mit denen du spielen kannst und vielleicht hilft ja eine.
Mein Rat von weiter oben ist auch begründet und deshalb wiederhole ich ihn nochmals: in die /usr/local/lib/X11/xinit/xinitrc, die von startx ausgeführt wird, die Zeilen mit twm usw ersetzen und von dort den fluxbox starten lassen. Nicht über eine locale .xsession, bzw .xinitrc. Ich kann das nicht abschließend wirklich erklären, aber du hast eine größere Chance auf diese Weise alles richtig zu machen UND Fehlermeldungen zu sehen, die dir weiter helfen können.
Ich glaube, exec fluxbox ist keine gute Idee.
Nimm /pfad/zu/fluxbox & und am liebsten, wie beschrieben in dieser xinitrc direkt eingetragen. Später spielt das dann eh keine Rolle mehr, was da steht, weil du dann deine localen Dateien nach Wunsch einrichtest.
Also, nicht, dass es nicht auch so gehen müsste, wenn dein Eintrag in der localen .xinitrc stimmt, aber es geht ja eben im Moment noch nicht bei dir und da rate ich zu eher Narrensicheren Methoden. Das soll nicht anzüglich gemeint sein, aber ich glaube, das brauche ich nun nicht mehr extra zu erwähnen.
Wenn du das ausprobiert hast, glaube ich, dass du Erfolgreich sein wirst ohne weitere Kniffe.
Vielleicht täusche ich mich aber und es funktioniert wirklich nicht mit deiner Graka.
Und deinem Monitor.
Ich glaube es zwar nicht, dass dieser Fehler so vom Monitor kommen kann, aber, wenn du mal einen anderen dran hängen kannst, wüssten wir es mit mehr Sicherheit. Vielleicht hat der monitor auch einen Auto-Setup und da könnte es helfen, den mal laufen zu lassen, während X läuft.
Das mit dem Bier ist eine hervorragende Idee, die ich nicht virtuell belasse! Wenn ich später nur noch lalle, weißt du nun also den Grund. Prost.
X ist fast immer ein Problem für mich gewesen. Es hat mir immer Angst gemacht, vor jeder Installation sah ich das als große Hürde und freute mich, wenn ich dann endlich bunte Bilder sah. Die Erleichterung war meist so groß, dass ich gar nicht mehr genau verstehen wollte, was ich da gemacht habe und nur mit dem Ergebnis zufrieden war. So lernt man es natürlich nicht und das hatte ich auch nie wirklich vor. Computer und Betriebssysteme interessieren mich nicht wirklich.
Was ich also nun sage, ist eine Art Essenz aus vielen Installationen in der Vergangenheit und ohne viel Grundlagen-Wissen. Details muss ich immer nachlesen.
Ich finde, du hast noch einige Chancen und kannst vielleicht noch mehr probieren. Evtl vertust du aber viel Zeit und findest keine Lösung. Es könnte durchaus so eine Monitor-Anpassungs-Schwierigkeit sein. Es kommt mich aber komisch vor, die Reaktion würde ich auch erst mal auf Treiber/Konfiguration schieben (jetzt, wo ich es sehe und verstehe
danke dafür und deine gesamte Erklärung)Was ich nun schreibe, steht nicht in der Reihenfolge, in der ich das selbst versuchen würde. Überflieg das mal zunächst und entscheide dann selbst.
Zunächst zum Treiber.
Wenn du in /usr/ports/x11-drivers hineinsiehst, findest du einige ati Treiber und darunter mehrere für radeonhd Karten. Früher waren da (glaube ich jedenfalls mich zu erinnern) zu jedem Treiber in der pkg-descr eine ganze reihe an Beispiel-Karten mit Namen aufgeführt. Nun habe ich kurz hineingesehen und finde nur dürftige Information.
Alleine, du kannst direkt sehen, dass es Treiber für radeonhd gibt und eine devel-version. Außerdem, das sieht man nicht sofort, gibt es einen Treiber xf86-video-ati und hier findet man in der pkg-plist dann auch Module für radeonhd. Es ist der Treiber, den ich nun für mich ausgesucht habe und mit meiner aktuellen Graka betreibe. Ich weiß, dass ich zuvor schon andere probiert hatte, ich weiß nicht mehr, wieso ich nun ausgerechnet bei diesem geblieben bin. Zumindest scheint er keine echten Nachteile gehabt zu haben.
Da könntest du also schon noch einige Versionen probieren, bevor du endgültig auf VESA setzt.
An dieser Stelle einen Einwand, der mir vielleicht Schelte einbringen wird: bei einigen Systemen erlebte ich es, dass die gleichen Programme, Xorg oder die Treiber, als Pakete leider nicht funktionierten und ich dafür dann eigens aus den Ports bauen ließ. Das waren damals FreeBSD7er und es bezog sich auf zwei PCs. Was die Ursache war, weiß ich nicht. Es bleibt unvergessen für mich und ich kann nicht sagen, ob das damals eine spezielle Sache war oder ein allgemeines Verfahren sein könnte, einen fehler auszuschließen.
Dann zu deiner xorg.conf und mit oder ohne HAL.
Hal ist Mist, ist mein Standpunkt und war es schon, als er in der Linux-Welt eingeführt wurde. Leider haben die Xorg-Menschen und viele andere darauf gesetzt und uns damit eine Entscheidung aufs Auge gedrückt, die sich bei manchen Systemen sehr nachteilig auswirkte, denn Hal funktioniert durchaus nicht immer, wie das mal angedacht war.
Sehr oft funktioniert er aber und bei den letzten Installationen, die ich machte, habe ich es nun zunächst aus purem Interesse immer zunächst vollkommen ohne xorg.conf probiert und stattdessen die Automagie von Hal genutzt.
Hal und dbus ausschalten sind gute Tips und zur Fehlersuche ist es hilfreich, dies mal zu tun. Da es aber bei dir keinen Erfolg ohne brachte, würde ich es gerade mal mit HAL und dbus und ohne xorg.conf probieren. Bei mir funktionierte es zu über 80 Prozent aller PCs direkt mit X und ohne eine xorg.conf und den X -configure Schritt. Das ist einen Versuch wert. Bei mir habe ich später fast immer doch wieder eine xorg.conf benutzt, weil ich einfach wusste, wie ich da bestimmte Einstellungen realisieren konnte, die ich erst hätte suchen müssen, um sie in den Hal-Konfigurationen zu realisieren. Also, eher aus Faulheit hielt ich dann an dem gewohnten fest und ignorierte die Möglichkeiten, die HAL eigentlich dafür anbietet. Grundsätzlich gibt es weitreichende Möglichkeiten, die ich nie richtig verstanden habe (weiter oben versuchte ich dazu auch mal eine Frage, wie die einzelnen Funktionen so zusammen oder gegeneinander arbeiten).
Es ist dabei eine weitere Erfahrung, auf wenigen Systemen basierend, dass der Automagismus von Hal präziser arbeitete, als X -configure.
Damit gibt es nun ja schon eine ganze Reihe an weiteren Möglichkeiten, mit denen du spielen kannst und vielleicht hilft ja eine.
Mein Rat von weiter oben ist auch begründet und deshalb wiederhole ich ihn nochmals: in die /usr/local/lib/X11/xinit/xinitrc, die von startx ausgeführt wird, die Zeilen mit twm usw ersetzen und von dort den fluxbox starten lassen. Nicht über eine locale .xsession, bzw .xinitrc. Ich kann das nicht abschließend wirklich erklären, aber du hast eine größere Chance auf diese Weise alles richtig zu machen UND Fehlermeldungen zu sehen, die dir weiter helfen können.
Ich glaube, exec fluxbox ist keine gute Idee.
Nimm /pfad/zu/fluxbox & und am liebsten, wie beschrieben in dieser xinitrc direkt eingetragen. Später spielt das dann eh keine Rolle mehr, was da steht, weil du dann deine localen Dateien nach Wunsch einrichtest.
Also, nicht, dass es nicht auch so gehen müsste, wenn dein Eintrag in der localen .xinitrc stimmt, aber es geht ja eben im Moment noch nicht bei dir und da rate ich zu eher Narrensicheren Methoden. Das soll nicht anzüglich gemeint sein, aber ich glaube, das brauche ich nun nicht mehr extra zu erwähnen.
Wenn du das ausprobiert hast, glaube ich, dass du Erfolgreich sein wirst ohne weitere Kniffe.
Vielleicht täusche ich mich aber und es funktioniert wirklich nicht mit deiner Graka.
Und deinem Monitor.
Ich glaube es zwar nicht, dass dieser Fehler so vom Monitor kommen kann, aber, wenn du mal einen anderen dran hängen kannst, wüssten wir es mit mehr Sicherheit. Vielleicht hat der monitor auch einen Auto-Setup und da könnte es helfen, den mal laufen zu lassen, während X läuft.
Hi Pit,
danke fürs feedback. Weil ich etwas in Eile bin und gleich los muss ein paar Antworten in Kurzfassung:
- es liegt definitiv nicht am Monitor
- es liegt definitiv nicht an fluxbox (siehe meine Erklärung mit Screenshots zuvor und überlege warum
- es liegt definitiv nicht an den Paketen, weil ich zuvor immer selbst gebaut hatte.
die von dir angesprochenen diversen Treiber hatte ich bereits getestet, auch den devel. Leider erfolglos. Mit den Treibern habe ich aber letztendlich nur 2 Tage rumgespielt, und sicherlich nicht ausgereizt. Hatte schon manuell mit dem neuen Xorg soweit mit KMS und DRM rumflicken müssen, das war nicht mehr schön. Die Treibergeschichte schaue ich mir mal bei Gelegenheit wieder an, aber ich denke ich hab da wirklich schon sehr viel zu diesem Thema (ATI Radeon mit meinem Chip) im Netz durchforstet. Hmm..wer weiß, vllt. findet sich ja noch der eine oder andere HInweis der zum Erfolg führen wird.
Hal und dbus werde ich mir bei Gelegenheit noch näher anschauen, zusammen mit noch einer andren Idee, die mir zwar nicht hilft das Problem zu lösen, aber weiter einzugrenzen.
Danke und einen schönen Abend,
Sloop.
danke fürs feedback. Weil ich etwas in Eile bin und gleich los muss ein paar Antworten in Kurzfassung:
- es liegt definitiv nicht am Monitor
- es liegt definitiv nicht an fluxbox (siehe meine Erklärung mit Screenshots zuvor und überlege warum
- es liegt definitiv nicht an den Paketen, weil ich zuvor immer selbst gebaut hatte.
die von dir angesprochenen diversen Treiber hatte ich bereits getestet, auch den devel. Leider erfolglos. Mit den Treibern habe ich aber letztendlich nur 2 Tage rumgespielt, und sicherlich nicht ausgereizt. Hatte schon manuell mit dem neuen Xorg soweit mit KMS und DRM rumflicken müssen, das war nicht mehr schön. Die Treibergeschichte schaue ich mir mal bei Gelegenheit wieder an, aber ich denke ich hab da wirklich schon sehr viel zu diesem Thema (ATI Radeon mit meinem Chip) im Netz durchforstet. Hmm..wer weiß, vllt. findet sich ja noch der eine oder andere HInweis der zum Erfolg führen wird.
Hal und dbus werde ich mir bei Gelegenheit noch näher anschauen, zusammen mit noch einer andren Idee, die mir zwar nicht hilft das Problem zu lösen, aber weiter einzugrenzen.
Danke und einen schönen Abend,
Sloop.
pit234a
Well-Known Member
...
- es liegt definitiv nicht an fluxbox (siehe meine Erklärung mit Screenshots zuvor und überlege warum
Sloop....
schon klar, hatte ich auch verstanden und gesehen. Manchmal bin ich wohl irgendwie stur...
Schönen Abend noch.
R
ralli
Guest
Sloop, wenn Du XFCE bevorzugst, das mit Freebsd 9 als Basissystem arbeitet, dann nimm doch einfach PC-BSD. Das habe ich mal ausprobiert, es funktioniert zufriedenstellend, aber leider hat mir die Performance jetzt nicht so gut gefallen, weil viele Dienste so weit automatisiert wurden, das ich das gesammte System als überfrachtet empfand. Natürlich kann nach der Installation auch eine Feinjustierung vorgenommen werden, aber es sollte doch irgendwie auch out of the box laufen, oder?
Nvidia und Ati GrakA werden automatisch erkannt und bereits als Auswahl bei der Installation angeboten und der entsprechende propertiäre Treiber automatisch installiert. Das funktioniert einwandfrei.
Der Nachteil ist, das ich ja nichts wirklich lerne, denn ich schau auch gerne hinter die Fassade.
Nachdem ich alle Desktops unter FreeBSD ausprobiert habe (Gnome, KDE, XFCE und LXDE) habe ich die Erfahrung machen dürfen, das leichtgewichtige WM für mich doch das Richtige sind, zumal ich ein Minimalist bin und außerdem Freude daran habe, mir ein individuelles System aufzubauen. Wer sich mit Fluxbox ein wenig beschäftigt, der merkt doch schnell, wie hochkonfigurierbar das ist. Schnell läßt es sich an die eigenen Bedürfnisse anpassen. Auch die Installation ist doch recht einfach. Hilfen dafür im Netz gibt es zahlreiche. Selber bevorzuge ich allerdings ein längst in die Vergessenheit geratenen WM, den mwm von Motif. Der ist unschlagbar schnell, und mehr als wie ein Startmenu brauche ich nicht, kein Firlefanz oder schmückendes Beiwerk, was zwar gut aussieht, aber ansonsten für mich keinen wirklichen Nutzen oder Mehrwert darstellt.
Nvidia und Ati GrakA werden automatisch erkannt und bereits als Auswahl bei der Installation angeboten und der entsprechende propertiäre Treiber automatisch installiert. Das funktioniert einwandfrei.
Der Nachteil ist, das ich ja nichts wirklich lerne, denn ich schau auch gerne hinter die Fassade.
Nachdem ich alle Desktops unter FreeBSD ausprobiert habe (Gnome, KDE, XFCE und LXDE) habe ich die Erfahrung machen dürfen, das leichtgewichtige WM für mich doch das Richtige sind, zumal ich ein Minimalist bin und außerdem Freude daran habe, mir ein individuelles System aufzubauen. Wer sich mit Fluxbox ein wenig beschäftigt, der merkt doch schnell, wie hochkonfigurierbar das ist. Schnell läßt es sich an die eigenen Bedürfnisse anpassen. Auch die Installation ist doch recht einfach. Hilfen dafür im Netz gibt es zahlreiche. Selber bevorzuge ich allerdings ein längst in die Vergessenheit geratenen WM, den mwm von Motif. Der ist unschlagbar schnell, und mehr als wie ein Startmenu brauche ich nicht, kein Firlefanz oder schmückendes Beiwerk, was zwar gut aussieht, aber ansonsten für mich keinen wirklichen Nutzen oder Mehrwert darstellt.
Tronar
aus Überzeugung altmodisch
Hallo, Sloop,
entschuldige, wenn ich etwas Triviales sage, aber hast Du Dir schon mal "man radeon" oder "man radeonhd" angeschaut und die dort aufgezählten Optionen? Mit deren Hilfe kannst Du alles mögliche deaktivieren und den Treiber in Minimalkonfiguration benutzen, dann sollte er am ehesten laufen. Mach mal sowas wie
und einiges Anderes. (Okay, die Beschleunigung ganz auf "none" zu setzen, ist nicht gerade das, wovon man als Benutzer träumt.) Versuch auch mal, in der Section "Module" Deiner xorg.conf verschiedene Extensions mit "Disable" auszuschalten, als z. B.
Wenn es in einer verkrüppelten Konfiguration mal läuft (zum Testen ist wohl Fluxbox am besten), dann schalte die Teile nacheinander wieder zu, bis Du den Übeltäter ausgemacht hast.
Bei AGP-Karten war es manchmal der Stabilität zuträglich, die AGP-Geschwindigkeit (2x, 4x usw.) herabzusetzen. Dafür gibt es im "radeon" die Treiberoption "AGPMode".
entschuldige, wenn ich etwas Triviales sage, aber hast Du Dir schon mal "man radeon" oder "man radeonhd" angeschaut und die dort aufgezählten Optionen? Mit deren Hilfe kannst Du alles mögliche deaktivieren und den Treiber in Minimalkonfiguration benutzen, dann sollte er am ehesten laufen. Mach mal sowas wie
Code:
Option "DRI" "false"
Option "AccelMethod" "none"
Code:
Disable "dri"
Disable "glx"
Disable "dbe"
Disable "record"Bei AGP-Karten war es manchmal der Stabilität zuträglich, die AGP-Geschwindigkeit (2x, 4x usw.) herabzusetzen. Dafür gibt es im "radeon" die Treiberoption "AGPMode".
Hi Tronar,
du wirst lachen, aber ich hatte mir nicht explizit die man von radeon angeschaut. Ich hatte schonmal aus anderen Forenpostings einige Werte ausprobiert, wußte nicht und kam aber nicht auf die Idee, dass es noch weitaus mehr Optionen gibt. Deinen Rat bin ich natürlich gleich gefolgt, und habe wirklich ALLE Optionen in den verschiedenen Schalterstellungen ausprobiert, natürlich war darunter auch die AGPMode und die verschiedenen Werte (1,2,4,8...) . Meine Ergebnisse soweit:
Es muss an der Beschleunigung liegen. Wenn ich mit "NoAccel" "true" die Beschleunigung deaktiviere, funktioniert es! Es muss also an der Acceleration-Schiene irgendwo liegen, oder an den Treibern/Modulen. Das war schonmal ein wichtiger Schritt, um näher an das Problem zu kommen. PS: du meinstest wohl mit Option "AccelMethod" "none" eher die Option "NoAccel" "true" nehme ich an, denn Option "AccelMethod" erlaubt nur die Werte "XAA" oder "EXA" (default). Wie auch immer, die beiden XAA oder EXA brachten auch keinen Erfolg,
Also habe ich die Beschleunigung erstmal wieder aktiviert indem ich die Zeile "Option" "NoAccel" entfernt habe. Daraufhin habe ich "Option "DRI" false" gesetzt, und siehe da es funktioniert. Das ist wieder eine Bestätigung mehr, dass es an der Acceleration, bzw. am DRI liegt.
Dann habe ich das mit dem kompletten Modul deaktivieren versucht. Laut 'man xorg.conf' überschreibt eine "Load"-Zeile den Wert einer "Disable"-Zeile, also musste ich erstmal die Zeile Load "dri" kommentieren, damit sie nicht in Kraft tritt, und dann explizit noch die Zeile hinzufügen Disable "dri". Damit wird dieses Modul "dri" definitiv nicht geladen vom xorg. Und so führt das wieder zum Erfolg, die Grafik passt. Dann habe ich DRI wieder eingeschaltet, und dafür dasselbe mit dem dri2 Modul gemacht, also dri2 ausgeschaltet. Kein Erfolg! Bedeutet also bis hierher, es liegt nicht am dri2-Modul. Also muss ich nun weitermachen, und das habe ich beginnend mit jedem einzelnen Modul alleine gemacht. Das heißt ,ich hab immer nur ein einziges Modul geladen indem ich alle anderen deaktiviert habe. Und dann schrittweise immer eins wieder dazuaktiviert. Das führte zum Ergebnis, dass nicht DRI der Übeltäter ist, sondern "GLX" (!). Sobald ich das Modul GLX deaktiviere, funktioniert alles einwandfrei. Funktioniert bedeutet: der Hintergrund ist grau schraffiert, und die Fensterleisten werden korrekt dargestellt, auch das Menü durch Mausklick funktioniert und ist sichtbar so wie erwartet. Ich habe übrigens nur Xorg installiert ohne fluxbox, das heisst ich teste mit dem default twm onboard.
Das ist doch schonmal ein Erfolg, den ich dank deines Hinweises erzielen konnte. Danke dir abermals !
Natürlich würde ich jetzt gerne wissen, welche Einschränkung ich durch das Deaktivieren von "GLX" hätte. Laut Wiki ist das eine Schnittstelle zwischen OpenGL und dem X. Wäre ja aber auch blöd, wenn das nicht vorhanden wäre, oder nicht? Gibt es eine Alternative, wie ich GLX durch etwas anderes ersetzen könnte und wenn ja, was und wie? Vielleicht könnt ihr mich mit mehr Infos füttern?
PS: Ich habe zu GLX noch in der xorg.conf manual page nachgesehen, und diese Optionen hier auch ausprobiert, indem ich GLX-Modul wieder aktiviert habe und dann abwechselnd und einzeln folgende Optionen probierte (ganz oben im Abschnitt ServerLayout):
Option "AIGLX" "true" (aber auch false) probiert
Option "DRI2" "true" (aber auch false) probiert.
Option "GlxVisuals" "typical" (aber auch minimal) probiert.
Leider brachten diese keinen Erfolg. Und dmesg |grep ATI oder dmesg |grep agp zeigte mir auch keine errors an, denn das AGP-Modul lade ich mit meiner /boot/default/loader.conf über die Zeile AGP_LOAD="yes". Also das AGP-Modul ist definitiv geladen und aktiv, sonst würde die dmesg Ausgabe irgendwelche AGP-Fehler bringen.
EDIT2:
Jetzt bin ich im Internet auf dieses Tutorial zu DRM gestossen. Dabei habe ich mal "dmesg |grep drm" oder einfachhalber einfach mal ein "tail -f /var/log/messages" abgesetzt und aktiv gehalten. Über ein andres Terminal (ttyv2) starte ich dann den X und ich erkenne jedesmal die Warn-/Fehlermeldung, die mir in die messages Datei geschrieben wird:
da gibt's also doch irgendein Problem, aber was?
Freue mich auf weitere Anregungen und Empfehlungen.
Danke und Grüße,
Sloop.
du wirst lachen, aber ich hatte mir nicht explizit die man von radeon angeschaut. Ich hatte schonmal aus anderen Forenpostings einige Werte ausprobiert, wußte nicht und kam aber nicht auf die Idee, dass es noch weitaus mehr Optionen gibt. Deinen Rat bin ich natürlich gleich gefolgt, und habe wirklich ALLE Optionen in den verschiedenen Schalterstellungen ausprobiert, natürlich war darunter auch die AGPMode und die verschiedenen Werte (1,2,4,8...) . Meine Ergebnisse soweit:
Es muss an der Beschleunigung liegen. Wenn ich mit "NoAccel" "true" die Beschleunigung deaktiviere, funktioniert es! Es muss also an der Acceleration-Schiene irgendwo liegen, oder an den Treibern/Modulen. Das war schonmal ein wichtiger Schritt, um näher an das Problem zu kommen. PS: du meinstest wohl mit Option "AccelMethod" "none" eher die Option "NoAccel" "true" nehme ich an, denn Option "AccelMethod" erlaubt nur die Werte "XAA" oder "EXA" (default). Wie auch immer, die beiden XAA oder EXA brachten auch keinen Erfolg,
Also habe ich die Beschleunigung erstmal wieder aktiviert indem ich die Zeile "Option" "NoAccel" entfernt habe. Daraufhin habe ich "Option "DRI" false" gesetzt, und siehe da es funktioniert. Das ist wieder eine Bestätigung mehr, dass es an der Acceleration, bzw. am DRI liegt.
Dann habe ich das mit dem kompletten Modul deaktivieren versucht. Laut 'man xorg.conf' überschreibt eine "Load"-Zeile den Wert einer "Disable"-Zeile, also musste ich erstmal die Zeile Load "dri" kommentieren, damit sie nicht in Kraft tritt, und dann explizit noch die Zeile hinzufügen Disable "dri". Damit wird dieses Modul "dri" definitiv nicht geladen vom xorg. Und so führt das wieder zum Erfolg, die Grafik passt. Dann habe ich DRI wieder eingeschaltet, und dafür dasselbe mit dem dri2 Modul gemacht, also dri2 ausgeschaltet. Kein Erfolg! Bedeutet also bis hierher, es liegt nicht am dri2-Modul. Also muss ich nun weitermachen, und das habe ich beginnend mit jedem einzelnen Modul alleine gemacht. Das heißt ,ich hab immer nur ein einziges Modul geladen indem ich alle anderen deaktiviert habe. Und dann schrittweise immer eins wieder dazuaktiviert. Das führte zum Ergebnis, dass nicht DRI der Übeltäter ist, sondern "GLX" (!). Sobald ich das Modul GLX deaktiviere, funktioniert alles einwandfrei. Funktioniert bedeutet: der Hintergrund ist grau schraffiert, und die Fensterleisten werden korrekt dargestellt, auch das Menü durch Mausklick funktioniert und ist sichtbar so wie erwartet. Ich habe übrigens nur Xorg installiert ohne fluxbox, das heisst ich teste mit dem default twm onboard.
Das ist doch schonmal ein Erfolg, den ich dank deines Hinweises erzielen konnte. Danke dir abermals !
Natürlich würde ich jetzt gerne wissen, welche Einschränkung ich durch das Deaktivieren von "GLX" hätte. Laut Wiki ist das eine Schnittstelle zwischen OpenGL und dem X. Wäre ja aber auch blöd, wenn das nicht vorhanden wäre, oder nicht? Gibt es eine Alternative, wie ich GLX durch etwas anderes ersetzen könnte und wenn ja, was und wie? Vielleicht könnt ihr mich mit mehr Infos füttern?
PS: Ich habe zu GLX noch in der xorg.conf manual page nachgesehen, und diese Optionen hier auch ausprobiert, indem ich GLX-Modul wieder aktiviert habe und dann abwechselnd und einzeln folgende Optionen probierte (ganz oben im Abschnitt ServerLayout):
Option "AIGLX" "true" (aber auch false) probiert
Option "DRI2" "true" (aber auch false) probiert.
Option "GlxVisuals" "typical" (aber auch minimal) probiert.
Leider brachten diese keinen Erfolg. Und dmesg |grep ATI oder dmesg |grep agp zeigte mir auch keine errors an, denn das AGP-Modul lade ich mit meiner /boot/default/loader.conf über die Zeile AGP_LOAD="yes". Also das AGP-Modul ist definitiv geladen und aktiv, sonst würde die dmesg Ausgabe irgendwelche AGP-Fehler bringen.
EDIT2:
Jetzt bin ich im Internet auf dieses Tutorial zu DRM gestossen. Dabei habe ich mal "dmesg |grep drm" oder einfachhalber einfach mal ein "tail -f /var/log/messages" abgesetzt und aktiv gehalten. Über ein andres Terminal (ttyv2) starte ich dann den X und ich erkenne jedesmal die Warn-/Fehlermeldung, die mir in die messages Datei geschrieben wird:
da gibt's also doch irgendein Problem, aber was?
Freue mich auf weitere Anregungen und Empfehlungen.
Danke und Grüße,
Sloop.
Zuletzt bearbeitet:
HURRRAAAAAA!!!! ICH HAB DEN WURM!!!! Juhuuuuuuuuuu!!! :-)
*FREU*JUBEL*IN_DIE_LUFT_SPRING*
Unglaublich aber wahr! Meine letzte dmesg Nachricht bin ich auf den Grund gegangen und mir überlegt warum der schreibt "WON'T FIT" (!) das hört sich an, als ob er zuwenig Speicher hätte. Also mein Gedanke, check mal das BIOS! UNd gesagt getan. Im BIOS war die Einstellung für AGP Aperture Size auf 128MB gestellt. Sobald ich diese auf 256MB erhöht habe (maximum möglich), funtkioniert es nun endlich mit der default xorg.conf, und dri und glx enabled, so wie es eben default ist.
GIGANTISCH!!!!
Da schraubt man soooooooooooooo lange am System rum, und letztendlich war's eine Hardwareeinstellung im BIOS. Hätte ich aber diese Fehlermeldung auf dmesg nicht entdeckt, wäre ich nie drauf gekommen. I LOVE X
Jetzt im Nachhinein bin ich natürlich sehr froh, mit diesem Problem konfrontiert worden zu sein, denn auf diese Weise habe ich so viel über den X gelernt, das ich normalerweise nie gelernt hätte.
Goooooott, bin ich jetzt endlich erleichtert. Das war ein Kampf, den ich ohne euch allen nie geschafft hätte. Nochmals ganz herzliches DANKESCHÖN an euch Allen, besonders an den letzten Tip von Tronar, der mich in diese Richtung lenkte
Der Tag ist gerettet.
PS: ich habe mit dem neuen Paketmanager XFCE4 jetzt installiert und schaut wunderbar aus, uuuf, eeeeeendlich :-)
*FREU*JUBEL*IN_DIE_LUFT_SPRING*
Unglaublich aber wahr! Meine letzte dmesg Nachricht bin ich auf den Grund gegangen und mir überlegt warum der schreibt "WON'T FIT" (!) das hört sich an, als ob er zuwenig Speicher hätte. Also mein Gedanke, check mal das BIOS! UNd gesagt getan. Im BIOS war die Einstellung für AGP Aperture Size auf 128MB gestellt. Sobald ich diese auf 256MB erhöht habe (maximum möglich), funtkioniert es nun endlich mit der default xorg.conf, und dri und glx enabled, so wie es eben default ist.
GIGANTISCH!!!!
Da schraubt man soooooooooooooo lange am System rum, und letztendlich war's eine Hardwareeinstellung im BIOS. Hätte ich aber diese Fehlermeldung auf dmesg nicht entdeckt, wäre ich nie drauf gekommen. I LOVE X
Jetzt im Nachhinein bin ich natürlich sehr froh, mit diesem Problem konfrontiert worden zu sein, denn auf diese Weise habe ich so viel über den X gelernt, das ich normalerweise nie gelernt hätte.
Goooooott, bin ich jetzt endlich erleichtert. Das war ein Kampf, den ich ohne euch allen nie geschafft hätte. Nochmals ganz herzliches DANKESCHÖN an euch Allen, besonders an den letzten Tip von Tronar, der mich in diese Richtung lenkte
Der Tag ist gerettet.
PS: ich habe mit dem neuen Paketmanager XFCE4 jetzt installiert und schaut wunderbar aus, uuuf, eeeeeendlich :-)
Zuletzt bearbeitet:
R
ralli
Guest
Ja Beharrlichkeit und Ausdauer zahlen sich aus und wurden belohnt. Glückwunsch auch von mir und viel Freude bei der Arbeit mit XFCE.
Tronar
aus Überzeugung altmodisch
Glückwunsch auch von mir! Das war wohl die härteste Nuß, an deren Lösung ich hier je mitwirken konnte. Und auf den letzten Schritt mit der AGP Aperture wäre ich dann selbst wohl nicht gekommen. Den Anmerkungen von ralli und Elwood kann ich nur zustimmen. Bei Deiner Hartnäckigkeit und Experimentierfreude bist Du bei BSD genau richtig! Da wirst Du noch viel Freude haben.
Naja, man muß das wohl als Bug in X ansehen, daß er da einfach hängenbleibt, statt mit einer vernünftigen Fehlermeldung auszusteigen.
Hattest Du eigentlich Linux-Erfahrung, bevor Du zu FreeBSD kamst?
Danke für die Blumen euch Allen das motiviert natürlich ungemein. Ja, ich komme aus der Linux-Ecke (Debian) und mache mit Linux seit 1,5 Jahren rum. Ich bin seeeeehr experimentierfreudig und egal was ich mit Computern tue, ich möchte immer soviel wie möglich verstehen, damit ich die Zusammenhänge erkennen kann. Dabei stelle ich -wie ihr sicherlich gemerkt habt- verdammt viele Fragen, und auch wenns euch nicht gleich auffällt: selbst wenn ich nerve, ihr helft mir durch eure Antworten sehr viel weiter. Mein Motto: wer nicht fragt, bleibt dumm. Gepaart mit meiner Neugier und der Bereitschaft alles auszuprobieren, gibt das immer Erfolge, da ich ungern aufgebe Deshalb freut es mich, dass dieses Problem aufgetreten ist. Dadurch bin ich zwangsweise dem BSD viel viel näher gekommen. Wobei ich mich selbst als Laie bezeichnen würde, wenn ich sehe wieviel tiefgründiges Wissen andere aus Foren haben. Aber mir gehts nicht darum mich zu vergleichen oder Wissen zu messen, sondern vielmehr darum es zu VERSTEHEN. Und BSD macht mir nun immer mehr Spass. Nun bin ich endlich soweit und überzeugt, dass es definitiv als OS installiert bleibt. Momentan habe ich meinen Desktop auch soweit aufgebaut, dass ich meine täglichen Arbeiten damit verrichten kann, sprich: Synergy mit Autostart zum Laufen gebracht, OpenVPN, usw... durch einen Nachbarthread bin ich auch auf den Raspberry Pi aufmerksam geworden, und jetzt lese ich sogar, dass NetBSD erfolgreich darauf läuft. Hab mir schon ein nächstes Projekt damit in den Kopf gesetzt, will mir ein Mediaplayer basteln und den Raspberry Pi in ein cooles designvolles Gehäuse passen (nein, keine Cherry-Tastatur! das wird dann ein Hingucker, so 'ne Art Möbelstück ) Was mir bisher an BSD ganz besonders gefällt ist: /etc/rc.d/ und /usr/local/etc/rc.d (als Beispiel). Ich glaube das ist dieser oft erwähnte Punkt --> strikte Trennung zwischen System und Userbereich. Gell? Mir gefällt das gesamte System an sich, es ist sowas von transparent, sehr simpel und einfach aufgebaut, ohne gross Schnickschnack drumherum. Ich hoffe dass ich weiterhin sehr viel Spass mit FreeBSD haben werde und hoffentlich werde ich auch Erfahrungen mit OpenBSD und NetBSD schon bald sammeln.
Nochmals an Alle, recht herzlichen Dank für eure Unterstützung und ein grosses "DAUMEN-HOCH" an das Forum. Es stimmt tatsächlich --> die BSD-Gemeinde ist sehr offen und freundlich. Weiter so!
Schönes Wochenende wünscht euch,
Sloop.
das motiviert natürlich ungemein. Ja, ich komme aus der Linux-Ecke (Debian) und mache mit Linux seit 1,5 Jahren rum. Ich bin seeeeehr experimentierfreudig und egal was ich mit Computern tue, ich möchte immer soviel wie möglich verstehen, damit ich die Zusammenhänge erkennen kann. Dabei stelle ich -wie ihr sicherlich gemerkt habt- verdammt viele Fragen, und auch wenns euch nicht gleich auffällt: selbst wenn ich nerve, ihr helft mir durch eure Antworten sehr viel weiter. Mein Motto: wer nicht fragt, bleibt dumm. Gepaart mit meiner Neugier und der Bereitschaft alles auszuprobieren, gibt das immer Erfolge, da ich ungern aufgebe Deshalb freut es mich, dass dieses Problem aufgetreten ist. Dadurch bin ich zwangsweise dem BSD viel viel näher gekommen. Wobei ich mich selbst als Laie bezeichnen würde, wenn ich sehe wieviel tiefgründiges Wissen andere aus Foren haben. Aber mir gehts nicht darum mich zu vergleichen oder Wissen zu messen, sondern vielmehr darum es zu VERSTEHEN. Und BSD macht mir nun immer mehr Spass. Nun bin ich endlich soweit und überzeugt, dass es definitiv als OS installiert bleibt. Momentan habe ich meinen Desktop auch soweit aufgebaut, dass ich meine täglichen Arbeiten damit verrichten kann, sprich: Synergy mit Autostart zum Laufen gebracht, OpenVPN, usw... durch einen Nachbarthread bin ich auch auf den Raspberry Pi aufmerksam geworden, und jetzt lese ich sogar, dass NetBSD erfolgreich darauf läuft. Hab mir schon ein nächstes Projekt damit in den Kopf gesetzt, will mir ein Mediaplayer basteln und den Raspberry Pi in ein cooles designvolles Gehäuse passen (nein, keine Cherry-Tastatur! das wird dann ein Hingucker, so 'ne Art Möbelstück ) Was mir bisher an BSD ganz besonders gefällt ist: /etc/rc.d/ und /usr/local/etc/rc.d (als Beispiel). Ich glaube das ist dieser oft erwähnte Punkt --> strikte Trennung zwischen System und Userbereich. Gell? Mir gefällt das gesamte System an sich, es ist sowas von transparent, sehr simpel und einfach aufgebaut, ohne gross Schnickschnack drumherum. Ich hoffe dass ich weiterhin sehr viel Spass mit FreeBSD haben werde und hoffentlich werde ich auch Erfahrungen mit OpenBSD und NetBSD schon bald sammeln.Nochmals an Alle, recht herzlichen Dank für eure Unterstützung und ein grosses "DAUMEN-HOCH" an das Forum. Es stimmt tatsächlich --> die BSD-Gemeinde ist sehr offen und freundlich. Weiter so!
Schönes Wochenende wünscht euch,
Sloop.
R
ralli
Guest
Danke für die Blumen euch Allen
Nochmals an Alle, recht herzlichen Dank für eure Unterstützung und ein grosses "DAUMEN-HOCH" an das Forum. Es stimmt tatsächlich --> die BSD-Gemeinde ist sehr offen und freundlich. Weiter so!
Schönes Wochenende wünscht euch,
Sloop.
Deine Einstellung ist goldrichtig und erfrischend lebendig und ich erkenne mich da auch selbst wieder. Diese Einstellung habe ich grundsätzlich auch, leider fehlt es mir manchmal an Geduld, aber ich arbeite daran.