(Teilweise gelöst per Framebuffer) Netbook - 1024x600 - Openchrome Treiber - Problem : Nur 1280x800

[chr200221]

Ja, immer das selbe Ergebnis.

Ich habe es mit einem Live System probiert.
Dann dem aktuellen Debian Image und jetzt das aktuelle Kali Image.

Es ist immer auf 1280x800

[chr200221]

Ok,

vergessen wir dieses dämliche X. Kein Klicki Bunti, keine Fenster.

Wie kann ich wenigstens die Textconsole auf eine bessere Auflösung bekommen. Vielleicht später dann mit Mauscursor. Aber erstmal iwie die Konsole auf der Schrottmühle brauchbar bekommen.

Das X System werde ich komplett entfernen. Das habe ich auf einem anständigen Laptop mit normalem Display und Geforce GTX sauber am laufen. Der kleine Laptop soll dann zumindest auf der Console brauchbar sein.


Ok,

Framebuffer geht auch nicht.

Modprobe viafb führt dazu, dass der Bildschirm einfach schwarz wird. FBset hat keine wirkung.
rmmod viafb bringt die displayanzeige nicht zurück. Per Shell kann ich ja die Befehle eingeben. Die SSH Shell bleibt erreichbar.

Ich glaube ich werde das Teil morgen zum Wertstoffhof schaffen. Das Gerät ist absolut unbrauchbar, weil einfach nichts mehr darauf funktioniert. Ausser vllt steinalte Distros, die man niemals updaten darf.


EDIT:

Aufgegeben. Ich mache einen neuen Post betreffend Framebuffer ohne Klicki Bunti.

[hikaru]

Nochmal zurück zur ASCII-Grafik:
Vielleicht kriegen wir nicht den Framebuffer klein, aber den nutzbaren Desktop-Bereich mit Hilfe von Panels. Ich hatte das vorhin unter Buster/Xfce probiert. Wenn man unten und rechts je ein richtig fettes Xfce-Panel hinlegt, kann man den nutzbaren Bereich auch so verkleinern.
Ich hatte das vorhin deshalb nicht gepostet, weil du unten 200 und rechts 256 Pixel loswerden musst. Der Xfce-Dialog für die Paneldicke erlaubt aber maximal 128 Pixel pro Panelzeile und mehrzeilige Panel reservieren keinen Platz mehr. Ich vermute, das wäre leicht zu patchen und du scheinst nicht erst seit gestern Linux zu nutzen.

Zur Info: Lxpanel kann maximal 200, das Mate-Panel 120 Pixel.

[chr200221]

Ich nutze Linux zwar schon eine ganze Zeit, aber da gibts noch sehr sehr viel zu lernen

Das X Windows würde ich jetzt einfach aufgeben und mehr Energie in die Framebuffer Console stecken. Aber selbst die bekomme ich nicht ans Laufen. Keine Ahung was ich da noch probieren soll.
Zudem habe ich nicht viel Ahnung, wie man die FB Console einrichten muss.

Aber würde die funktionieren, wäre ich schon zufrieden. Man kann so auch zumindet mal ein JPG öffen oder den Inhalt von PNGs überprüfen.

[MSfree]

Ich nutze Linux zwar schon eine ganze Zeit, aber da gibts noch sehr sehr viel zu lernen

Das X Windows würde ich jetzt einfach aufgeben und mehr Energie in die Framebuffer Console stecken. Aber selbst die bekomme ich nicht ans Laufen. Keine Ahung was ich da noch probieren soll.
Zudem habe ich nicht viel Ahnung, wie man die FB Console einrichten muss.

Aber würde die funktionieren, wäre ich schon zufrieden. Man kann so auch zumindet mal ein JPG öffen oder den Inhalt von PNGs überprüfen.

Warum?

Ich würde wirklich mal nomodesetting in die Datei /etc/default/grub in die Zeile

Code: Alles auswählen

GRUB_CMDLINE_LINUX=""

folgedermassen eintragen:

Code: Alles auswählen

GRUB_CMDLINE_LINUX="nomodesetting"

und danach

Code: Alles auswählen

update-grub
reboot

ausführen.

Vielleicht klappt es ja dann auch mit der Auflösung unter X11.

[detix]

Wie sieht das Bild denn mit einfacher Skalierung aus?

Code: Alles auswählen

xrandr --output FP-1 --scale 0.8x0.75 # entweder so,
xrandr --output FP-1 --scale 1.25x1.333 # oder so
xrandr --output FP-1 --scale 1.0x1.0 # zurücksetzen

[KP97]

@chr200221
Die mit cvt erstellte Modeline heißt "1024x600_60.00". Das muß auch exakt so mit --add-modeline angegeben werden. Ebenso muß auch die Monitorbezeichnung genau stimmen.
Zur Sicherheit nochmal mit xrandr abfragen (mal ohne verbose).
In Deiner xorg.conf könntest Du es auch mal in der Monitor-Sektion mit den nachfolgenden Optionen probieren:

Option "UseEDID" "false"
Option "UseEDIDFreqs" "false"
Option "IgnoreEDID" "true"

So schnell geben wir nicht auf...

[chr200221]

Finde ich klasse, dass Ihr mir da helfen wollt Danke hierfür

Leider hat weder das ändern der Grub Cmdline mit "nomodesetting"
noch die Skalierung per xrandr zum Erfolg geführt.

Die Erstellung des neuen Modes mit der Modeline von cvt hat auch nicht funktioniert. Xrandr wirft den selben Fehler. Habe die Werte nochmals gecheckt.

Das Grafische Menü in GRUB war auch auf 1280x800 eingestellt. Das konnte ich aber ändern und in Grub wird es jetzt richtig mit 1024x600 angezeigt.
Da verstehe ich nicht, warum nichtmal der Framebuffer auf der Shell funktioniert.

Auch mit der CMDline "video=viafb:viafb_mode=1024x768,viafb_bpp=32,viafb_refresh=85" in Grub habe ich keinen Erfolg.
Die Konsolen Auflösung ändert sich nicht. Es ist dann auch kein /dev/fb0 vorhanden.

Wenn ich aber "modprobe viafb" verwende, dann kann ich ein /dev/fb0 finden. Aber sobald ich viafb lade wird der Bildschirm schwarz und ein rmmod bringt dann auch nichts mehr. Per SSH komme ich noch drauf und kann sauber rebooten.

vga=0x203 in der CMDline führt zu einem booten mit schwarzem Bildschirm. Soll ich das Teil nicht doch lieber wegwerfen ?

[debianoli]

Hallo zusammen,

ich habe ein Problem mit dem X-Server nachdem ich ein Dist Upgrade gefahren habe. Debian 9 > 10.
Auf dem Netbook läuft Kali Linux. Aber da man sich dort nicht registieren kann, versuche ich es mal hier. Kali basiert auf Debian. Ich denke ohnehin, dass es ein Dist unabhängiges Problem ist und direkt mit dem X Server zusammenhängt.

Installier dir doch ein Debian 9 auf dem Teil, Wenn das läuft, kannst du zB den Kernel und den Xserver auf hold setzen und dann nur bestimmte Teile des Systems upgraden.

[Tintom]

Das konnte ich aber ändern und in Grub wird es jetzt richtig mit 1024x600 angezeigt.

Wenn das funktioniert kannst du die GRUB-Option GRUB_GFXPAYLOAD_LINUX=keep setzen. Die gefundene Auflösung wird dann an den Kernel übergeben.
GRUB benutzt übrigens VESA, vielleicht hat das Modul vom VIA-Framebuffer einfach einen Bug.

[KP97]

Die Erstellung des neuen Modes mit der Modeline von cvt hat auch nicht funktioniert. Xrandr wirft den selben Fehler. Habe die Werte nochmals gecheckt.

Das kann ich mir nun überhaupt nicht vorstellen. Eine neue Modeline über xrandr funktioniert immer (wenn man es richtig macht).
Du gibst uns aber leider nicht die gewünschten Infos.

Versuchen wir es also nochmal, diesmal mit Vorgabe der Befehle. Auf meinem 27" Monitor macht das letztliche Zuordnen natürlich keinen Sinn,
aber die Ausgabe ist ja auch nur eine Anleitung für Dich.
Infos:
Mein Monitor heißt DP1, da mußt Du Deinen Namen FP-1 eingeben.
Die von Dir genannte Fehlermeldung erscheint nur, wenn die Modeline schon vorhanden ist. Eine zweite gleichen Namens läuft also nicht.
Du könntest diese aber mit --rmmode löschen und nochmal eine neue anlegen. Nachzulesen in man xrandr.
Führe das bitte als User im Terminal genauso aus und poste den Befehl nebst Ausgabe von Deinem Gerät.

MB@MB:~$ gtf 1024 600 60

# 1024x600 @ 60.00 Hz (GTF) hsync: 37.32 kHz; pclk: 48.96 MHz
Modeline "1024x600_60.00" 48.96 1024 1064 1168 1312 600 601 604 622 -HSync +Vsync

MB@MB:~$ xrandr --newmode "1024x600_60.00" 48.96 1024 1064 1168 1312 600 601 604 622 -HSync +Vsync

MB@MB:~$ xrandr --addmode DP1 "1024x600_60.00"

Zur Kontrolle

Code: Alles auswählen

xrandr

ausführen.
Die neue Modeline erscheint unten als letzte Zeile.

MB@MB:~$ xrandr
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
DP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 600mm x 340mm
1920x1080 60.00*+ 71.91 50.00 59.94
[......]
720x400 70.08
1024x600_60.00 60.00

Nun zuordnen mit

Code: Alles auswählen

xrandr -s 1024x600_60.00

Was war mit den Optionen edid für die xorg.conf? edid berechnet die Bildschirmabmessungen, evtl. ist das fehlerhaft.

Ansonsten hat @debianoli einen guten Vorschlag gemacht.
Du wirst doch das Gerät nicht entsorgen für so eine Kleinigkeit, das tut ein Linuxer nicht!
Du weißt doch, viele Wege führen nach Rom...

[chr200221]

Mit GRUB_GFXPAYLOAD_LINUX=keep konnte ich schonmal die FB Console in Gang setzen. Ich bekomme /dev/fb0.

fbset zeigt mir eine Auflösung von 1024x600@75

75 wundert mich, ich war mir sicher, dass es 60 HZ waren. Die xorg.conf war vom bestehenden System.
Mit 75HZ funktioniert aber die FB Console und ich habe anständigen lesbaren Text auf der Commandline.

Wenn option "keep" übergeben wird, dann wirft Xorg einen Fehler Kann den Framebuffer nicht mappen und findet keine Screens mit passender Config.

https://nopaste.debianforum.de/41423

Da ich jetzt auf diese 75 Hertz statt 60 gestossen bin, habe ich die "keep" im Grub wieder rausgenommen und das System wie vorher gebootet.

Jetzt habe ich die xrandr config nochmal mit 75 HZ probiert

Code: Alles auswählen

┌──(christian㉿onemini)-[~]
└─$ cvt 1024 600 75

# 1024x600 74.82 Hz (CVT) hsync: 47.06 kHz; pclk: 62.50 MHz
Modeline "1024x600_75.00"   62.50  1024 1072 1176 1328  600 603 613 629 -hsync +vsync

┌──(christian㉿onemini)-[~]
└─$ xrandr --newmode "1024x600_75.00"   62.50  1024 1072 1176 1328  600 603 613 629 -hsync +vsync


┌──(christian㉿onemini)-[~]
└─$ xrandr

Screen 0: minimum 320 x 200, current 1280 x 800, maximum 2044 x 2048
VGA-1 disconnected (normal left inverted right x axis y axis)
FP-1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1280x800      59.81*+
  1024x600_75.00 (0x52e) 62.500MHz -HSync +VSync
        h: width  1024 start 1072 end 1176 total 1328 skew    0 clock  47.06KHz
        v: height  600 start  603 end  613 total  629           clock  74.82Hz

┌──(christian㉿onemini)-[~]
└─$ xrandr --addmode FP-1 "1024x600_75.00"

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  18 (RRAddOutputMode)
  Serial number of failed request:  25
  Current serial number in output stream:  26
┌──(christian㉿onemini)-[~]
└─$

Xrandr steigt wieder mit dem selben Fehler aus. Das genau selbe habe ich aber auch mit 60 HZ probiert.

Die Befehle sind wirklich korrekt. Ich habe sie mehrfach kontrolliert und 1:1 übernommen. Ich habe es mit den Modelines von cvt und GTF probiert.
Habe auch die Modelines von gtf und cvt direkt in der xorg.conf probiert. Mit option keep, kann er den FB nicht mappen und findet keine screens mit passender config.

Ohne Option keep, wird wieder die Auflösung von 1280x800 genommen und die Modeline wird ignoriert.

Aber zumindest habe ich schonmal die Option auf eine FB Console.

[Tintom]

Mit GRUB_GFXPAYLOAD_LINUX=keep konnte ich schonmal die FB Console in Gang setzen. Ich bekomme /dev/fb0.

Schön, darauf kann man aufbauen. Hast du mal die Vorschläge von @KP97 ausprobiert?

Option "UseEDID" "false"
Option "UseEDIDFreqs" "false"
Option "IgnoreEDID" "true"

So schnell geben wir nicht auf...

Ich habe weiterhin das Xorg-Modul im Verdacht. Wenn die Auflösung der Framebuffer-Konsole übernommen wird, die Modelines von xrandr aber ignoriert werden, könnte man noch das hier probieren:

Option VBEModes boolean
Enables the use of VBE BIOS calls for setting the display mode. This mimics the behaviour of the vesa driver but still provides acceleration and other features. This option may be used if your hardware works with the vesa driver but not with the openchrome driver. It may not work on 64-bit systems. Using "VBEModes" may speed up driver acceleration significantly due to a more aggressive hardware setting, particularly on systems with low memory bandwidth. Your refresh rate may be limited to 60 Hz on some systems.

Grub greift beim Setzen der Auflösung auf diese VBE-Modes zurück, die Hoffung wäre jetzt, dass durch die Option Xorg die Auflösung einfach übernimmt. Du müsstest dazu der Device-Section von xorg dann Option VBEModes true setzen.

[chr200221]

Auch das führte nicht zum Erfolg.

Aber, die FB Console funktioniert und ich kann damit arbeiten. Sogar Maus support funktioniert auf Anhieb mit gpm.


Ich werde das so lassen. Zudem braucht die Kiste deutlich weniger Ram als mit dem X Windows System. (300 MB mehr freier RAM bei 1024 Total Ram)

Leider ist das Einrichten von X immernoch ein riesen geschiss, wenn man keine Standard Hardware hat. Vor ein paar Jahren war es auch mit geläufiger Hardware ein Graus.

Also ich werde das Klicki Bunti aufgeben. Zudem ist das eh besser um mehr Linux zu lernen. Die Möhre bootet so natürlich deutlich schneller. Jetzt werde ich mich erstmal um die Netzwerk Settings kümmern um zu lernen, wie man da einfach ein neues Wlan verbindet. Network Manager ist mir schonmal ein Begriff.

Die Kiste wandert jedenfalls nicht auf den Schrott, die ist so echt brauchmar. Per SSH kann ich meine VPS verwalten. Das ist ideal für den Urlaub, weil Handy ist einfach (sorry) Scheisse. Ich hasse Touch

[KP97]

Xrandr steigt wieder mit dem selben Fehler aus. Das genau selbe habe ich aber auch mit 60 HZ probiert.

Warum weigerst Du Dich eigentlich standhaft, mal die Ausgabe von xrandr -ohne weitere Optionen- zu zeigen? Dann könnte man nämlich sehen, welche Modelines systemmäßig vorhanden sind.
Ich hatte zuvor schon geschrieben, daß die Fehlermeldung nur auftaucht, wenn man eine bereits vorhandene Modeline neu mit gleichem Namen anlegen will.

Das motiviert die Helfer nicht sonderlich...

[chr200221]

Ah, sorry hatte ich vergessen.

Habe die vorhandenen Modelines überprüft, bevor ich die neue hinzugefügt habe. Ich kann die Modeline hinzufügen, aber nicht auf FP-1 zuweisen. Dann kommt die oben genannte Fehlermeldung.

Code: Alles auswählen

┌──(christian㉿onemini)-[/etc/X11]
└─$ xrandr

Screen 0: minimum 320 x 200, current 1280 x 800, maximum 2044 x 2048
VGA-1 disconnected (normal left inverted right x axis y axis)
FP-1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1280x800      59.81*+

┌──(christian㉿onemini)-[/etc/X11]
└─$ 

[Tintom]

Auch das führte nicht zum Erfolg.

Und in der Xorg.0.log steht dann was genau?

[chr200221]

Xorg gibt dann dieses Log aus :

https://nopaste.debianforum.de/41423


Wenn "keep" in Grub aktiv ist.

[Tintom]

Wie sieht die xorg.conf zu der o.g. Xorg.0.log aus?

[baeuchlein]

Zwei Dinge, die mir so aufgefallen sind:

1. Wenn der Framebuffer (für die Konsole) schon mal läuft, könnte man auch versuchen, über die xorg.conf den Treiber fbdev (statt des Openchrome-Treibers) für X.Org zu benutzen. fbdev setzt sich normalerweise auf einen (nahezu) beliebigen Framebuffer-Support "oben drauf". Könnte helfen, wenn der Chrome-Treiber für X nicht "will".

2. Die 1024x600 tun's laut einer hier im Thread verlinkten Datei aus der Kernel-Dokumentation lediglich am LCD-Anschluss der Chrome-Hardware, nicht aber an VGA oder DVI. Vielleicht ist dieses Panel tatsächlich nicht an LCD, sondern DVI dran. Oder aber irgendwas im Treiber glaubt, am verwendeten Anschluss ginge 1024x600 nicht, und stellt sich deswegen quer.

Im Augenblick würde ich aber auch erst mal den bereits im Thread aufgeführten Anregungen/Ideen nachgehen. Falls das dann nix bringt, kann man die zwei Punkte hier immer noch "abklappern".

[chr200221]

Wie sieht die xorg.conf zu der o.g. Xorg.0.log aus?

Ich habe mal einen neuen Run gemacht, weil ich mir nicht mehr sicher bin, welches log zu welcher conf gehört

Code: Alles auswählen

section "device"
        identifier      "device1"
        vendorname      "VIA Technologies, Inc."
        boardname       "VIA Chrome9-based cards"
        driver          "openchrome"
        option          "dpms"
        option          "forcepanel"
        option          "active device" "LCD,CRT"
        option          "panelsize" "1024x600"
        Option          "VBEModes" "true"
        option          "swcursor"
endsection

section "monitor"
        identifier      "FP-1"
        vendorname      "generic"
        modelname       "flat panel 1024x600"
        horizsync       31.5-55
        Option "UseEDID" "false"
        Option "UseEDIDFreqs" "false"
        Option "IgnoreEDID" "true"
        vertrefresh     40-70
        Modeline "1024x600_75.00"   62.50  1024 1072 1176 1328  600 603 613 629 -hsync +vsync
endsection

section "screen"
        identifier      "screen1"
        device          "device1"
        monitor         "FP-1"
        defaultcolordepth 24
        subsection      "display"
                depth   24
                modes   "1024x600"
        endsubsection
endsection

Generiert dieses log : (GFX_PAYLOAD_LINUX="keep" in GRUB)

https://nopaste.debianforum.de/41429


Der Tip von baeuchlein mit dem fbdev treiber hat funktioniert
Mit diesem Treiber wird der Bildausschnitt richtig angezeigt.
Die Xorg.conf ist identisch mit der obigen, nur als Treiber ist "fbdev" eingetragen.

[baeuchlein]

So weit, so gut.

Bei der Benutzung des fbdev-Treibers habe ich zwei Nachteile gesehen:

1. Auch der fbdev-Treiber kann Bugs/Probleme haben. Bei mir arbeitet er nicht gut mit dem uvesafb-Framebuffer zusammen; beim Wechsel vom laufenden X zur (Framebuffer-)Konsole und wieder zurück beendet sich X. Eventuell nicht gespeicherte Dinge in laufenden Programmen unter X sind dann futsch. (Abhilfe hier: VESA-Treiber für X benutzen.)

2. Es ist möglich, dass nur ein Teil einer eventuellen Hardware-Beschleunigung der Grafikkarte noch an X "durchgereicht" wird. Könnte v.a. für PC-Spiele unter Linux ein Problem sein.

Aber mit ein Bißchen Glück treten diese Probleme vermutlich nicht in Erscheinung.

[chr200221]

Ich probiere es jetzt mal so und teste was in bestimmten Situationen passiert.

Spielen tut ich eh nicht auf der Möhre, ich brauche die nur dafür, um meine VPS zu Not ausm Urlaub zu managen. Ich habe eine Pokemon Go Map für unsere Stadt am Laufen und da muss man ab und an mal ran, wenns hakt.