XWindow

Ici tout plein de brol sur X.

Plusieurs moniteurs

Configuration

Tout se passe dans xorg.conf.

Deux 'Section "Device"'

On définit 2 'Section "Device"', une par carte vidéo Si on a une seule carte avec 2 sorties, ce sont deux sections quasiment identiques, la seule différence c'est qu'on ajoute :

• "Screen 0" à l'une
• "Screen 1" à l'autre (et évidemment il faut des Identifiers différents)

Exemple :

# AGP card divided into 2 virtual devices :
Section "Device"
   Identifier  "Geforce - VGA"
   VendorName  "nVidia Corporation"
   BoardName   "NVIDIA GeForce FX 5500"
   Driver      "nvidia"
   Screen      0
   BusID       "PCI:1:5:0"
   Option      "NoLogo"    "True"
EndSection
Section "Device"
   Identifier  "GeForce - DVI"
   VendorName  "nVidia Corporation"
   BoardName   "NVIDIA GeForce FX 5500"
   Driver      "nvidia"
   Screen      1
   BusID       "PCI:1:5:0"
   Option      "NoLogo"    "True"
EndSection

Attention, avec les cartes nvidia, les options suivantes sont parfois nécessaires dans la section device

Option "UseDisplayDevice" "DFP"

ou

Option "UseDisplayDevice" "CRT"

Elle indiquent au driver de quelle sortie vidéo on parle. Il semble qu'il choisisse lui même sinon. Voir LA pour de plus amples informations.

Deux 'Section "Monitor"'

une pour chaque écran. Exemple :

Section "Monitor"
   Identifier "HP P1110"
   HorizSync   29-121
   VertRefresh 50-180
   Option      "DPMS"
EndSection
Section "Monitor"
   Identifier   "Flatron 795FT"
   HorizSync    30.0 - 96.0
   VertRefresh  50.0 - 160.0
   Option       "DPMS"
EndSection

Deux 'Section "Screen"'

• l'une utilise un des 2 device et un des 2 écrans
• l'autre utilise les 2 trucs restants

Exemple :

Section "Screen"
   Identifier	"Screen - VGA"
   Device		"GeForce - VGA"
   Monitor		"Flatron 795FT"
   DefaultDepth	24
   SubSection "Display"
       Depth		24
       Modes		"1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
   EndSubSection
EndSection
Section "Screen"
   Identifier	"Screen - DVI"
   Device		"GeForce - DVI"
   Monitor		"HP P1110"
   DefaultDepth	24
   SubSection "Display"
       Depth		24
       Modes		"1800x1440" "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
   EndSubSection
EndSection

Une 'Section "ServerLayout"'

On définit une 'Section "ServerLayout" où l'on indique les 2 Screen configurés juste ci-dessus. On peut indiquer leur position en absolu ou en relatif.

Exemple d'un layout monoscreen :

Section "ServerLayout"
   Identifier	"Single"
   Screen		"Screen - VGA" 0 0
   InputDevice	"Generic Keyboard"
   InputDevice	"Configured Mouse"
   InputDevice	"Generic Mouse"
EndSection

Exemple d'un layout dualscreen :

Section "ServerLayout"
   Identifier	"Dual"
   Screen		"Screen - VGA" 0 0
   Screen		"Screen - DVI" RightOf "Screen - VGA"
   InputDevice	"Generic Keyboard"
   InputDevice	"Configured Mouse"
   InputDevice	"Generic Mouse"
EndSection

On peut utiliser RightOf, LeftOf, Top... et en absolu on peut tout se permettre (superposition totale si les deux sont en 0 0 et de mêmes résolutions, superposition partielle...)

Résultats

• On a 2 "bureaux réels" (display :0.0 et display :0.1), chacun avec leurs bureaux virtuels et leur barre des tâches.
• Seule la souris peut passer de l'un à l'autre, ce qui déplace le focus du clavier en même temps.
• On peut lancer une application depuis l'un vers l'autre en surchargeant temporairement la variable DISPLAY. Exemple depuis le premier :

DISPLAY=:0.1 xine

• On NE peut PAS glisser une application d'un écran à l'autre.

Et avec l'option Xinerama ?

Dans la configuration, dans la 'Section "ServerLayout"' on ajoute l'option :

Option "Xinerama" "On"

Ca fusionne les 2 écrans en un seul écran géant, le wallpaper et la barre des tâches sont étendus sur les 2 écrans. On peut donc faire glisser une application de l'un vers l'autre.

Spécial NVidia

Le TwinView est une technique spécifique au driver propriétaire NVidia.

La documentation des drivers contient tous les paramètres. En gros on garde 1 Device mais avec pas mal d'options à rajouter, dont les specs du second moniteur. On a toujours 1 Monitor (le principal), 1 Screen (le principal), 1 ServerLayout classique. Bref c'est presque comme avec un seul écran niveau fichier de configuration, on grossit juste un peu la 'Section "Device"'. Exemple :

Section "Device"
   Identifier      "GeForce - TwinView"
   Driver      "nvidia"     
   Option "NoLogo" "True"
   # TwinView stuff
   Option "TwinView"
   Option "TwinViewOrientation" "RightOf"
   Option "SecondMonitorHorizSync" "29-121"
   Option "SecondMonitorVertRefresh" "50-180"
   Option "MetaModes" "1280x1024, 1280x1024"
   Option "ConnectedMonitor" "CRT, CRT"
EndSection

Le résultat est le même, on peut être en mode étendu (à la Xinerama) ou Clone (le même affichage sur les 2 écrans)

Plusieurs sessions en même temps

Les différentes consoles

• 6 consoles textuelles de <CTRL><ALT><F1> à <CTRL><ALT><F6>
• 6 consoles graphiques de <CTRL><ALT><F7> à <CTRL><ALT><F12>

Texte

• texte pur : il suffit de se logger. Si vous n'avez pas assez de terminaux, pensez à utiliser le logiciel screen
• texte sous X : autant de terminaux que vous voulez, il suffit de les lancer dans votre X. Au choix : xterm, aterm, eterm, konsole, gnome-terminal...

X

On peut lancer plusieurs serveurs sur la même machine, en utilisant xinit ou son wrapper startx

Présentation de xinit

La syntaxe de xinit ou startx est :

xinit  client client_option -- serveur serveur_options

• Si on ne précise pas le client, xinit cherche dans ~/.xinitrc ou ~/.Xsession. S'il ne trouve rien ca sera xterm.
• Si on ne précise pas le serveur, xinit utilise X :0 (X est en général un lien vers /usr/bin/XFree ou /usr/bin/Xorg)

Lancer un deuxième X en parallèle

Nous allons donc simplement indiquer à X d'utiliser le display suivant, à savoir :1

• Le display :0 c'est <CTRL><ALT><F7>
• Le display :1 c'est <CTRL><ALT><F8>
• etc

Pour instancier la même chose que votre <CTRL><ALT><F7> mais sur <CTRL><ALT><F8>, on passe juste une option au serveur

xinit -- :1

Pour lancer un autre window manager sur <CTRL><ALT><F8>

xinit /usr/bin/xfce -- :1

Pour lancer un serveur X différent sur <CTRL><ALT><F8>

xinit -- /usr/bin/mon_autre_serveur_X :1

La totale : autre client, autre serveur, autre display

xinit /usr/bin/xfce -- /usr/bin/mon_autre_serveur_X :1

Note

Une option intéréssante de Xorg : "-layout NAME"

Cela lancera X en prenant dans xorg.conf la section ServerLayout nommée NAME au lieu de prendre la première trouvée. Très pratique si vous voulez gérer différentes configurations, par exemple une avec 1 moniteur et une autre avec 2, ou encore une avec 1 moniteur haute résolution et une autre avec un moniteur plus ancien.

Dans /tmp on trouve

• .X0-lock si <CTRL><ALT><F7> est occupé
• .X1-lock si <CTRL><ALT><F8> est occupé
• etc

Options par défaut de X

Si vous éditez startx vous verrez qu'il cherche des fichiers xinitrc et xserverrc, dans /etc/X11/xinit/ et dans votre ~ en fichiers cachés (le ~ est prioritaire)

Le fichier /etc/X11/xinit/xserverrc nous apprend que de base, X est lancé avec les paramètres :

/usr/bin/X11/X -dpi 100 -nolisten tcp

L'option "-nolisten tcp" désactive les connexions tcp. C'est bien pour la sécurité mais mauvais si vous souhaitez déporter l'affichage...

Déporter l'affichage par le réseau

Introduction

On va supposer l'existence de 2 machines :

• "here" est la machine locale
• "faraway" est la machine distante

Vous êtes physiquement devant "here" et voulez lancer une application installée sur "faraway".

L'affichage déporté consiste à faire tourner l'application sur "faraway". "here" ne fait que recevoir l'affichage et transmet les évènements clavier/souris par le réseau à "faraway" qui fait tout le boulot.

Texte

Machine distante

Il faut un serveur ssh

Machine locale

Il faut un client ssh.

here$ ssh login@faraway

C'est tout, ca marche et c'est sûr en plus.

Liste d'applications

• Linux :
  • Clients : ssh
  • Serveurs : sshd
• Windows :
  • Clients : putty
  • Serveurs :

X

Note : on ne parle que de xhost, pas de xauth, désolé :(

Le principe

La subtilité

X fonctionne à l'inverse d'un client/serveur réseau classique.

La machine distante contient l'application que vous voulez à tout prix lancer. Cette application est un client X.

Votre pc local doit afficher cette application sur votre moniteur. "here" doit donc faire tourner un serveur X.

Résumé :

• Client X sur faraway
• Serveur X sur here. On va supposer qu'il tourne sur le display :0

Une seule application

Méthode classique

Machine locale

D'abord on autorise le serveur X de "here" à afficher les applications de "faraway"

here$ xhost +faraway

Machine distante

Puis on se connecte sur faraway, par telnet, rsh, ssh, bref par n'importe quel moyen donnant accès à un shell.

faraway$ DISPLAY=here:0 la_super_application

Bon la variable DISPLAY n'est définie que le temps de lancer la_super_application, mais vous pouvez faire

faraway$ export DISPLAY=:0
faraway$ la_super_application&
faraway$ la_super_application_2&

si ca vous chante. En général ca ne semble pas très utile car si vous lancez un xterm ou un window manager, toutes les applications que vous lancerez par la suite grâce à eux hériteront de cette variable DISPLAY alors...

Si ca ne marche pas

Soit "faraway" empêche le client X de sortir (firewall très stricte ? rare en tout cas)

Soit "here" fait tourner un serveur X lancé avec l'option "-nolisten tcp" et donc qui refuse toute connexion réseau.

• Si vous utilisez startx, éditer /etc/X11/xinit/xserverrc
• Si vous utilisez gdm, lancer gdmconfig et jettez un oeil dans l'onglet sécurité
• Si vous utilisez kdm, xdm : euh sûrement pas très différent de gdm

Avec "ssh -X"

Le problème de la méthode précédente, c'est le chiffrage des données. Si vous lancez une application qui demande la saisie de différents mots de passe, ceux-ci vont voyager en clair je pense...

On peut a priori sécuriser n'importe quoi en l'encapsulant dans un tunnel SSH, mais là c'est tellement "courant" comme utilisation qu'il y a une option fournie d'office.

De plus pas besoin d'autoriser quoique ce soit avec xhost, car le client X sur faraway se connectera sur localhost, et le serveur X sur here n'écoutera que localhost.

Machine locale

here$ ssh -X login@faraway

Machine distante

Il faut que le serveur X fasse du X11Forwarding. Pour cela il faut avoir

X11Forwarding yes

dans /etc/ssh/sshd_config

Une fois la connexion ssh établie, votre variable DISPLAY sera modifiée automatiquement et vaudra sans doute quelque chose comme "localhost:10.0".

Vous pouvez lancer votre application directement, le serveur ssh de "faraway" se chargera de transmettre les données d'affichage arrivant sur localhost:10.0 par le tunnel ssh qui le relie à "here". Sur "here" le client ssh se fera une joie de transmettre tout ça au serveur X comme ci cela provenait d'une application locale.

Vous pouvez utiliser -C pour compresser les données et gagner un peu de vitesse.

Avec dxpc (compression)

dxpc pour "Differential X Protocol Compressor.". Ca consiste à poser un proxy côté client et un autre côté serveur, qui assurent la connexion et la compression des données entre les 2 machines.

Pour bien faire, il faut installer le logiciel "dxpc" des 2 côtés donc.

Machine distante

On lance dxpc en daemon

faraway: dxpc -f

Il faut que le port 4000 soit ouvert

Machine locale

On lance dxpc en client

here$ : dxpc faraway

Machine distante

Maintenant que tout ce beau monde est connecté on peut lancer sur la machine distante :

faraway$ DISPLAY=unix:8 la_super_application

En effet dxpc compresse et transfère par le réseau les données qui arrivent sur la socket unix:8

Avec lbxproxy (compression, deprecated)

Il faut lbxproxy sur la machine distante uniquement, car c'est un proxy pour client X. En face, il faut un serveur X capable de gérer les extensions LBX (XFree ok a priori)

Machine locale

D'abord on autorise le serveur X de "here" à afficher les applications de "faraway"

here$ xhost +faraway

Cette étape est inutile si vous vous connectez à faraway par "ssh -X" (cf. partie sur ssh, plus haut)

Machine distante

faraway$ lbxproxy -display here:0 :1 &

Si vous êtes loggé par "ssh -X" un simple :

faraway$ lbxproxy :1 &

suffit (ben oui tout est local du coup, cf. partie sur ssh plus haut)

faraway:$ DISPLAY=:1 la_super_application

Deprecated

A disparu depuis Xorg 7.2

Tout l'affichage

En général la machine distante a aussi un serveur X, pour les utilisateurs qui se servent physiquement de la machine. C'est pour cela qu'elle contient toutes ces applications intéréssantes que vous voulez lancer à distance.

Parfois on voudrait se logger sur cette machine 'comme si on était devant'. Plusieurs solutions...

XDMCP

Le protocole XDMCP permet de se logguer au serveur graphique d'une machine distante, et de faire exactement comme si on était loggué sous X en local sur la machine.

Là encore attention, tout voyage en clair sur le réseau. Donc c'est sans doute mieux de faire un tunnel ssh pour crypter l'intégralité de votre session X. Il y a un exemple de tunnel SSH dans le paragraphe consacré à VNC.

Machine distante

Il faut avoir gdm qui tourne et qui accepte les connexions par xdmcp. Pour cela éditez /etc/gdm/gdm.conf et modifiez la section xdmcp :

[xdmcp]
Enable=true

puis redémarrez gdm.

Machine locale

here$ X :1 -query faraway

devrait faire apparaître le gdm sur <CTRL><ALT><F8>

VNC

VNC sert à déporter l'affichage d'applications graphiques d'une machine à l'autre.

Machine distante

On se connecte sur faraway, par telnet, rsh, ssh, bref par n'importe quel moyen donnant accès à un shell.

On lance vncserver :

faraway$ vncserver

Et on tape un mot de passe assez long pour pas être trop évident.

On vient de lancer "une sorte de X" sur le premier display de libre, :1 a priori. Vous pouvez lancer "vncserver :n" avec n le numéro de session voulu, sachant que le serveur tournera sur le port p = n + 5800.

Si vous voulez carrément prendre le contrôle du serveur X en cours, lancez :

faraway: x11vnc

Ce qui devrait rendre accessible sur le réseau le display :0 à n'importe qui :o)

Machine locale

Si vous avez lancé vncserver :

here$ vncviewer faraway:1

Si vous avez lancé x11vnc :

here$ vncviewer faraway:0

Si ca ne marche pas

Firewall ?

VNC over ssh

Pour plus de sécurité, on peut établir un tunnel ssh entre la machine locale et la machine distante :

here$ ssh -L 5901:faraway:5901 -l login faraway

Ici 5901 c'est le port de la source, et faraway:5901 la destination.

Ensuite vous suivez exactement la procédure normale pour vnc, sauf que vous utilisez

here$ vncviewer localhost:1

et plus faraway:1

Liste d'applications

• Linux :
  • VNC :
    • Clients : vncviewer
    • Serveurs : vncserver, x11vnc
• Windows :
  • X :
    • Serveurs : Xwin.exe, cygwin
  • VNC :
    • Clients :
    • Serveurs :

Partager le clavier, la souris, le clipboard entre 2 X

Avec x2x

ssh -X user@autre_machine "/usr/bin/x2x -east -to :0.0"