VESA Konsole

Hayabuzza

Well-Known Member
Wer gerne mit der Konsole ohne X arbeitet, kann es mit vesa.ko kernelmodul versuchen.
- Es bring bessere Übersicht beim Systemen ohne X und SSH
- Schriften sehen besser aus, da besser an LCD Monitoren sichtbar

als Erstes muss man, die Option "options SC_PIXEL_MODE" in die Kernelkonfiguration einfügen und den Kernel neubauen sowie installieren.
siehe dazu http://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/kernelconfig.html

Zeile in der Kernelconfigfile /usr/src/sys/i386/conf/(MyKernelName)
bei amd64/usr/src/sys/amd64/conf/(MyKernelName)
options SC_PIXEL_MODE

als nächste muss man den Portsbaum um vesa Modul erweitern.
mehr Info dazu http://forums.freebsd.org/archive/index.php/t-6291.html
zum Patchen der Ports
cd /usr/ports
fetch ftp://ftp.lissyara.su/users/Guest/vesa-kmod.diff
patch -sp0 -i vesa-kmod.diff

nach dem die Ports das Vesa modul enthalten wechselt man das Verzeichnis
cd /usr/ports/misc/vesa-kmod

anschließend vesa.ko bauen
make install clean

damit werden im Verzeichnis /boot/modules/ entsprechende Module erstellt.

als nächstes muss man Verzeichnis /boot/modules zum laden beim start freigeben,
dazu fügt man in /boot/loader.conf folgende zeilen
module_path="/boot/modules;/boot/kernel"

und damit das Modul beim booten geladen wird noch in /boot/loader.conf
eingefügt

jetzt das System neustarten damit das Modul gestartet wird.
Nach dem Login als root sollte man jetzt überprüfen ob das Modul geladen wurde
es sollte vesa.ko und bei amd64 Systemen x86bios.ko angezeigt werden.

nun muss man den möglichen Monitormodis testen.
vidcontrol -i mode

es werden je nach Grafikkarte unterschiedliche Modis angezeigt,
jetzt sollte man das passende Modus für sich selbst aussuchen.
bei mir war es der Modus 283, der unterstütz ein Monitor 1280x1024 bei 24 Bit Farbe.
Um dem Modus zu testen sollte man sich in irgend einen anderen terminal mit STRG+ALT+F2 neu einlogen.
anschließend gibt man, dem zum testen gewünschten Modus ein, bei war es 283
vidcontrol MODE_283
wenn die Anzeige Fehler aufweist sollte man sich ein anderen Modi in neuen terminal aussuchen. Ist er einmal defekt kann man kaum was lesen.

Ist man mit dem Ergebnis zufrieden
fügt man in /etc/rc.conf
allscreens_flags="MODE_xxx"
Die xxx stehen für dem Modus der gut funktioniert hat.
Achtung Eingabe von falschen MODE Variablen kann bei dem nächsten Start zum bösen Überraschungen führen.

Nach dem nächsten Start werden alle Konsolen in VESA Modus in der gewählten Auflösung starten.
 
Zuletzt bearbeitet:
Zwei kleine Anmerkungen:
- In FreeBSD/amd64 9-CURRENT ist das alles gar nicht nötig, da dort der x86 BIOS Emulator und das neue VESA-Modul bereits teil des Systems sind. Einen MFC gab es bisher noch nicht, auch da man anscheinend auf Newcons und Eds DRI-Konsole wartet.

- Statt "module_path="/boot/modules;/boot/kernel"" zu setzen wäre es wohl sinnvoller /boot/kernel/vesa.ko einfach zu löschen. Sonst bricht man wunderschön POLA, was hier gerade eben drastische Auswirkungen (sprich ich musste eine Live-CD brennen) hatte.
 
Klingt toll, darauf warte ich schon lange. Aber ich werde jetzt zumindest noch weiter warten, bis es offiziell in den Ports ist.
 
Das hängt an syscons. Wie du sicher weißt, arbeitet Ed Shouten seit einigen Jahren daran, doch FreeBSD zu unicodeisieren ist ein Fass ohne Boden. Seine letzte große Aktion war, dass komplette utmp(5) Subsystem - verwaltet Logindaten - auszutauschen. Das hing damit irgendwie zusammen. Ausgetauscht wurde auch schon der TTY-Layer selbst und der Terminalemulator unterhalb von Syscons.
Was ich weiß, das muss aber nicht zwingend korrekt sein, ist der große Plan in etwa so, dass nun erst einmal der Unicode-Krams in die libc soll, der vor einiger Zeit im Rahmen des Google SoC entwickelt wurde. Anschließend kann man dann mal weitersehen.
Die VESA-Konsole sollte an sich ausreichend sein, nicht umsonst wurde der x86emu auf FreeBSD portiert, womit sie auch unter Plattformen abseits von i386 möglich wird. Es wurde aber auch schon diskutiert, ob man nicht alternativ gleich eine DRI-Konsole implementiert. Das hätte gewisse Vorteile, es wäre schneller und wenn eines Tages Kernelmodesetting und DRI-Speichermanager von Linux portiert sind könnte man Auflösungen frei wählen und Dinge ähnlich des DirectFB unter Linux machen. Fakt ist nur, dass Unicode so eine erweiterte Konsole braucht.
Das eigentliche Baby ist dann aber newcons. Wie der Name schon sagt ist es ein neuer Konsolentreiber, der Syscons - was immerhin 17 Jahre alt ist - ersetzen soll. Newcons ist vollständig unicodefähig. Er muss logischerweise der letzte Schritt sein. Das Einzige, was ich zu newcons weiß ist, dass er vor 9.0 fertig sein soll. Auf der FOSDEM war wohl ein Prototyp zu sehen, aber davon ist im Netz noch nichts weiter aufgetaucht.
 
Danke Yamagi für die ausführliche Info. Hatte auch zwischenzeitlich gelesen, daß es langsam vorangeht -> wie Du schon geschrieben hast: Fass ohne Boden :)
 
bei der 8-Releas kann man das teil mit
module_path="/boot/modules;/boot/kernel"
übersprinngen.


Was mir noch positiv aufgefallen ist, der VESA konsolenmodul wird von den X nicht gestört.
Bei linuxkernel geht die FB konsole meistens nicht mehr nutzbar wenn man den X gestartet hat.
 
Zwei kleine Anmerkungen:
- In FreeBSD/amd64 9-CURRENT ist das alles gar nicht nötig, da dort der x86 BIOS Emulator und das neue VESA-Modul bereits teil des Systems sind. Einen MFC gab es bisher noch nicht, auch da man anscheinend auf Newcons und Eds DRI-Konsole wartet.

x86 Bios emulator? Kannst du dazu (vielleicht an einem anderem Ort, da hier OT) etwas mehr erzählen?
 
Die ganze Geschichte ist gerade ins 8-STABLE geMFCt worden. STABLE-Nutzer können die VESA-Konsole daher ab sofort "out of the Box" nutzen, ohne irgendwas am System ändern zu müssen. Für RELEASE-Nutzer wird es dann in 8.1 enthalten sein. :)

Code:
  Date: Tue, 2 Mar 2010 02:56:55                                                
  From: Xin LI <delphij@FreeBSD.org>                                            
  To: src-committers@freebsd.org, svn-src-all@freebsd.org,                      
      svn-src-stable@freebsd.org, svn-src-stable-8@freebsd.org                  
  Subject: svn commit: r204546 - in stable/8: . lib share/man/man4              
      share/man/man4/man4.i386 sys/amd64/conf sys/compat/x86bios                
      sys/conf sys/contrib/x86emu sys/dev/atkbdc sys/dev/dpms   sys/dev/fb      
      sys/dev/pci sys...                                                        
                                                                                
  Author: delphij                                                               
  Date: Tue Mar  2 01:56:55 2010                                                
  New Revision: 204546                                                          
  URL: http://svn.freebsd.org/changeset/base/204546                             
                                                                                
  Log:                                                                          
    MFC x86emu/x86bios emulator and make previously i386 only dpms and vesa     
    framebuffer driver, etc. work on FreeBSD/amd64.                             
                                                                                
    A significant amount of improvements were done by jkim@ during the recent   
    months to make vesa(4) work better, over the initial code import.  This     
    work is based on OpenBSD's x86emu implementation and contributed by         
    paradox <ddkprog yahoo com> and swell.k at gmail com.                       
                                                                                
    Hopefully I have stolen all their work to 8-STABLE :)                       
                                                                                
    All bugs in this commit are mine, as usual.
 
So, funktioniert wie von i386 gewohnt, nur das die Vesa Emulation unter amd64 deutlich schneller läuft als unter i386 mit richtigem Vesa.
Da wäre es doch eine Überlegung Wert, Vesa unter i386 rauszuschmeißen und da auch auf die Emulationslösung zu setzen. Da frage ich miich gerade - wenn das Vesa nur emuliert ist, kann man dann nicht eigentlich auch Non-Vesa Auflösungen unterstützen? Die größte Vesa-Auflösung, die auf meinen Schirm passt ist 1024x768. Eine 1440x900 Konsole wäre da schon noch eine Nummer lustiger.
 
Hm, was genau heißt das jetzt für mich? Höhere Auflösungen mit GENERIC? Das wäre schön. Sonst auch noch was?
 
Brauche ich als aktueller RELENG_8 Nutzer jetzt noch das Modul aus den Ports?

Habs nämlich gerade mal ohne versucht, und das tut nicht
Code:
vidcontrol: cannot activate raster display: Inappropriate ioctl for device
VESA und x86bios sind aber drinn.
 
Du musst deinen Kernel noch mit
Code:
options SC_PIXEL_MODE
neubauen, denn im GENERIC ist es (derzeit) nicht drin. Danach wird es gehen.
 
Du musst deinen Kernel noch mit
Code:
options SC_PIXEL_MODE
neubauen, denn im GENERIC ist es (derzeit) nicht drin. Danach wird es gehen.

Was war denn nochmal genau der Sinn des Ganzen? Ich hab deinen anderen Artikel auch gelesen, aber es erschließt sich mir nicht. Früher musste ich am Kernel rumdoktern um Auflösungen zu kriegen, jetzt muss ich genau dasselbe machen. Was bringt das x86bios-Voodoo denn real für User?
 
Zurück
Oben