Questa parte del documento è stata donata molto gentilmente da Frederick A. Niles, che conserva tutti i diritti per le informazioni incluse in questa sezione dell'HOWTO.
L'obiettivo principale di questo documento è di introdurti all'avvio di una configurazione "dual head" [N.d.T.: ossia con due o più schede video] di Linux. Per quanto il processo sia piuttosto semplice, ci son molte cose che uno può sbagliare lungo il percorso.
L'esempio su cui mi concentrerò è l'avvio di un X-server su di un secondo monitor. L'ho trovata cosa simpatica in quanto si possono trovare vecchi, larghi monitor da 19" e 21" a frequenza fissa che la gente da via perché non può più utilizzarli. In questo modo puoi avviare una piccola multifrequenza e quindi usare X su un bel monitor grande.
Per favore tieni conto che il supporto per il dual head è attualmente in sviluppo, quindi queste informazioni cambiano rapidamente. Qualsiasi punto di questo documento può essere datato e semplicemente scorretto nel momento in cui lo stai leggendo.
** ATTENZIONE ** Questo documento è stato scritto prima di qualsiasi rilascio dell'XFree86 4.0. Se lo stai leggendo e l'XFree86 4.0 è già stato rilasciato molte cose possono essere cambiate. Prova ad ottenere una nuova versione di questo documento se disponibile.
Per questo documento, sarò molto lieto se sarò contattato. Senza i vostri suggerimenti e proposte, questo documento non esisterebbe. Per questo, inviatemi aggiunte, commenti e critiche a: Frederick.A.Niles@gsfc.nasa.gov. Frederick.A.Niles@gsfc.nasa.gov.
Le seguenti persone han contribuito a questo mini-HOWTO.
* Petr Vandrovec vandrove@vc.cvut.cz
* Andreas Ehliar ehliar@lysator.liu.se (x2x)
* Marco Bizzarri m.bizzarri@icube.it (X server multipli)
No liability for the contents of this document can be accepted. Use the concepts, examples and other content at your own risk. As this is a new edition of this document, there may be errors and inaccuracies that could be damaging to your system. Proceed with caution, and although this is highly unlikely, I don't take any responsibility for that.
[** Traduzione italiana **]
Nessuna responsibilità per il contenuto di questo documento sarà accettata. Utilizza i concetti, esempi ed altri contenuti a tuo proprio rischio. In quanto questa è una nuova edizione del documento, vi possono essere errori ed imperfezioni tali da danneggiare il tuo sistema. Procedi con cautela e, sebbene questo sia alquanto inverosimile, non mi prenderò alcuna responsabilità se ciò accadrà.
This section of the document is copyrighted (c)1999 Frederick Niles and distributed under the following terms:
* Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions.
* All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below.
* If you have questions, please contact, the Linux HOWTO coordinator, at linux-howto@sunsite.unc.edu
[** Traduzione italiana **]
Questa sezione del documento è copyright (c)1999 di Frederick Niles e distribuita sotto i seguenti termini:
* I documenti Linux HOWTO possono essere riprodotti e distribuiti in tutto o in parte, su qualsiasi mezzo fisico od elettronico, finché questa nota di copyright venga mantenuta su tutte le copie. Ridistribuzioni commerciali sono permesse ed incoraggiata; comunque, l'autore gradirebbe ricevere notifica di questo tipo di distribuzioni.
* Tutte le traduzioni, lavori derivati o includenti qualsiasi documento Linux HOWTO devono essere tutelate dalla stessa nota di copyright. Ossia, non puoi produrre un lavoro derivato da un HOWTO ed imporvi restrizioni addizionali alla sua distribuzioni. Eccezioni a queste regole possono essere garantiti sotto certe condizioni; per favore contatta il coordinatore degli HOWTO Linux all'indirizzo indicato più avanti.
* Se hai domande, per favore contatta il coordinatore degli HOWTO Linux presso linux-howto@sunsite.unc.edu
La maggior parte delle schede grafiche assume d'essere l'unica in un sistema e sono permanentemente impostate con l'indirizzamento dell'adattatore primario per lo schermo. Ci sono poche eccezioni.
* Schede Matrox: Queste includono le schede video Matrox Millennium, Matrox Millennium II, Matrox Mystique, Matrox Mystique 220, Matrox Productiva G100, Matrox Mystique G200, Matrox Millennium G200 e Matrox Marvel G200
* MDA: Questa include gli adattatori grafici monocromatici Hercules tra le altre. Questa è solo per un supporto testuale sul seconda uscita.
Nota: è solo il secondo adattatore a dover essere uno dei precedenti.
Questo mini-HOWTO principalmente riguarda il free software. Comunque, ci sono X server commerciali con incluso il supporto per il "multi-head". Tra questi Metro Link's (www.metrolink.com) Metro-X e Xi Graphics' (www.xig.com) Accelerated-X.
Hai bisogno dei seguenti patch e programmi:
* Il programma "fbset" prova:
http://www.cs.kuleuven.ac.be/~geert/bin/(nota: questo programma è incluso nella RedHat 6.0)
* "fbaddon", patch del Kernel Linux per dual head Matrox prova:
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/
* Il programma "con2fb" prova:
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/
* Il frame buffer server X11 XF86_FBDev. Lo si trova come componente standard di XFree86 3.3.1.
La prima cosa che dovrai fara sarà patchare una copia delle sorgenti di Linux con la patch "fbaddon". Quindi dovrai configurare il kernel ed attivare il supporto framebuffer. Se hai schede Matrox attiva il supporto per il driver unificato accelerato Matrox così come il tipo particolare di scheda in tuo possesso. Non attivare il supporto per il frame buffer VESA. Questo potrebbe causare un conflitto. Attiva (ovviamente) il supporto per il multi-head. Crea il kernel e riavvia.
Ora dovrai installare il programma "fbset" e leggere attentamente tutta la documentazione su come regolare le impostazioni. L'utilizzo di un file "/etc/fb.modes" è caldamente consigliato una volta che avrai deciso le tue impostazioni. Il programma fbset include uno script in Perl per convertire il tuo file XF86Config nelle impostazioni fb.modes. Ho incluso il mio script in octave/Bourne shell per convertire il tuo file XF86Config nelle Appendici A & B.
Ti deve prima diventare agevole l'utilizzo del device frame buffer su di un monitor, comprendendo ogni problematica che può spuntar fuori dal tuo impostare che non abbia nulla a che vedere col supporto per il multi-head. Questo può risparmiare un mucchio di grattamenti di testa successivamente.
Mi sto per concentrare nella mia spiegazione su come avviare X sul secondo schermo rendendo molte altre configurazioni semplicemente ed ovviamente presupposti della procedura stessa.
Compila il programma "con2fb". Se lo lanci senza alcun argomento otterrai il seguente messaggio per l'utilizzo:
"usage: con2fb fbdev console".
Quindi, un comando esemplificativo potrebbe essere "con2fb /dev/fb1 /dev/tty6" per spostare la console virtuale numero sei sul secondo schermo. Usa Ctrl-Alt-F6 per spostarti su tal console e vedere che per davvero spunta sul secondo schermo.
"fbset" regola le impostazioni solo sullo schermo in cui lo lanci. Per questo, dovrai fare attenzione ad usare la flag "-fb" sul secondo schermo. In particolare, se non altro probabilmente vorrai di impostare almeno la risoluzione virtuale verticale pari alla tua reale risoluzione verticale.
esempio "fbset -fb /dev/fb1 -vyres 600"
Questo rallenterà pesantemente la modalità testuale, ma X sarebbe sgradevole senza di questo.
Il file framebuffer.txt spiega questo meglio di quanto possa io, ma qui ci son due punti importanti.
Assicurati d'aver impostato il collegamento per "X" in modo che punti a "XF86_FBDev".
Quindi dovrai aggiungere una sezione "monitor" al tuo file XF86Config per il device frame buffer. Qui c'è un esempio:
# Il server Frame Buffer
Section "Screen"
Driver "fbdev"
Device "Millennium"
Monitor "NEC MultiSync 5FGp"
Subsection "Display"
Depth 8
Modes "default"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 16
Modes "default"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 24
Modes "default"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 32
Modes "default"
ViewPort 0 0
EndSubsection
EndSection
Utilizza le modalità di "default" in quanto non credo che qualsiasi altra possa funzionare con frame buffer per Matrox.
Imposta la variabile FRAMEBUFFER al secondo frame buffer.
"export FRAMEBUFFER=/dev/fb1"
oppure
"setenv FRAMEBUFFER /dev/fb1"
Dovrai avviare l'X server in modo che si combini con la profondità di colore selezionata e che appaia sullo stesso schermo da cui l'hai avviato.
esempio "startx -- :0 -bpp 16 vt06"
Questo esempio avvia un X "zero" sulla console virtuale sei con 16 bit di colore. Utilizzare ":1" all'avvio di un altro server X per l'altro frame buffer ti permetterà d'avere due server X avviati.
I passi necessari per avere un X server attivo su un secondo schermo possono essere riassunti come segue:
* Recuperare la patch del kernel, fbset e con2fb.
* Applicare la patch al kernel, configurare, ricompilare e riavviare.
* Aggiungere la sezione XF86_FBDev al file XF86Config ed impostare il collegamento per X.
Quindi, ad ogni riavvio:
* Spostare una console. es. "con2fb /dev/fb1 /dev/tty6"
* Regolare le impostazioni es. "fbset -fb /dev/fb1 1280x1024"
* Impostare la FRAMEBUFFER es. "export FRAMEBUFFER=/dev/fb1"
* Lanciare il server X es. "startx -- -bpp 16 vt06"
Puoi automatizzare tutto questo per ogni riavvio grazie ad un alias della shell. Dev'essere un alias e non uno script della shell in quanto deve rilevare il corrente numero della console. Questo è il mio alias per la C-shell per avviare X in un secondo monitor a frequenza fissa:
alias startxfb = " setenv FRAMEBUFFER /dev/fb\!*; # Imposta la var env all'arg del cmd. con2fb $FRAMEBUFFER /dev/$tty; # Sposta fb sulla corrente tty. fbset -fb $FRAMEBUFFER 1280x1024@62; # Favoriti da /etc/fb.modes startx -- :\!* -bpp 16 vt0`echo $tty | cut -dy f 2`' # X su questa tty. "
Nel mio file .cshrc questo è tutto sulla stessa riga senza commenti, ma è più facile da leggere con gli a capi e con i commenti inseriti. Devo semplicemente dare il numero del frame buffer come un argomento e partirà senza problemi.
Non son sicuro su come far lo stesso alias con la bash. Non so come determinare la corrente tty o passare l'argomento ad un alias con la bash. Se qualcuno me lo farà sapere l'aggiungerò qui. Comunque, puoi usare il comando "tty" per ottenere il nome della corrente VT a quindi semplicemente realizzare due alias separati per ogni server X.
* Sia "fbset" che "startx" DEVONO essere lanciati dallo stesso frame buffer poiché questi ne son soggetti. Questo pone seri limiti a come questi comandi possano essere automatizzati tramite script.
* XFree86 4.0 avrà un "corretto" supporto per più di un'uscita video, ma attualmente il 3.3.1 non ce l'ha. Puoi lanciare due server con 3.3.1 ed usare x2x per passare da uno all'altro, in ogni caso... (vedi il prossimo paragrafo)
* Il frame buffer inattivo tratterrà l'ultima immagine di quand'era attivo, nessun aggiornamento cioè avverrà.
* Il monitor che non è selezionato non sempre mantiene la sua condizione quando non è attivo. (Ma di solito lo fa.)
* Geert Uytterhoeven (il mantenitore del frame buffer) e Linus Torvalds non sono d'accordo con gli attuali cambiamenti al supporto per console multi-head detti "frame buffer per VT" (ossia fbaddon) quindi questi non saranno mai nel principale ramo del kernel. (Questo è stato sentito di terza mano e potrebbe essere clamorosamente falso.)
* Se "non rispetti le regole" ed avvii il server X (lanci "startx") da uno schermo differente, la macchina potrebbe eventualmente crashare in malo modo con gli input del mouse e della tastiera tutti mischiati tra loro.
* La documentazione framebuffer.txt nelle sorgenti del kernel spiega che puoi usare le impostazioni Modeline nel file XF86Config direttamente quanto lanci X. L'utilizzare il frame buffer per Matrox sembra forzare il server X a cestinarle tutte quante. Quindi puoi solo avere una ("predefinita") impostazione per volta (lo stesso che hai nella modalità testuale).
* Il XF86_FBDev non è accelerato. Comunque, ci son patch per il supporto per Matrox accelerato presso
http://www.in-berlin.de/User/kraxel/xfree86/
Non son ancora riuscito ad immaginarmi un modo per avviare nel livello 5 di init con una configurazione a doppio schermo (ed effettivamente avere il server su uno o l'altro degli schermi od entrambi). Mentre sembra abbastanza semplice aggiungere una riga al file dei server gdm/xdm, la costrizione di dover avviare il server X dallo stesso frame buffer impedisce alla soluzione banale di funzionare. Se qualcuno trova un modo per favore mi contatti per e-mail e l'aggiungerò qui.
Esiste un simpatico programmino chiamato x2x che passa in automatico da un server X all'altro quando si arriva al bordo dello schermo. L'ultima casa conosciuta di questo programma è:
http://ftp.digital.com/pub/DEC/SRC/x2x. Lo si trova anche tra i pacchetti opzionali della Debian. Non l'ho ancora provato, ma alcuni utenti han riferito d'averlo utilizzato con successo.
Esistono alcuni comandi linux che vale la pena ricordare quando si ha a che fare con una configurazione a più uscite (specialmente quando si scrivono script).
* "chvt" permette di passare da una console virtuale ad un'altra
* "openvt" lancia un programma in un nuovo terminale virtuale (VT).
* "tty" riferisce il nome del corrente terminale.
(notare l'impostazione bpp)
#!/usr/bin/octave -q
bpp = 16;
DCF = sscanf(argv(1,:), "%f");
HR = sscanf(argv(2,:), "%f");
SH1 = sscanf(argv(3,:), "%f");
SH2 = sscanf(argv(4,:), "%f");
HFL = sscanf(argv(5,:), "%f");
VR = sscanf(argv(6,:), "%f");
SV1 = sscanf(argv(7,:), "%f");
SV2 = sscanf(argv(8,:), "%f");
VFL = sscanf(argv(9,:), "%f");
pixclock = 1000000 / DCF;
left_margin = HFL - SH2;
right_margin = SH1 - HR;
hsync_len = SH2 - SH1;
# 3) regolazioni verticali:
upper_margin = VFL - SV2;
lower_margin = SV1 - VR;
vsync_len = SV2 - SV1;
RR = DCF / (HFL * VFL) *1e6;
HSF = DCF / HFL * 1e3;
printf("mode \"%dx%d\"\n",HR,VR);
printf(" # D: %3.2f MHz, H: %3.2f kHz, V: %2.2f Hz\n", DCF, HSF, RR);
printf(" geometry %d %d %d %d %d\n", HR, VR, HR, VR, bpp);
printf(" timings %d %d %d %d %d %d %d\n", ...
pixclock, left_margin, right_margin, ...
upper_margin, lower_margin, ...
hsync_len, vsync_len);
printf("endmode\n");
(Che richiama lo script in octave "cvtmode")
#!/bin/sh # Script della shell per convertire il file XF86Config in uno fb.modes. # Utilizza lo script in octave cvtmode.m if [ -z $1 ]; then FILE=/etc/X11/XF86Config else FILE=$1 fi i=1 LEN=`grep Modeline $FILE | wc -l` while expr $i \< $LEN > /dev/null ; do CURLINE=`grep Modeline $FILE | cut -d'"' -f 3-20 | head -$i | tail -1 ` ./cvtmode.m $CURLINE echo " " i=`expr $i + 1` done