X11/xorg problem

[hastifranki]

Wenn man vga=normal verwendet, sollte alles im Textmodus ablaufen. D.h., es wird gar kein Framebuffertreiber geladen. Erst wenn das X System geladen wird, wird auch ein Grafiktreiber geladen. Sollte es dann möglich sein, auf die Konsole mit z.B. Strg+Alt+F2 zu schalten, wird diese dann auch im Textmodus (ohne Framebuffertreiber) angezeigt. Für Testzwecke ist diese Vereinfachung bestimmt hilfreich.

mir ist ausserdem aufgefallen , dass der framebuffer überhaupt nicht auf startparameter reagiert . wenn ich eine auflösungsangabe wie "video=1280x1024-24@60" in verschiedenen variationen mache , bleibt die console trotzdem bei 1024x768 bei 60 hz .
wenn ich das manual finde werde ich noch ein paar andere parameter testen .

Soweit ich informiert bin, wird die Auflösung für die Konsole mit Framebuffer im Bootloader eingegeben. z.B. vga=795 für 1280x1024-24

Vielleicht ist bei gentoo alles doch etwas anders.

Viele Grüße
Frank

[auth.Gast]

jo das wär wirklich optimal mit "vga=normal " -zumindest bis das problem gelöst ist n

leider funktioniert der befehl wie gesagt nicht .

Soweit ich informiert bin, wird die Auflösung für die Konsole mit Framebuffer im Bootloader eingegeben. z.B. vga=795 für 1280x1024-24
Vielleicht ist bei gentoo alles doch etwas anders.

also das lliegt halt daran ,dass gentoo den vesafb-tng empfiehlt (standard) , nachdem er scheinbar auch besser zu bedienen ist , habe ich mich auch für den entschieden . wenn man direkt die gewünschte auflösung als parameter eingeben kann ,ohne erst in einer tabelle nachschauen zu müssen, ist das schon sehr praktisch .

hier mein kernelog

Code: Select all

Jun 18 18:57:38 hell kernel:  vesafb: pmi: set display start = c00ceca5, set palette = c00ced2a
Jun 18 18:57:38 hell kernel: [   83.949528] vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c70
3 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03
Jun 18 18:57:38 hell kernel: [   84.005195] vesafb: VBIOS/hardware doesn't support DDC transfers
Jun 18 18:57:38 hell kernel: [   84.005283] vesafb: no monitor limits have been set
Jun 18 18:57:38 hell kernel: [   84.005362] vesafb: scrolling: redraw
Jun 18 18:57:38 hell kernel: [   84.400237] Console: switching to colour frame buffer device 128x48
Jun 18 18:57:38 hell kernel: [   84.428815] vesafb: framebuffer at 0xd8000000, mapped to 0xd0900000, using 7
500k, total 131072k
Jun 18 18:57:38 hell kernel: [   84.429292] fb0: VESA VGA frame buffer device

und hier d mit knoppixt5 .0

Code: Select all

vesafb: framebuffer at 0xd8000000, mapped to 0xd0880000, using 3072k, total 131072k
vesafb: mode is 1024x768x16, linelength=2048, pages=1
vesafb: protected mode interface info at c000:ec60
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device

werde villeicht mal versuchen einen kernel mit anderem fbdevice zu kompilieren , auch wenn ich das schon lange nichtmehr gemacht habe . oder villeicht eine initrd benutzen und nur das modul kompilieren ? mal sehen

grüsse

[auth.Gast]

also mit "vesafb" framebuffer funktioniert scheinbar alles ganz normal bei einer xsession - wie schon in knoppix aus einer chroot-umgebung .

kein "vga" statement kommt einem "vga=normal" gleich, oder ?

habe zwar noch keine zeit gehabt , die dokumentation für den vesafb-tng durchzulesen ,
aber werde auf jedenfall noch versuchen mit den vielversprechenden parametern ihn doch noch auf meinem system zur zusammenarbeit mit xorg zu bewegen (wer weiss was xorg mit ihm anstellt ) - wär wirklich ärgerlich wenn das nicht klappt . alleine die vga-zahlentabelle ist einfach total ätzend


danke schon mal an alle die geholfen haben .

grüsse

[auth.Gast]

also nachdem der vesafb-tng ja anscheinend probleme bei mir hatte die EDID meines monitors auszulesen , habe ich die limits mit "video=vesafb:maxclock:wert,maxvf:wert,maxhf:wert" nach herstellerspezifikation festgesetzt.
jetzt werden meine anderen terminals auch nichtmehr mit undarstellbarer frequenz betrieben , wenn ich einen xorg-server starte

verstehe nur noch nicht ganz warum auf den konsolen mit selber auflösung und selber frequenz die horizontale bildausrichtung zuweit nach links verschoben ist . liegt das villeicht an der farbtiefe ?


grüsse

[Janka]

Nein, das liegt an der Einstellung in der Modedb. Die Bildposition wird innerhalb eines größeren Rahmens festgelegt. Der Monitor braucht ja schließlich am Ende der Zeile und des Bildes auch jeweils noch etwas Schwarzschulter und Sync.

Guck dir die Zahlen in /usr/src/linux/drivers/video/modedb.c an und basteln dann für X eine entsprechende Modeline -- ist einfacher, als die modedb im Kernel zu ändern.

Janka

[auth.Gast]

also die modline für X zu ändern kommt für mich nicht in frage ,
nachdem das bild unter windows genauso justiert ist und es damit auch
der optimalen einstellung entprechen dürfte (wenn es die geben sollte)

auf jedenfall ist mir wieder das tool fbset eingefallen , mit dem ich das framebufferbild jetzt auch perfekt justieren kann und ich auch die aktuellen timings auslesen kann .

die parameter "R" für reduced blanking , und "m" für 1,8% margin als bootcommand innerhalb der "video=" anweisung (so wie in der modedb.txt) beschrieben können leider irgendwie nicht verarbeitet werden und der framebuffer wird ganz deaktiviert .

jetzt müsste ich halt nur noch eine möglichkeit finden die framebuffertimings als parameter in der cmdline mitzugeben , damit der fb auch automatisch wie gewünscht eingestellt wird (automatische ausführung von "fbset" beim start wär mir zu monitorlastig) .wüsste allerdings nicht wie ich das machen sollte - geht anscheinend garnicht

also müsste ich wohl selber eine option innerhalb der modedb.c mit den
gewünschten timings plazieren , die dann auch garantiert über einen bootparameter ausgewählt wird ... kann eigentlich garnicht programmieren

was mich allerdings ziemlich wundert ist , dass selbst bei exakt denselben bildschirmtimings das bild doch unterschiedlich positioniert wird . hatte z.b. mit dem "nv" treiber ein verschobenes bild nach rechts und jetzt mit genau denselben timings und "nvidia" treiber ist alles optimal eingestellt...irgendwie ziemlich unlogisch .
die optimalen framebuffertimings weichen auch sehr stark von dem wert unter X ab , aber da ist es noch verständlicher ...


grüsse

.

[Janka]

Vermutlich ignoriert der nvidia-Treiber die Einstellungen einfach, der nv-Treiber hält sich dran.

Man kann einfach durch passendes Kopieren und Ändern einer Zeile in der modedb.c neue Videomodi hinzufügen. Dann Kernel kompilieren. Ich habe das hier beim einem Rechner auch gemacht, weil ich da 'nen alten Festfrequenzmonitor benutze.

Janka