lightdm.conf – fichier de référence

Fichier référence de configuration de LightDM  pour le multiseat (cas d’un seul fichier xorg.conf) :

Version détaillée :

[LightDM]   # Options générales pour LighDM
minimum-display-number=0 # Nombre minimal d'écrans à utiliser pour le serveur X.
minimum-vt=7 # Première console virtuelle à utiliser, on utilisera celle-ci et celles qui suivent. On peut ne omettre cette option ou indiquer une autre console de départ.

[SeatDefaults] # Options communes à tous les postes (équivalent au ServerFlag de xorg.conf)
greeter-session=unity-greeter   # Écran d'accueil à utiliser, on trouve la liste des valeurs possibles ici : /usr/share/xgreeters/ et on peut en installer d'autres. Ici, écran d'accueil par défaut d'Ubuntu 12.04 LTS
user-session=gnome-session-fallback    # Environnement de bureau (Gnome, Unity, etc.), on trouve la liste des valeurs possibles ici : /usr/share/xsessions/ et on peut en installer d'autres. Ici, bureau proche de Gnome 2
exit-on-failure=true   # Indique au démon de LightDM de quitter en cas d'erreur. Ainsi, si un serveur X ou un écran d'accueil plante, LightDM stoppe toute l'interface graphique et on se retrouve en mode console.

[Seat:0] # Options du premier poste, on peut utiliser les même que dans SeatDefaults, les valeurs ci-dessous seront prioritaires.
xserver-command=/usr/bin/X   # LightDM indique déja le bon affichage par défaut dans la commande, donc on ne met que la commande de base.
xserver-layout=Seat0   # Indique au serveur X quel est le matériel à utiliser (ici il y a un unique fichier donc on indique le ServerLayout voulu).

[Seat:1]
xserver-command=/usr/bin/X -sharevts   # On doit obligatoirement rajouter l'otpion -sharevts sur tous les postes excepté le premier, aucune raison logique trouvée.
xserver-layout=Seat1

Version utilisable :

[LightDM]
minimum-display-number=0
minimum-vt=7
[SeatDefaults]
greeter-session=unity-greeter
user-session=gnome-session-fallback
exit-on-failure=true
[Seat:0]
xserver-command=/usr/bin/X
xserver-layout=Seat0
[Seat:1]
xserver-command=/usr/bin/X -sharevts
xserver-layout=Seat1

Note : si on utilise plusieurs fichiers de configuration du serveur X (un par poste par exemple), il faut remplacer la ligne « xserver-layout=layout_utilisé » par « xserver-config=fichier_utilisé ».

Publicités

Galerie d’images

Durant le projet, quelques bizarreries et autres ont été trouvées, petit moment souvenir.

Quand le bureau Gnome perd la tête…

bureau_gnome_fou

Écran de connexion de Lightdm, si si je vous jure… Merci à la carte Trident Microsystem pour cette œuvre d’art !

Carte trident sans xorg.conf - 1

Un peu petit non ?

comparaison_gabarit_ordinateurs

Brave bête.

interieur_pc_dell_1

Arrière du DELL XPS prêté par l’UPPA.

arrière_pc_dell

Avant du DELL XPS prêté par l’UPPA.

avant_pc_dell

Bleu et vert, en mode pumbASS.

pc_dell_2

Et puis il y a tout ce que l’on ne peut pas prendre en photo, les nombreux messages d’erreur d’Ubuntu nous disant que l’application que l’on utilise aurait planté, la joie de corrompre la session graphique d’un utilisateur en lançant un joli « sudo startx — :1 » dans le terminal (méchant sudo ! ), le fait que l’on bidouille comme on peut pour faire quelque chose qui existe depuis les début d’Unix…
Que du bonheur !  ; )

xorg.conf – fichier de référence

Les nombreuses heures de travail sur le projet ont mené à la création d’un fichier de configuration du serveur X général et tout-terrain, qui peut servir de base pour tout multiseat.

# Configuration de référence du serveur X pour le multiseat. Fichier générique, mais configuré pour un poste précis. Les zones à modifées sont indiquées par un commentaire non indenté.
# Note : les entêtes des parties de chaque seat ont été modifiées pour la machine en cours. Elles seront adaptées aux différentes contextes. Le script générateur donnera la possibilité à l'utilisateur de mettre un petit texte pour se souvenir de quel matériel traite le seat.

#**************************************************************
#**************************************************************
#
#	PARTIE COMMUNE À TOUS LES SEAT
#
#**************************************************************
#**************************************************************

    Section "ServerFlags"
        Option         "AutoAddDevices"      "false"
        Option         "AutoEnableDevices"   "false"
        Option         "AllowEmptyInput"     "true"
        Option         "AllowMouseOpenFail"  "true"
        Option         "AutoAddGPU"          "false"
        Option         "DPMS"                "true"
        Option         "BlankTime"           "5"
        Option         "StandbyTime"         "6"
        Option         "SuspendTime"         "7"
        Option         "OffTime"             "8"
        Option         "DefaultServerLayout" "Seat0"
        Option         "DontVTSwitch"        "true"
    EndSection

    Section "Module"
        Load         "extmod"
        Load         "dri2"
        Load         "dri"
        Load         "dbe"
        Load         "record"
        Load         "glx"
        Load         "GLcore"
    EndSection

#**************************************************************
#**************************************************************
#
#	SEAT 0 - Matériel perso
#
#**************************************************************
#**************************************************************

    Section "ServerLayout"
        Identifier         "Seat0"
        Screen           0 "Screen0"        0 0
        InputDevice        "Mouse0"         "CorePointer"
        InputDevice        "Keyboard0"      "CoreKeyboard"
        Option             "DontVTSwitch"   "false"
    EndSection

    Section "Device"
        Identifier         "Videocard0"
# CHANGER LE PILOTE
        Driver             "nvidia"
# CHANGER L'ADRESSE PCI
        BusID              "PCI:01:00:0"
# OPTION À UTILISER UNIQUEMENT SI LE PILOTE NVIDIA EST UTILISÉ
        Option             "ProbeAllGpus" "false"
    EndSection

    Section "InputDevice"
        Identifier         "Keyboard0"
        Driver             "evdev"
# CHANGER LE CHEMIN
        Option             "Device"       "/dev/input/by-path/platform-i8042-serio-0-event-kbd"
        Option             "XkbRules"     "xorg"
        Option             "XkbModel"     "xorg"
# ADAPTER LES DEUX OPTIONS SUIVANTES À LA LANGUE ET LA VARIANTE DU CLAVIER UTILISÉ
        Option             "XkbLayout"    "fr"
        Option             "XkbVariant"   "oss"
        Option             "GrabDevice"   "true"
    EndSection

    Section "InputDevice"
        Identifier         "Mouse0"
# PILOTE "SYNAPTICS" SI PC PORTABLE AVEC TOUCHPAD SYNAPTICS
        Driver             "mouse"
# CHANGER LE CHEMIN
        Option             "Device"      "/dev/input/by-path/pci-0000:00:0b.0-usb-0:2:1.0-mouse"
	Option             "Protocol"    "ExplorerPS/2"
        Option             "GrabDevice"  "true"
    EndSection

    Section "Monitor"
        Identifier         "Monitor0"
        Option             "DPMS"
    EndSection     

    Section "Screen"
        Identifier         "Screen0"
        Device             "Videocard0"
        Monitor            "Monitor0"
        Option             "NoLogo" "true"
    EndSection

#**************************************************************
#**************************************************************
#
#	SEAT 1 - matériel université
#
#**************************************************************
#**************************************************************

    Section "ServerLayout"
        Identifier         "Seat1"
        Screen             "Screen1"
        InputDevice        "Mouse1"      "CorePointer"
        InputDevice        "Keyboard1"   "CoreKeyboard"
    EndSection

    Section "Device"
        Identifier         "Videocard1"
# CHANGER LE PILOTE
	Driver             "nvidia"
# CHANGER L'ADRESSE
        BusID              "PCI:06:00:0"
# OPTION À UTILISER UNIQUEMENT SI LE PILOTE NVIDIA EST UTILISÉ
        Option             "ProbeAllGpus" "false"
    EndSection

    Section "InputDevice"
        Identifier         "Keyboard1"
        Driver             "evdev"
# CHANGER LE CHEMIN
        Option             "Device"         "/dev/input/by-path/pci-0000:00:0b.0-usb-0:4:1.0-event-kbd"
        Option             "XkbRules"       "xorg"
        Option             "XkbModel"       "xorg"
# ADAPTER LES DEUX OPTIONS SUIVANTES À LA LANGUE ET LA VARIANTE DU CLAVIER UTILISÉ
        Option             "XkbLayout"      "fr"
        Option             "XkbVariant"     "oss"
        Option             "GrabDevice"     "true"
    EndSection

    Section "InputDevice"
        Identifier         "Mouse1"
# PILOTE "SYNAPTICS" SI PC PORTABLE AVEC TOUCHPAD SYNAPTICS
        Driver             "mouse"
# CHANGER LE CHEMIN
        Option             "Device"       "/dev/input/by-path/pci-0000:00:0b.0-usb-0:1:1.0-mouse"
	Option             "Protocol"     "ExplorerPS/2"
        Option             "GrabDevice"   "true"
    EndSection

    Section "Monitor"
        Identifier         "Monitor1"
        Option             "DPMS"
    EndSection    

    Section "Screen"
        Identifier         "Screen1"
        Device             "Videocard1"
        Monitor            "Monitor1"
        Option             "NoLogo" "true"
    EndSection

Un fichier détaillant chaque ligne est également disponible (on ne peut pas héberger des fichiers texte donc il faudra faire du copier/coller) :

# Fichier de configuration d'X.Org créé manuellement en vue de la réalisation d'un système multiseat.
# Chaque ligne est commentée pour détailler le rôle de l'option, son fonctionnement, son importance et les problèmes possibles.

# Version 1.0
#
# Notes de version :
#    - Première version fonctionnelle ;
#    - Multiseat statique à deux postes : aucune modification du matériel n'est possible, tous les réglages se font à la main dans ce fichier et dans le fichier lightdm.conf :
#        - Pas de déplacement des périphériques sur d'autres ports (sauf en modifiant ce fichier) ;
#        - Pas de branchement à chaud de périphériques d'entrée (sauf en modifiant ce fichier ; supports de stockage possible mais que sur le premier seat) ;
#        - Pas de modification des sorties sur lesquelles les écrans sont branchés (sauf en modifiant ce fichier) ;
#    - Fonctionne avec une carte graphique par poste ;
#    - Ne gère pas le son.

#**************************************************************
#**************************************************************
#
#	NOTES
#
#**************************************************************
#**************************************************************

# Méthodes d'identification des périphériques d'entrée (InputDevice) :
#        
#        Note : toutes ces méthodes ont un défaut, on ne peut pas changer le périphérique de place (le brancher sur un autre port) car ils sont repérés en fonction de leur adresse physique.
#        
#     1. cat /proc/bus/input/devices (NE FONCTIONNE PAS MAIS LA PREMIÈRE PARTIE EST TRÈS UTILE POUR IDENTIFIER LE PÉRIPHÉRIQUE (NAME + EVENT))
#        Ce fichier contient une liste des périphériques connectés à l'ordinateur et diverses informations utiles, qui permettent de les identifier entre-autres.
#        
#        Exemple d'entrées concernant le bouton d'alimentation :
#        I: Bus=0019 Vendor=0000 Product=0001 Version=0000
#        N: Name="Power Button"
#        P: Phys=PNP0C0C/button/input0
#        S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
#        U: Uniq=
#        H: Handlers=kbd event1 
#        B: PROP=0
#        B: EV=3
#        B: KEY=10000000000000 0
#        
#        Le nom nous aide à identifier le périphérique, et la valeur de "Phys" nous permet de l'identifier. On entrera alors la ligne suivante dans la section InputDevice :
#        Option "Dev Phys" "PNP0C0C/button/input0"
#         OU :
#        Option "Phys" "PNP0C0C/button/input0"
#        
#        NOTE : CETTE FAÇON DE FAIRE A ÉTÉ ÉVOQUÉE ICI : https://help.ubuntu.com/community/MultiseatX ET UTILISÉE ICI http://en.wikibooks.org/wiki/Multiseat_Configuration/evdev ET LÀ http://blog.fclement.info/en/content/configurer-souris-logitech-v470-cordless-laser-sous-ubuntu. MAIS ELLE NE FONCTIONNE PAS ! Il y a peut-être une façon de l'utiliser mais je n'ai pas trouvé sur le web. On n'a quasiment jamais à identifier le périphérique utilisé directement dans xorg.conf, rare sont les exemples sur internet et ceux trouvés ne fonctionnent pas. Après 45min de recherche, cette solution a été mise de côté.
#        
#     2. ls -la /dev/input/by-path/ (MÉTHODE UTILISÉE !) OU ls -la /dev/input/by-id/
#        
#        Ce dossier permet d'identifier les périphériques d'entrée. Il contient des liens menant aux fichiers correspondant à ces périphériques. ces fichiers sont du type "eventn", n étant le numéro de l'évennement. Ce numéro pouvant changer entre les démarrage, on ne s'en sert pas directement. Les liens du dossier /dev/input/by-path/ mènent toujours au bon endroit et ne changent pas, leur nom est donné en fonction de l'adresse physique du périphérique (adresse du port USB ou bus PCI). Ainsi, chaque périphérique est identifié en fonction du port où il est connecté. Le fichier /proc/bus/input/devices aide pour identifier le clavier voulu.
#        
#        Exemple d'entrée pour le clavier :
#        
#        lrwxrwxrwx 1 root root  10 mars  15 19:40 pci-0000:00:1d.0-usb-0:1.5:1.0-event-mouse -> ../event11
#        lrwxrwxrwx 1 root root   9 mars  15 19:40 pci-0000:00:1d.0-usb-0:1.5:1.0-mouse -> ../mouse1
#
#        La seconde ligne nous intéresse, elle va nous servir à identifier le périphérique. NE SURTOUT PAS UTILISER LA PREMIÈRE LIGNE, LA SOURIS DEVIENDRAIT FOLLE ET INUTILISABLE. On entrera alors la ligne suivante dans la section InputDevice :
#        Option "Device" " "/dev/input/by-path/pci-0000:00:1d.0-usb-0:1.5:1.0-mouse"
#
#        Méthode similaire pour ls -la /dev/input/by-id/
#        
#     3. ls -la /dev/input/mouse*
#        Cette commande liste tous les fichiers spéciaux correspondants aux souris (un par souris connectée), numérotés de mouse0 à mouse(n-1) s'il y a n souris connectées. Pour identifier quel fichier correspond à quelle souris, il faut lire le fichier /proc/bus/input/devices et lire la partie  H: Handlers=mouse0 event1 pour déterminer quel est le numéro de la souris.
#
#        On entrera alors la ligne suivante dans la section InputDevice :
#        Option "Device" "/dev/input/mouse0"
#        
#     4. dmesg | tail (après avoir branché un périphérique)
#        Cette commande affiche les dernières lignes (tail) du tampon du noyau (dmesg). man dmesg : "dmesg is used to examine or control the kernel ring buffer. The default action is to read all messages from kernel ring buffer." C'est "ring buffer" que j'ai du mal à traduire avec précision.
#        Quand on connecte ou déconnecte un périphérique, cette action est écrite dans le tampon du noyau et on peut la lire. Cela permet de déterminer quel périphérique vient d'être connecté pour le traiter. Je ne sais pas si on peut s'en servir aisément pour un script, mais à la main, c'est plutôt pratique. Même si les périphériques ne sont pas ajoutés/activés par défaut, l'évennement est noté ici. Enfin, pour le traitement des périphériques, regarder aussi les évennements HAL/udev pour les ajouter via un script et voir DevicePresenceNotify. Bref se renseigner plus amplement.

#        DPMS : Protocole de communication entre la carte graphique et l'écran (donc les deux doivent le supporter). Utilisé pour la synchronisation verticale et horizontale entre-autres. Je n'en sais pas plus, c'est assez technique et je n'ai pas le temps de me renseigner plus. Mais ça sert aussi pour mettre l'écran en veille s'il ne  reçoit plus de signal de la carte vidéo.

# Il peut y avoir des problèmes en cas d'utilisation de plusieurs ports VGA : http://forum.ubuntu-fr.org/viewtopic.php?pid=2935712#p2935712.

# Les pilotes propriétaires sont plus stables.

#**************************************************************
#**************************************************************
#
#	PARTIE COMMUNE À TOUS LES SEAT
#
#**************************************************************
#**************************************************************

    Section "ServerFlags" # Permet de définir des options générales pour le serveur X ; héritées par tous les seats

        Option         "AutoAddDevices"      "false"
        # empêche l’ajout automatique de périphériques (inhibe utilisation de plusieurs claviers/souris sur un même poste) ; permet d’isoler les périphériques d’entrée en fonction du poste. Regarder les évennements HAL pour les ajouter via un script. Piste : DevicePresenceNotify.

        Option         "AutoEnableDevices"   "false"
        # empêche l’activation automatique des périphériques (ils ne seront pas reconnus dès leur branchement), ce qui peut poser problème car si une souris ou autre est débranchée, on doit relancer la session pour pouvoir la réutiliser. Un script lancé par une règle udev devrait corriger cela, et on garderait donc le contrôle sur chaque périphérique. Ou alors, des InputClass peut-être.

        Option         "AllowEmptyInput"     "true"
        # permet au serveur X de démarrer même si aucun périphérique d’entrée n’a pu être initialisé ; option inutile mais préconisée par plusieurs sources et ne génère pas de bug.

        Option         "DontZap"             "false"
        # empêche de tuer le serveur X avec une combinaison de touches.

        Option         "AllowMouseOpenFail"  "true"
        # permet au serveur X de démarrer même si aucune souris n’a pu être initialisé ; option inutile (et redondante avec "AllowEmptyInput") mais préconisée par plusieurs sources et ne génère pas de bug.

        Option         "AutoAddGPU"          "false"
        # option mystérieuse, utilisée pour les multiseat. Plus d’infos ici : http://www.mail-archive.com/xorg-devel@lists.x.org/msg31094.html (page officielle); utilisé ici : https://help.ubuntu.com/community/MultiseatX. Pas plus d'informations trouvées. La description officielle dit «This option is to stop the X server adding non-primary devices as gpu screens ». On ne comprend pas vraiment ce que veut dire « non-primary device » dans notre contexte. La documentation de Gentoo sur le multiseat indique « In case xorg-server 1.13.0 and above is in use, the following must be used to maintain the gpu separation », cette option servirait donc à séparer les GPUs...

        Option         "DPMS"                "true"
        # active le DPMS pour l’écran. DPMS : protocole de communication entre la carte graphique et l’écran (donc les deux doivent le supporter). Utilisé pour la synchronisation verticale et horizontale entre-autres. Cela sert aussi pour mettre l’écran en veille s’il ne  reçoit plus de signal de la carte vidéo. Une source (http://www.freebsd.org/doc/fr/books/handbook/x-config.html) : « X autorise l’utilisation des caractéristiques DMPS (Energy Star) avec les moniteurs qui en sont capables. Le programme xset(1) contrôle les délais et peut forcer la mise en veille, l’arrêt, ou les modes d’extinction ».

        Option         "BlankTime"           "5" # sets the inactivity timeout for the blanking phase of the screensaver

        # les 3 options qui suivent concernent les écrans et cartes compatibles avec le protocole DPMS. Elles gèrent l’extinction de l’écran après une période d’inactivité. Nous ne connaissons pas leur rôle (les tests ne donnent rien), mais elles sont dans cet ordre (de l’effet le moins important au plus important). La documentation n’est pas claire ; temps en minute ; commentaires du manuel de xorg.conf.s
        Option         "StandbyTime"         "6" # sets the inactivity timeout for the "standby" phase of DPMS mode
        Option         "SuspendTime"         "7" # sets the inactivity timeout for the "suspend" phase of DPMS mode
        Option         "OffTime"             "8" # sets the inactivity timeout for the "off" phase of DPMS mode

        Option         "DefaultServerLayout" "Seat0"
        # indique le poste à charger par défaut si on n'indique pas à X.org lequel utiliser ; inutile dans le cas du multiseat car on configure lightdm pour démarrer X.org avec le poste voulu. Laissé à des fins de débogage (si on rétabli la configuaration par défaut de lightdm par exemple) pour que le serveur X ne soit pas perdu.

        Option         "DontVTSwitch"        "true"
        # empêche de changer de console virtuelle avec la séquence ctrl+Fn. Important car seul le premier poste a accès à ces consoles, mais si un autre utilisateur fait cette combinaison, le premier poste est affecté et est changé de console virtuelle (donc l'utilisateur du premier poste va se retrouver dans une console sans comprendre pourquoi). On doit par contre le ré-activer pour le premier poste, avoir un accès à une console peut toujours servir.
    EndSection

    Section "Module" # Liste des modules optionnels à charger
        # depuis sa version 7.0, X.org est divisé en différents modules et tous ne sont pas chargés par défaut. Les modules listés ici seront chargés au démarrage. Il n'y a pas de liste exhaustive des modules possibles ni de façon simple et rapide de connaître ceux installés sur l'ordinateur (et donc utilisables). Il existe deux façons de déclarer un module : load "nom_module" (le nom est sensible à la casse) ou créer une sous-section ayant le nom du module et qui contient des Option (des extensions du module) qui seront transmises au module chargé. Certains modules sont chargés automatiquement, on peut l'empêcher en utilisant "Disable" au lieu de "Load". X.org va charger les fichiers correspondant au nom des modules donnés. Toutefois, le nom du module diffère légèrement du nom du fichier. Lorsque l'on nomme le module, on ne doit pas écrire les suffixes ".a", ".o", ou ".so", ni le préfixe "lib" si le nom du fichier le contient. Ainsi, le fichier "libextmod.so" est référencé par le module "extmod". X.org cherche récursivement les fichiers correspondants aux modules dans tous les répertoires spécifiés par le ModulePath (voir ci-dessous), les pilotes, les périphériques de saisie, les extensions et les polices. Il est donc très compliqué d'avoir un aperçu complet des modules disponibles. Toutefois, le contenu du répertoire "/usr/lib/xorg/modules" donne une liste non-exhaustive. Les modules “extmod”, “dbe”, “dri”, “dri2”, “glx” et “record” sont chargés automatiquement s'ils sont présents, à moins qu'ils soient explicitement désactivés par l'option "Disable". Il est recommandé de charger au moins le module "extmod".
        # Le "ModulePath" est une option que l'on peut spécifier dans la section "File" (absente de ce fichier). On utilise la syntaxe suivante : « ModulePath "path1[,path2][...][,pathn]" », on entre donc un ou plusieurs chemins séparés par des virgules. Si plusieurs entrées "ModulePath" sont présentes, elles seront concaténées pour créer le "ModulePath" utilisé par le serveur X. Le chemin par défaut est "/usr/lib/xorg/modules".
        # Source : Manuel de xorg.conf pour la version 1.11.3 de xorg-server. Certaines parties ne sont pas valables pour toutes les versions de xorg-server.

        # Principaux modules utilisables - source : http://www.x.org/wiki/XorgConfModulesSection :

        Load         "extmod"
        # active de nombreuses extensions très courantes de X.org comme shaped windows, shared memory, video mode switching, DGA, et Xvideo ; toutes ne sont pas forcément disponibles et certaines peuvent être désactivées en utilisant «SubSection "extmod" "omit nom_extension" EndSubSection ». ACTIVÉ PAR DÉFAUT.

        Load         "dri"
        # active le DRI (direct rendering infrastructure), toutes les cartes vidéos le supportent désormais. Permet d'utiliser l'accélération matérielle pour les rendus 3D (c'est la carte vidéo qui travaille et non le processeur ainsi). Sans ce module, c'est le serveur X qui génère ces rendus, faisant tout logiciellement, ce qui consomme beaucoup de ressources. Plus d'informations ici : http://www.gentoo.org/doc/fr/dri-howto.xml. ACTIVÉ PAR DÉFAUT.

        Load         "dri2"
        #  active le DRI2, amélioration du DRI. Plus d'informations ici : http://www.x.org/releases/X11R7.7/doc/dri2proto/dri2proto.txt et là : http://www.x.org/wiki/DRI2. ACTIVÉ PAR DÉFAUT.

        Load         "dbe"
        # active l'extension de double-buffering (utilise deux tampon pour créer les images), utile pour l'animation ou la vidéo. ACTIVÉ PAR DÉFAUT.
        # Traduction approximative de "http://www.x.org/releases/X11R7.7/doc/xextproto/dbe.html#Introduction" : L'extension DBE fournit une façon standard d'utiliser une double mémoire tampon dans le cadre du serveur X. Deux mémoires tampon snt utilisées, nommées "front" et "back" qui contiennent les images. Le premier tampon est visible par l'utilisateur, l'autre non. Les images successives d'une animation sont créées dans le tampon arrière pendant que l'image précédente est affichée sur le tampon avant. Quand uune nouvelle image est prête, les deux tampons échangent leur rôle, rendant visible la nouvelle image.

        Load         "record"
        # active l'extension record, enregistre des événements qui se produisent. Utilisé à des fins de test généralement. Spécification du protocole : http://www.x.org/releases/X11R7.7/doc/recordproto/record.html. ACTIVÉ PAR DÉFAUT.

        Load         "glx"
        # active le rendu OpenGL ; extension faisant le lien entre le serveur X et OpenGL (pour tout ce qui est 3D, etc.). Plus d'informations ici : http://doc.ubuntu-fr.org/opengl, http://fr.wikipedia.org/wiki/GLX, http://fr.wikipedia.org/wiki/OpenGL. ACTIVÉ PAR DÉFAUT.

        Load         "GLcore"
        # utilisé par OpenGL, pas plus d'informations trouvées.

        Load         "bitmap"
        # active le support des polices bitmap pour la rastérisation (http://fr.wikipedia.org/wiki/Rast%C3%A9risation - http://msdn.microsoft.com/fr-fr/library/ff604996%28v=xnagamestudio.40%29.aspx - traite l'image pour l'affichage sur l'écran). Inutile depuis la version 7.0 de X.org.

        Load         "vbe"
        # active l'extension Vesa Bios ;  autorise la demande des capacités du moniteur via la carte vidéo.

        Load         "int10"
        # émulateur x86 utilisé pour le démarrage de la carte vidéo secondaire. Devrait être activé si "vbe" l'est. Traduction de « real-mode x86 emulator used to softboot secondary VGA cards. Should be enabled if vbe is enabled ».

        Load         "ddc"
        # active l'extension Data Display Channel ;  autorise la demande des capacités du moniteur via la carte vidéo.

        Load         "i2c"
        # serial bus over which you speak the ddc protocol to get info from the monitor.

        Load         "freetype"
        Load         "type1"
        # charge les polices "freetype" et "type1" (ce sont des types de police, donc toutes celles qui y sont associées sont chargées ; polices stockées ici : "/usr/share/fonts").

    EndSection

#**************************************************************
#**************************************************************
#
#	SEAT 0 - Matériel perso
#
#**************************************************************
#**************************************************************

    Section "ServerLayout" # permet d’associer tout le matériel pour former une configuration complète. On peut également y appliquer diverses options, pour écraser celles du ServerFlags par exemple.
        Identifier         "Seat0"
        # permet d’identifier de manière unique cette section et donc tout ce qui s'y réfère.

        Screen           0 "Screen0"        0 0
        # n° écran du layout  (identifiant écran – position x – position y) ; voir man xorg.conf.

        InputDevice        "Mouse0"         "CorePointer"
        # indique la souris à utiliser ; CorePointer indique que c’est la souris principale.

        InputDevice        "Keyboard0"      "CoreKeyboard"
        # indique le clavier à utiliser ; CoreKeyboard indique que c’est le clavier principal.

        Option             "DontVTSwitch"   "true"
        # permet à l'utilisateur de ce poste d'utiliser les consoles virtuelles et d'y accéder grâce à la combinaison de touches ctrl+Fn.

    EndSection

    Section "Device"
        # permet d’identifier et configurer les carte graphique vidéo ; une section par carte (dans le cas du multiseat, sans multi-écran). Dans le cas d'un multi-écran, on utilise une section "Device" par sortie vidéo, en les identifiant de manière unique avec l'option « Screen n », n étant le numéro de la sortie. Numérotation début à 0 et est composée de nombres entiers contigues. Lors de la référence aux écrans dans le "ServerLayout", un écran ne peut être utilisé que si tous les écrans de numéro inférieur le sont. Ainsi, l'écran de la sortie n°1 ne peut être utilisé que si celui de la sortie n°0 y est. L'identification des sorties étant logicielle et non matérielle, le choix du numéro des sorties vidéo est arbitraire.
        Identifier         "Videocard0"

# CHANGER LE PILOTE
        Driver             "nvidia"
        # indique à X.org quel est le pilote de la carte graphique. Cela dépend de la carte graphique, il ne faut pas se tromper sinon le pilote nécessaire ne sera pas chargé. Voir ici (http://doc.ubuntu-fr.org/carte_graphique) les documentations de chaque carte pour plus d’informations sur les pilotes. En général, "radeon" fonctionne bien avec les cartes AMD, et "nv", "nouveau" avec celles Nvidia. "vesa" fonctionne aussi mais est trop basique. Pilote propriétaire "nvidia" recommandé pour les cartes Nvidia. Le répertoire "/usr/lib/xorg/modules/drivers" liste les pilotes graphiques installés.

# CHANGER L'ADRESSE PCI
        BusID              "PCI:01:00:0"
        # numéro du bus PCI de la carte : son adresse physique, permet de l’identifier de façon non-ambiguë. La commande  « $ lspci | grep -E « 3D|VGA » » permet de lister les différentes cartes graphiques. La ligne correspondant à chaque périphérique commence par son adresse physique. Note importante : l’adresse donnée par la commande sera de la forme « 01:00.0 », mais il faut écrire « 01:00:0 » dans le fichier xorg.conf. L’adressage des cartes AGP dans xorg.conf utilise excatement la même syntace (PCI:01:00:0).

# OPTION À UTILISER UNIQUEMENT SI LE PILOTE NVIDIA EST UTILISÉ
        Option             "ProbeAllGpus" "false"
        # permet de ne sonder que les cartes vidéos qui sont connectées à un écran ; comportement par défaut sonde toutes les cartes.
    EndSection

    Section "InputDevice" # permet de répertorier chaque périphérique de saisie et d’en donner les caractéristiques afin qu’ils soient bien reconnus par le système ; une section par périphérique.
        Identifier         "Keyboard0"

        Driver             "evdev"
        # pilote qui gère les claviers.

# CHANGER LE CHEMIN
        Option             "Device"       "/dev/input/by-path/platform-i8042-serio-0-event-kbd"
        # chemin vers le fichier correspondant au clavier considéré.

# le dossier /usr/share/X11/xkb contient les différentes valeurs possibles pour les options suivantes.

        Option             "XkbRules"     "xorg"
        # indique les règles utilisées pour interpréter les options XkbModel, XkbLayout, XkbVariant et XkbOptions. On indique généralement "xorg" ou "evdev".

        Option             "XkbModel"     "xorg"
        # type de clavier (105 touches, etc), "xorg" fonctionne trrès bien.

# ADAPTER LES DEUX OPTIONS SUIVANTES À LA LANGUE ET LA VARIANTE DU CLAVIER UTILISÉ
        Option             "XkbLayout"    "fr"
        # langue du clavier.

        Option             "XkbVariant"   "oss"
        # variante du clavier (bépo et autrte) ; oss est très bien et fournit de nombreux caractères manquants sur les claviers azerty comme : «»≤≥œ©êæâêþÿûîôöŀïüð’‘ëßä ¬¿×÷¡↓↔↖↑↗→↔↓↘↙ à l'aide de la touche altGr.

        Option             "GrabDevice"   "true"
        #  peut empêcher certains bugs du clavier ou de la souris.

    EndSection

    Section "InputDevice"
        Identifier         "Mouse0"

# PILOTE "SYNAPTICS" SI PC PORTABLE AVEC TOUCHPAD SYNAPTICS
        Driver             "mouse"
        # pilote qui gère les souris.

# CHANGER LE CHEMIN
        Option             "Device"      "/dev/input/by-path/pci-0000:00:0b.0-usb-0:2:1.0-mouse"

	Option             "Protocol"    "ExplorerPS/2"
        # protocole qui gère la souris ; nombreuses valeurs possibles ; entrées obligatoire, aucune valeur par défaut. Plus d'informations ici : http://ftp.x.org/pub/X11R7.0/doc/html/mouse.4.html.

        Option             "GrabDevice"  "true"
    EndSection

    Section "Monitor" # permet de configurer les écrans, une section par écran.
        Identifier         "Monitor0"

        Option             "DPMS"
        # Active l'extension DPMS (Energy Star) pour l'écran ; tous le supportent maintenant.
    EndSection     

    Section "Screen" # permet de créer un dispositif d'affichage complet en associant une carte vidéo et un écran. L'écran connecté utilisera donc les réglages spécifiés dans la section "monitor", changer d'écran ne se fait pas toujours simplement.
        Identifier         "Screen0"

        Device             "Videocard0"
        # référence à la carte vidéo utilisée.

        Monitor            "Monitor0"
        # référence à l'écran utilisé.

# OPTION À UTILISER UNIQUEMENT SI LE PILOTE NVIDIA EST UTILISÉ
        Option             "NoLogo" "true"
        # auparavant, avec le pilote "nvidia", le logo de Nvidia apparaissait au démarrage de X.org et cette option permettait de l'enlever. Aujourd'hui, le comportement par défaut est de ne pas l'afficher, rendant ceette option caduque. Voir http://brainstorm.ubuntu.com/idea/6420/.

    EndSection

#**************************************************************
#**************************************************************
#
#	SEAT 1 - matériel université
#
#**************************************************************
#**************************************************************

    Section "ServerLayout"
        Identifier         "Seat1"
        Screen             "Screen1"
        InputDevice        "Mouse1"      "CorePointer"
        InputDevice        "Keyboard1"   "CoreKeyboard"
    EndSection

    Section "Device"
        Identifier         "Videocard1"
# CHANGER LE PILOTE
	Driver             "nvidia"
# CHANGER L'ADRESSE
        BusID              "PCI:06:00:0"
# OPTION À UTILISER UNIQUEMENT SI LE PILOTE NVIDIA EST UTILISÉ
        Option             "ProbeAllGpus" "false"
    EndSection

    Section "InputDevice"
        Identifier         "Keyboard1"
        Driver             "evdev"
# CHANGER LE CHEMIN
        Option             "Device"         "/dev/input/by-path/pci-0000:00:0b.0-usb-0:4:1.0-event-kbd"
        Option             "XkbRules"       "xorg"
        Option             "XkbModel"       "xorg"
# ADAPTER LES DEUX OPTIONS SUIVANTES À LA LANGUE ET LA VARIANTE DU CLAVIER UTILISÉ
        Option             "XkbLayout"      "fr"
        Option             "XkbVariant"     "oss"
        Option             "GrabDevice"     "true"
    EndSection

    Section "InputDevice"
        Identifier         "Mouse1"
# PILOTE "SYNAPTICS" SI PC PORTABLE AVEC TOUCHPAD SYNAPTICS
        Driver             "mouse"
# CHANGER LE CHEMIN
        Option             "Device"       "/dev/input/by-path/pci-0000:00:0b.0-usb-0:1:1.0-mouse"
	Option             "Protocol"     "ExplorerPS/2"
        Option             "GrabDevice"   "true"
    EndSection

    Section "Monitor"
        Identifier         "Monitor1"
        Option             "DPMS"
    EndSection    

    Section "Screen"
        Identifier         "Screen1"
        Device             "Videocard1"
        Monitor            "Monitor1"
    EndSection

Phase 3 : Première mise en place d’un multiseat

NOTE : CET ARTICLE EST ASSEZ MAL RÉDIGÉ. Certaines parties sont incomplètes et/ou mal rédigées, cela sera corrigé petit à petit.

Le projet est arrêté, plus aucun article ne verra le jour. En effet, une équipe de développeur travaille actuellement sur un logiciel automatisant la configuration d’un multiseat. Au moment où l’on écrit cette note (novembre 2013), le projet ubuntu-multiseat avance à grand pas.

Note : dans cet article, nous utilisons les guillemets français « » et anglais  »  ». Malheureusement WordPress les transforme tous en guillemets français, sauf lorsqu’ils sont précédés de chiffres. Dans tous les fichiers de configuration, il faut penser à mettre les guillemets anglais.

I – Introduction :

Le projet ayant pour but d’être financièrement avantageux et le plus indépendant possible des logiciels tiers, les solutions commerciales ne seront pas retenues. Le multiseat se fera donc sur les systèmes d’exploitations basés sur le noyau Linux uniquement. Windows n’est pas équipé des outils adaptés, il faudrait des professionnels pour les développer, et de toute façon la licence d’utilisateur de Windows interdit l’utilisation simultanée de l’ordinateur par plusieurs personnes.

Il faut donc trouver le moyen de réaliser un multiseat sous Linux, plus précisément sous Ubuntu 12.04 LTS. Une recherche sur le web s’est révélée nécessaire pour déterminer la faisabilité du projet ainsi que les outils à manipuler. La première étape du projet consiste donc en une grande documentation pour établir le travail à effectuer et comment arriver à nos fins. Nous nous contenterons dans un premier temps d’un multiseat basique, fonctionnel mais très limité. On tâchera par la suite de dégager les points à améliorer et de trouver les solutions adéquates. On établira donc un cahier des charges précis que notre programme devra respecter et on fera une première estimation du matériel nécessaire. Enfin, lorsque l’on aura une solution répondant à tout nos critères, on étudiera le gain financier théorique de la solution par rapport à l’achat d’un PC par utilisateur et si la solution est pertinente, on l’automatisera et la distribuera librement sur le web.

II – Documentation et résumé des ressources trouvées :

Lors de notre documentation, nous avons trouvé toutes les ressources référencées dans l’article de bibliographie. Tout ce qui est dit ici a donc pour source les lien indiqués dans la bibliographie.

Nous avons pu déduire de nos lectures les points importants de la réalisation d’un multiseat. Ce dernier est possible grâce aux développeurs Linux qui ont rendu les logiciels nécessaires compatibles avec le multiseat. C’est donc une technique officiellement supportée bien qu’aucune méthode standard et/ou officielle n’existe, ni même de script automatisant totalement le tout (certains le font en partie). Le multiseat est quelque chose de connu, mais qui se réalise encore en bricolant soi-même les fichiers nécessaires. Il est par conséquent difficile de généraliser le multiseat pour le moment, et ce dernier est totalement dépendant de quelques logiciels implémentés directement dans les distributions. Ainsi, s’ils sont modifiés ou carrément remplacé par d’autres, le multiseat peut ne plus fonctionner. La pérennité  de la solution ne peut donc pas être assurée sur le long terme, bien qu’il semble évident qu’il y aura toujours des développeurs pour créer les outils nécessaires. Mais cela implique également un développement continu du programme automatisant le multiseat afin de le rendre compatible avec les systèmes les plus récents.

III – Première réflexion sur la méthode de réalisation d’un multiseat :

1. X.Org :

Pour réaliser un multiseat nous avons besoin de connecter simultanément plusieurs utilisateurs, chacun sur un écran totalement indépendant des autres, avec ses propres périphériques. Il faut donc trouver le moyen de séparer l’affichage et d’allouer aux poste les périphériques correspondants. À chaque écran sont donc liés le clavier et la souris qui sont en face, ainsi qu’un hub USB pour permettre de connecter facilement des périphériques. Concrètement, pour associer les périphériques aux écrans, nous devons les identifier au niveau des ports de connexion de l’ordinateur (carte vidéo, port USB, port PS/2, etc.) et les lier au niveau logiciel.

Associer une carte vidéo avec un port USB semble assez étrange au premier abord et on peut penser que cela est impossible à faire, ou très difficile. Toutefois, sous Linux le logiciel gérant l’affichage est le même que celui qui gère les périphériques (enfin, il communique étroitement avec le gestionnaire de périphériques) et permet un réglage très fin de tout cela. En effet, le serveur d’affichage X.org, utilisé sur quasiment toutes les distributions Linux permet via un fichier de configuration d’identifier tout le matériel connecté à l’ordinateur et d’en préciser les caractéristiques. On peut ainsi indiquer quels sont les périphériques connectés, donner leur fonction (clavier, souris, etc.) et décider de n’utiliser que ceux-là et aucun autre. Ainsi, si on identifie la souris et que l’on indique de ne pas activer les nouveaux périphériques, seule cette souris sera utilisée, en brancher une autre ne servira à rien. On identifie également le(s) écran(s) à utiliser et leur(s) caractéristique(s) (de manière très avancée).

Ensuite, on a la possibilité d’associer certains éléments matériels pour les regrouper en une configuration complète. On peut créer plusieurs configurations différentes (utilisant du matériel différent, au moins en partie) et les identifier de manière unique afin de sélectionner par la suite celle à utiliser. De cette manière, seul le matériel identifié comme fonctionnant ensemble sera utilisé, tout le reste restera inactif. Cette méthode est utile par exemple si l’on veut utiliser deux types de claviers (un bépo pour nous, un azerty pour les autres) ou alors brancher un second écran à certains moments et faire en sorte qu’il soit toujours bien réglé (typiquement un enseignant avec un vidéo-projecteur). Utilisée autrement, cette fonctionnalité sera fondamentale pour la réalisation du multiseat.

En effet, on a vu qu’elle permet d’identifier manuellement tout le matériel connecté à l’ordinateur, de le paramétrer avec une immense précision et de créer des dispositions personnalisées, en utilisant uniquement le matériel voulu. On va donc s’en servir pour isoler chaque poste en créant une configuration par poste, ne partageant aucun matériel externe. Tout le matériel interne (carte réseau, disques dur, processeur, mémoire) est une ressource partagée par tous. Les cartes graphiques en revanche sont allouées à chaque poste. Ces dernières sont en effet associées à chaque écran pour créer un dispositif d’affichage complet (carte vidéo +  écran). On peut en allouer une ou plusieurs à chaque poste, cela ne pose aucun problème, même en multiseat. Il est d’ailleurs possible de régler au pixel près la disposition des écrans (mode bureau étendu, les deux écrans peuvent afficher tous les deux une même partie du bureau, on est totalement libre) ou de dupliquer l’image.

X.org nous permet donc de déclarer le matériel à utiliser par chaque poste, c’est une partie essentielle pour le multiseat. Ce logiciel gère officiellement le multiseat depuis sa version 6.9/7.0 (les deux versions partageant les mêmes fonctionnalités), source : http://www.x.org/releases/X11R7.0/doc/html/RELNOTES2.html. Nous verrons plus tard les limitations de ce logiciel et les contraintes que cela pose.

Il est important de noter qu’une limitation technique d’X.org impose l’utilisation d’une carte vidéo par utilisateur. Une même carte ne peut pas être partagée par deux serveurs X et donc par deux utilisateurs. Pour réaliser un multiseat utilisant les différents ports vidéos d’une carte, il faut utiliser Xephyr (un serveur Xephyr par utilisateur). Cette méthode fonctionne mais a quelques inconvénients, comme l’absence de certaines extensions (3D, OpenGL) et des performances inférieures à la méthode utilisée ici. Toutefois, elle a également la réputation d’être plus stable et de fonctionner avec toutes les cartes vidéos. Elle sera donc détaillées dans un prochain article et intégrée au projet si cela se montre nécessaire.

2. Gestionnaire d’affichage :

Nous avons vu que nous pouvons créer plusieurs machines « logiques », mais le serveur X ne peut utiliser qu’une seule configuration à la fois ! Il va de soit que l’on ne peut pas utiliser de manière exclusive deux configurations différentes simultanément, un même utilisateur se servirait de deux jeux de matériel différents et indépendants, mais qui agiraient de façon similaire sur le système. Il faut donc lancer plusieurs instances du serveur X, une par poste, chacune utilisant une configuration matérielle différente. Ainsi, on active de façon indépendante chacun des postes. Par chance, cela est tout à fait possible, il suffit de les lancer les serveurs X un après les autre dans une console virtuelle (pas un terminal graphique). Le problème est ensuite de pouvoir se connecter sur chacun des postes. C’est là qu’intervient un autre logiciel : le gestionnaire d’affichage. Ce dernier diffère selon les distributions et est a pour rôle au démarrage de l’ordinateur de lancer la session graphique (de lancer X.org) et de gérer la connexion des utilisateurs (écran de connexion et divers paramètres liés). Sous Ubuntu 12.04 LTS, ce logiciel est Lightdm et les développeurs ont inclut les fonctionnalités vitales pour le multiseat : la possibilité de lancer plusieurs serveurs X dès le démarrage, chacun utilisant la configuration matérielle voulue ; la gestion des différentes connexion simultanées, des déconnexions ; empêche automatiquement l’extinction de l’ordinateur ; etc.

3. Bilan rapide :

En configurant X.org et le gestionnaire d’affichage, on obtient donc un premier multiseat fonctionnel. Nous faisons dores et déjà face à une première limite : notre solution ne fonctionne que grâce au bon vouloir des développeurs de ces logiciels et des distributions qui les implémentes. Cela est particulièrement vrai pour le gestionnaire d’affichage qui change en fonction des distributions et mêmes des upgrades d’une même distributions. De plus, X.org est très ancien et en fin de vie car dépassé sur de nombreux points. Il sera normalement remplacé par Wayland (qui supporte le multiseat, source), sauf sous Ubuntu qui développe son propre serveur graphique Mir (projet récent, à voir comment il évolue – aucune info sur le multiseat). Toutefois, le multiseat étant assez connu, on peut espérer qu’il sera toujours possible de le réaliser d’une façon ou d’une autre.

IV – Réalisation d’un multiseat basique en utilisant X.org et Lightdm :

1. Introduction :

Nous avons vu que la réalisation d’un multiseat sous Ubuntu 12.04 LTS  passe par la configuration de deux logiciels vitaux : X.org et Lightdm. Nous verrons en détail dans cette partie comment configurer chacun de ces logiciels, explicitant tous nos choix. Cette configuration s’inspire de celles trouvées sur le web, mais elle est unique. Rien n’a été laissé au hasard, chaque morceau a été vérifié, testé et son utilité prouvée par la lecture de documentations. La tâche n’a pas été facile, car toutes les solutions trouvées sont différentes (parfois radicalement) et certaines ne fonctionnent pas. De plus il est parfois difficile, voire impossible parfois, de trouver de la documentation sur certains points, même des ressources anglophones. La configuration ci-dessous sert à expliquer le fonctionnement des fichiers de configuration et des entrées qui nous sont nécessaires. Les fichiers de configuration réellement utilisés sont disponibles ici pour xorg.conf et pour lightdm.conf.

2. Configuration de X.org :

2.1. Généralités :

X.org se paramètre à l’aide de fichiers de configurations, des fichiers textes avec l’extension « .conf ».  Ces derniers se placent dans l’un des répertoire suivant : /etc, /etc/X11, /etc/X11/xorg.conf.d,  /usr/etc/X11, /usr/lib/X11. Par défaut, il n’y a plus de fichier de configuration depuis la version 7.0 de X.org (2005), mais on peut toujours en créer un qui sera alors pris en compte au démarrage de X.org. Pour le multiseat il est conseillé de faire un fichier de configuration par poste, bien que l’on puisse en utiliser un seul. C’est d’ailleurs un unique fichier qui servira d’exemple ici, mais il faut noter qu’en utiliser plusieurs permet une plus grande souplesse, ce sera donc la méthode retenue par la suite.

Le fichier de configuration est aisé à comprendre, il est découpé en plusieurs sections traitant chacune d’un point précis et contenant toutes les informations nécessaires (de nombreuses options sont possibles). Le manuel de xorg.conf explique bien le contenu du fichier, on peut le trouver ici, de plus cette page le décrit en détail et en français (certains passages sont obsolètes car très anciens). Ici, on ne détaillera que ce qui est utile à notre configuration.

Les sections sont identifiée par leur nom et délimitées par les mots clé « Section » et « EndSection ». Dans ces sections, on utilise diverses options dont il n’existe pas de liste exhaustive. Les plus générales sont présentées dans le manuel, mais certaines dépendent des modules optionnels chargés (pilotes graphiques par exemple). Il y a la plupart du temps deux syntaxes possibles pour les options (cela dépend l’option considérée) : « nom_option « valeur » » ou « Option « nom_option » « valeur » ». Le fichier xorg.conf est très sensible, la moindre erreur empêche le serveur X de démarrer. Il faut donc le modifier avec précaution et régulièrement tester les modifications. Nous avons par exemple dû  corriger de nombreuses fois (plus de 50) la configuration depuis la console à cause d’une erreur. Il faut noter que les mots clés ne sont pas sensibles à la casse et que l’underscore « _ » est ignoré, ainsi « ServerFlags » et « server_FlAg » seront corrects, mais on respecte généralement la première syntaxe. Les noms des options sont en plus insensibles aux espaces. Source : « Config file keywords are case-insensitive, and “_” characters are ignored. Most strings (including Option names) are also case-insensi‐tive, and insensitive to white space and “_” characters ».

2.2. ServerFlags :

Cette section permet de définir des options générales pour le serveur X, elles seront héritées par toutes les configurations matérielles. Dans notre cas, on utilise les options suivantes :

  • Option    « AutoAddDevices »    « false » : empêche l’ajout automatique de périphériques (inhibe utilisation de plusieurs claviers/souris sur un même poste) ; permet d’isoler les périphériques d’entrée en fonction du poste.
  • Option    « AutoEnableDevices »    « false » : empêche l’activation automatique des périphériques (ils ne seront pas reconnus dès leur branchement), ce qui peut poser problème car si une souris ou autre est débranchée, on doit relancer la session pour pouvoir la réutiliser. Un script lancé par une règle udev devrait corriger cela, et on garderait donc le contrôle sur chaque périphérique. Ou alors, des InputClass peut-être.
  • Option    « AllowEmptyInput »    « true » : permet au serveur X de démarrer même si aucun périphérique d’entrée n’a pu être initialisé ; option inutile mais préconisée par plusieurs sources et ne génère pas de bug.
  • Option    « DontZap »    « false » : empêche de tuer le serveur X avec une combinaison de touches.
  • Option    « AllowMouseOpenFail »    « true » : permet au serveur X de démarrer même si aucune souris n’a pu être initialisé ; option inutile (et redondante avec « AllowEmptyInput ») mais préconisée par plusieurs sources et ne génère pas de bug.
  • Option    « AutoAddGPU »    « false » : option mystérieuse, utilisée pour les multiseat. Plus d’infos ici (page officielle) ; utilisé ici. Pas plus d’informations trouvées. La description officielle dit «This option is to stop the X server adding non-primary devices as gpu screens ». On ne comprend pas vraiment ce que veut dire « non-primary device » dans notre contexte. La documentation de Gentoo sur le multiseat indique « In case xorg-server 1.13.0 and above is in use, the following must be used to maintain the gpu separation », cette option servirait donc à séparer les GPUs…
  • Option    « DPMS »    « true » : active le DPMS pour l’écran. DPMS : protocole de communication entre la carte graphique et l’écran (donc les deux doivent le supporter). Utilisé pour la synchronisation verticale et horizontale entre-autres. Cela sert aussi pour mettre l’écran en veille s’il ne  reçoit plus de signal de la carte vidéo. Une source : « X autorise l’utilisation des caractéristiques DMPS (Energy Star) avec les moniteurs qui en sont capables. Le programme xset(1) contrôle les délais et peut forcer la mise en veille, l’arrêt, ou les modes d’extinction ».
  • Option    « BlankTime »    « 5 » : Temps en minute avant l’écran de veille (« sets the inactivity timeout for the blanking phase of the screensaver »).
  • Les 3 options qui suivent concernent les écrans et cartes compatibles avec le protocole DPMS. Elles gèrent l’extinction de l’écran après une période d’inactivité. Nous ne connaissons pas leur rôle (les tests ne donnent rien), mais elles sont dans cet ordre (de l’effet le moins important au plus important). La documentation n’est pas claire ; temps en minute ; commentaires du manuel de xorg.conf.
    Option    « StandbyTime »    « 6 » : sets the inactivity timeout for the « standby » phase of DPMS mode.
    Option    « SuspendTime »    « 7 » : sets the inactivity timeout for the « suspend » phase of DPMS mode.
    Option    « OffTime »    « 8 » : sets the inactivity timeout for the « off » phase of DPMS mode.
  • Option    « DefaultServerLayout »    « Seat0 » : indique le poste à charger par défaut si on n’indique pas à X.org lequel utiliser ; inutile dans le cas du multiseat car on configure lightdm pour démarrer X.org avec le poste voulu. Laissé à des fins de débogage (si on rétabli la configuration par défaut de lightdm par exemple) pour que le serveur X ne soit pas perdu.
  • Option    « DontVTSwitch »    « true » : empêche de changer de console virtuelle avec la séquence ctrl+Fn. Important car seul le premier poste a accès à ces consoles, mais si un autre utilisateur fait cette combinaison, le premier poste est affecté et est changé de console virtuelle (donc l’utilisateur du premier poste va se retrouver dans une console sans comprendre pourquoi). On doit par contre le ré-activer pour le premier poste, avoir un accès à une console peut toujours servir.

2.3. Device :

Cette section permet d’identifier et configurer les carte graphique vidéo ; une section par carte (dans le cas du multiseat, sans multi-écran). Dans le cas d’un multi-écran, on utilise une section « Device » par sortie vidéo, en les identifiant de manière unique avec l’option « Screen n », n étant le numéro de la sortie. Numérotation début à 0 et est composée de nombres entiers contigues. Lors de la référence aux écrans dans le « ServerLayout », un écran ne peut être utilisé que si tous les écrans de numéro inférieur le sont. Ainsi, l’écran de la sortie n°1 ne peut être utilisé que si celui de la sortie n°0 y est. L’identification des sorties étant logicielle et non matérielle, le choix du numéro des sorties vidéo est arbitraire.

  • Identifier    « Videocard0 » : permet d’identifier de manière unique cette section et donc tout ce qui s’y réfère.
  • Driver    « nvidia » : indique à X.org quel est le pilote de la carte graphique. Cela dépend de la carte graphique, il ne faut pas se tromper sinon le pilote nécessaire ne sera pas chargé. Voir ici les documentations de chaque carte pour plus d’informations sur les pilotes. En général, « radeon » fonctionne bien avec les cartes AMD, et « nv », « nouveau » avec celles Nvidia ; « vesa » fonctionne aussi mais est trop basique. Le pilote propriétaire « nvidia » est recommandé pour les cartes Nvidia. Le répertoire « /usr/lib/xorg/modules/drivers » liste les pilotes graphiques installés.
  • Screen    0 : permet d’identifier la sortie vidéo sur la carte, la numérotation commence à 0 et est composée de nombres entiers contigus. On ne sait pas quel numéro correspond à quelle sortie, il faut faire des essais. Cette identification permet de configurer un multi-écran pour un poste, où les deux écrans sont paramétrés différemment. Dans une section « ServerLayout », on ne pourra utiliser le moniteur connecté sur la sortie n°1 que si celui sur la sortie n°0 est présent dans la configuration, sinon X.org plante au démarrage.
  • BusID    « PCI:01:00:0 » : numéro du bus PCI de la carte : son adresse physique, permet de l’identifier de façon non-ambiguë. La commande  « $ lspci | grep -E « 3D|VGA » » permet de lister les différentes cartes graphiques. La ligne correspondant à chaque périphérique commence par son adresse physique. Note importante : l’adresse donnée par la commande sera de la forme « 01:00.0 », mais il faut écrire « 01:00:0 » dans le fichier xorg.conf. L’adressage des cartes AGP dans xorg.conf utilise excatement la même syntace (PCI:01:00:0).
  • Option    « ProbeAllGpus »    « false » : pour le pilote « nvidia » uniquement ; permet de ne sonder que les cartes vidéos qui sont connectées à un écran ; comportement par défaut sonde toutes les cartes.

2.4. InputDevice :

Cette section permet de répertorier chaque périphérique de saisie et d’en donner les caractéristiques afin qu’ils soient bien reconnus par le système ; une section par périphérique. On utilise les options suivantes :

  • Identifier    « Keyboard0 » : permet d’identifier de manière unique cette section, donc ce périphérique en lui donnant un nom.
  • Option    « Device »    « /dev/input/by-path/platform-i8042-serio-0-event-kbd » : adresse physique du périphérique (port sur lequel il est connecté), permet de l’identifier de façon non-ambiguë. Voir ci-dessous pour l’identification des périphériques.
  • Option    « GrabDevice »    « true » : peut empêcher certains bugs du clavier ou de la souris.

Pour les claviers :

  • Driver    « evdev » : pilote qui gère les claviers.
  • Option    « XkbRules »    « xorg » : indique les règles utilisées pour interpréter les options XkbModel, XkbLayout, XkbVariant et XkbOptions. On indique généralement « xorg » ou « evdev ».
  • Option    « XkbModel »    « evdev » : type de clavier (105 touches, etc), « xorg » fonctionne très bien.
  • Option    « XkbLayout »    « fr » : langue du clavier.
  • Option    « XkbVariant »    « oss » : variante du clavier (bépo et autrte) ; oss est très bien et fournit de nombreux caractères manquants sur les claviers azerty comme : «»≤≥œ©êæâêþÿûîôöŀïüð’‘ëßä ¬¿×÷¡↖↑↗→↔↓↘↙ à l’aide de la touche altGr..

Le dossier /usr/share/X11/xkb contient les différentes valeurs possibles pour ces options.

Pour les souris :

  • Driver    « mouse » : driver pour gérer les souris ; on peut mettre « Synaptics » si on utilise un pavé tactile de cette marque.
  • Option    « Protocol »    « ExplorerPS/2 » : protocole qui gère la souris ; nombreuses valeurs possibles ; entrées obligatoire, aucune valeur par défaut. Plus d’informations ici : http://ftp.x.org/pub/X11R7.0/doc/html/mouse.4.html. « ExplorerPS2 » gère bien tout (ex : molette et 7 boutons) sans autre réglage. D’autres protocoles existent (ex : PS/2, IMPS/2), mais sont moins bons. Liste complète sur le lien ci-dessus.

Identification des périphériques d’entrée :

Note : toutes ces méthodes ont un défaut, on ne peut pas changer le périphérique de place (le brancher sur un autre port) car ils sont repérés en fonction de leur adresse physique.

a) cat /proc/bus/input/devices (Ne fonctionne pas mais la première partie est très utile pour identifier le périphérique (name + event)) :

Ce fichier contient une liste des périphériques connectés à l’ordinateur et diverses informations utiles, qui permettent de les identifier entre-autres.

Exemple d’entrées concernant le bouton d’alimentation :
I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
U: Uniq=
H: Handlers=kbd event1
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

Le nom nous aide à identifier le périphérique, et la valeur de « Phys » nous permet de l’identifier. On entrera alors la ligne suivante dans la section InputDevice :

Option « Dev Phys » « PNP0C0C/button/input0 »

OU :

Option « Phys » « PNP0C0C/button/input0 »

NOTE : Cette façon de faire a été évoquée ici et utilisée ici, ici et . Mais elle ne fonctionne pas ! Il y a peut-être une façon de l’utiliser mais nous n’avons pas trouvé.. On n’a quasiment jamais à identifier le périphérique utilisé directement dans xorg.conf, rare sont les exemples sur internet et ceux trouvés ne fonctionnent pas. Après 45min de recherche, cette solution a été mise de côté.

2. ls -la /dev/input/by-path/ (MÉTHODE UTILISÉE !) OU ls -la /dev/input/by-id/ :

Ce dossier permet d’identifier les périphériques d’entrée. Il contient des liens menant aux fichiers correspondant à ces périphériques. ces fichiers sont du type « eventn », n étant le numéro de l’évennement. Ce numéro pouvant changer entre les démarrage, on ne s’en sert pas directement. Les liens du dossier /dev/input/by-path/ mènent toujours au bon endroit et ne changent pas, leur nom est donné en fonction de l’adresse physique du périphérique (adresse du port USB ou bus PCI). Ainsi, chaque périphérique est identifié en fonction du port où il est connecté. Le fichier /proc/bus/input/devices aide pour identifier le périphérique voulu. Le « name » nous permet de trouver le bon périphérique et le « handlers » donne l’événement associé.

Exemple d’entrées pour la souris :
lrwxrwxrwx 1 root root 10 mars 15 19:40 pci-0000:00:1d.0-usb-0:1.5:1.0-event-mouse -> ../event11
lrwxrwxrwx 1 root root 9 mars 15 19:40 pci-0000:00:1d.0-usb-0:1.5:1.0-mouse -> ../mouse1

La seconde ligne nous intéresse, elle va nous servir à identifier le périphérique. NE SURTOUT PAS UTILISER LA PREMIÈRE LIGNE, LA SOURIS DEVIENDRAIT FOLLE ET INUTILISABLE. On entrera alors la ligne suivante dans la section InputDevice :

Option "Device" " "/dev/input/by-path/pci-0000:00:1d.0-usb-0:1.5:1.0-mouse"

Méthode similaire pour ls -la /dev/input/by-id/

3. ls -la /dev/input/mouse* :

Cette commande liste tous les fichiers spéciaux correspondants aux souris (un par souris connectée), numérotés de mouse0 à mouse(n-1) s’il y a n souris connectées. Pour identifier quel fichier correspond à quelle souris, il faut lire le fichier /proc/bus/input/devices et lire la partie H: Handlers=mouse0 event1 pour déterminer quel est le numéro de la souris.

On entrera alors la ligne suivante dans la section InputDevice :

Option "Device" "/dev/input/mouse0"
4. dmesg | tail (après avoir branché un périphérique) :

Cette commande affiche les dernières lignes (tail) du tampon du noyau (dmesg), « man dmesg : « dmesg is used to examine or control the kernel ring buffer. The default action is to read all messages from kernel ring buffer. » ». C’est « ring buffer » que j’ai du mal à traduire avec précision.

Quand on connecte ou déconnecte un périphérique, cette action est écrite dans le tampon du noyau et on peut la lire. Cela permet de déterminer quel périphérique vient d’être connecté pour le traiter. Nous ne savons pas si on peut s’en servir aisément pour un script, mais à la main, c’est plutôt pratique. Même si les périphériques ne sont pas ajoutés/activés par défaut, l’évennement est noté ici. Enfin, pour le traitement des périphériques, il faudra regarder aussi les évennements HAL/udev pour les ajouter via un script et voir DevicePresenceNotify, donc se renseigner plus amplement (informations complémentaires à venir).

2.5. Monitor :

Cette section permet de définir les réglages de l’écran (très pointu pour les écrans à tube cathodique, ils ne seront donc pas supportés par la version finale du script). Concrètement, on va conditionner le signal de sortie vidéo pour qu’il soit correctement géré par l’écran. On utilise les options suivantes :

  • Identifier     « Monitor0 » : identifie la section ; une par écran.
  • Option    « DPMS » : active le DPMS (Energy Star) pour l’écran ; tous le supportent maintenant.

2.6. Screen :

Cette section permet de créer un dispositif d’affichage complet en associant une carte vidéo et un écran. L’écran connecté utilisera donc les réglages spécifiés dans la section « monitor », changer d’écran ne se fait pas toujours simplement. On utilise les options suivantes :

  • Identifier    « Screen0 » : identifie la section ; une par écran.
  • Device    « Videocard0 » : référence à la sortie vidéo voulue.
  • Monitor    « Monitor0 » : référence à l’écran voulu.
  • Option    « NoLogo »    « true : pour le pilote « nvidia » uniquement ; auparavant, avec le pilote « nvidia », le logo de Nvidia apparaissait au démarrage de X.org et cette option permettait de l’enlever. Aujourd’hui, le comportement par défaut est de ne pas l’afficher, rendant cette option caduque. Voir http://brainstorm.ubuntu.com/idea/6420/.

On peut également compléter cette section et la section « Monitor » en indiquant les modes possibles pour l’écran (résolution et profondeur de couleur), mais cela dépend de l’écran et X.org détecte tout très bien en général. Mais il faudra penser à l’éventualité d’ajouter ces paramètres plus tard.

2.7. Module :

Cette section permet de donner la liste des différents modules optionnels à charger. On répertorie ici les modules principaux.

Depuis sa version 7.0, X.org est divisé en différents modules et tous ne sont pas chargés par défaut. Les modules listés ici seront chargés au démarrage. Il n’y a pas de liste exhaustive des modules possibles ni de façon simple et rapide de connaître ceux installés sur l’ordinateur (et donc utilisables). Il existe deux façons de déclarer un module : « load « nom_module » » (le nom est sensible à la casse) ou créer une sous-section ayant le nom du module et qui contient des Option (des extensions du module) qui seront transmises au module chargé.

Certains modules sont chargés automatiquement, on peut l’empêcher en utilisant « Disable » au lieu de « Load ». X.org va charger les fichiers correspondant au nom des modules donnés. Toutefois, le nom du module diffère légèrement du nom du fichier. Lorsque l’on nomme le module, on ne doit pas écrire les suffixes « .a », « .o », ou « .so », ni le préfixe « lib » si le nom du fichier correspondant le contient. Ainsi, le fichier « libextmod.so » est référencé par le module « extmod ».

X.org cherche récursivement les fichiers correspondants aux modules dans tous les répertoires spécifiés par le ModulePath (voir ci-dessous), les pilotes, les périphériques de saisie, les extensions et les polices. Il est donc très compliqué d’avoir un aperçu complet des modules disponibles. Toutefois, le contenu du répertoire « /usr/lib/xorg/modules » donne une liste non-exhaustive. Les modules “extmod”, “dbe”, “dri”, “dri2”, “glx” et “record” sont chargés automatiquement s’ils sont présents, à moins qu’ils soient explicitement désactivés par l’option « Disable ». Il est recommandé de charger au moins le module « extmod ».

Le « ModulePath » est une option que l’on peut spécifier dans la section « File » (absente de ce fichier). On utilise la syntaxe suivante : « ModulePath « path1[,path2][…][,pathn] » », on entre donc un ou plusieurs chemins séparés par des virgules. Si plusieurs entrées « ModulePath » sont présentes, elles seront concaténées pour créer le « ModulePath » utilisé par le serveur X. Le chemin par défaut est « /usr/lib/xorg/modules ».

Source : Manuel de xorg.conf pour la version 1.11.3 de xorg-server. Certaines parties ne sont pas valables pour toutes les versions de xorg-server.

  • Load    « extmod » : active de nombreuses extensions très courantes de X.org comme shaped windows, shared memory, video mode switching, DGA, et Xvideo ; toutes ne sont pas forcément disponibles et certaines peuvent être désactivées en utilisant « SubSection « extmod » « omit nom_extension » EndSubSection ». Activé par défaut.
  • Load    « dri » : active le DRI (direct rendering infrastructure), toutes les cartes vidéos le supportent désormais. Permet d’utiliser l’accélération matérielle pour les rendus 3D (c’est la carte vidéo qui travaille et non le processeur ainsi). Sans ce module, c’est le serveur X qui génère ces rendus, faisant tout logiciellement, ce qui consomme beaucoup de ressources. Plus d’informations ici. Activé par défaut.
  • Load    « dri2 » : active le DRI2, amélioration du DRI. Plus d’informations ici et .Activé par défaut.
  • Load    « dbe » : active l’extension de double-buffering (utilise deux tampon pour créer les images), utile pour l’animation ou la vidéo. Activé par défaut.
    Traduction approximative de « http://www.x.org/releases/X11R7.7/doc/xextproto/dbe.html#Introduction » : l’extension DBE fournit une façon standard d’utiliser une double mémoire tampon dans le cadre du serveur X. Deux mémoires tampon snt utilisées, nommées « front » et « back » qui contiennent les images. Le premier tampon est visible par l’utilisateur, l’autre non. Les images successives d’une animation sont créées dans le tampon arrière pendant que l’image précédente est affichée sur le tampon avant. Quand uune nouvelle image est prête, les deux tampons échangent leur rôle, rendant visible la nouvelle image.
  • Load    « record » : active l’extension record, enregistre des événements qui se produisent. Utilisé à des fins de test généralement. Spécification du protocole : http://www.x.org/releases/X11R7.7/doc/recordproto/record.html. Activé par défaut.
  • Load    « glx » : active le rendu OpenGL ; extension faisant le lien entre le serveur X et OpenGL (pour tout ce qui est 3D, etc.). Plus d’informations ici, ici et . Activé par défaut.
  • Load « GLcore » : utilisé par OpenGL, pas plus d’informations trouvées.
  • Load « bitmap » : active le support des polices bitmap pour la rastérisation (http://fr.wikipedia.org/wiki/Rast%C3%A9risationhttp://msdn.microsoft.com/fr-fr/library/ff604996%28v=xnagamestudio.40%29.aspx – traite l’image pour l’affichage sur l’écran). Inutile depuis la version 7.0 de X.org.
  • Load    « vbe » : active l’extension Vesa Bios ; autorise la demande des capacités du moniteur via la carte vidéo.
  • Load    « int10 » : émulateur x86 utilisé pour le démarrage de la carte vidéo secondaire. Devrait être activé si « vbe » l’est. Traduction de « real-mode x86 emulator used to softboot secondary VGA cards. Should be enabled if vbe is enabled ».
  • Load    « ddc » : active l’extension Data Display Channel ; autorise la demande des capacités du moniteur via la carte vidéo.
  • Load    « i2c » : serial bus over which you speak the ddc protocol to get info from the monitor.
  • Load    « freetype »
  • Load    « type1 » : charge les polices « freetype » et « type1 » (ce sont des types de police, donc toutes celles qui y sont associées sont chargées ; polices stockées ici : « /usr/share/fonts »).

2.8. ServerLaout :

Cette section permet d’associer tout le matériel pour former une configuration complète. On peut également y appliquer diverses options, pour écraser celles du ServerFlags par exemple. On utilise les options suivantes :

  • Identifier    « Seat0 » : identifie la section ; une par poste.
  • Screen    0 « Screen0 » 0 0 : n° écran du layout  (identifiant écran – position x – position y) ; voir man xorg.conf.
  • InputDevice    « Mouse1 »    « CorePointer » : indique la souris à utiliser ; CorePointer indique que c’est la souris principale.
  • InputDevice    « Keyboard0 »    « CoreKeyboard » : indique le clavier à utiliser ; CoreKeyboard indique que c’est le clavier principal.
  • Option    « DontVTSwitch »    « true » : pour le pilote « nvidia » uniquement ; permet à l’utilisateur de ce poste d’utiliser les consoles virtuelles et d’y accéder grâce à la combinaison de touches ctrl+Fn.

2.9. Informations complémentaires :

De nombreux autres réglages sont possibles, mais ici on reste le plus général possible afin de s’adapter sans heurt à toutes les plate-formes. Plus tard il sera intéressant d’améliorer cette configuration. Mais dans un premier temps ce n’est pas essentiel.

Notre documentation sur xorg.conf nous a amené à lire quelques options de configuration qui sont obsolètes ou dépréciées. En effet, rien n’étant figé, les options se comportent différemment et évoluent en même temps que le serveur X. Les anciennes options sont souvent conservées pour assurer la rétro-compatibilité mais sont à éviter autant que faire se peut. D’une manière générale, les versions récentes de X.org détectent très bien le matériel de manière automatique et le fichier de configuration n’est là que pour des cas très précis (comme le multiseat). Il faut donc peu décrire le matériel, car cela est inutile et de plus on conserve ainsi un fichier de configuration général et facilement adaptable à d’autres ordinateurs. Ainsi, indiquer la fréquence ou la mémoire d’une carte vidéo n’a plus de sens. On ne doit indiquer que ce que le serveur X ne peut pas deviner, comme les associations de matériel que l’on fait, les pilotes que l’on veut utiliser et autres. Les sites web n’étant pas tous à jour, il est possible de trouver des options archaïque et des exemples de fichiers très détaillés. Pour trier tout ça, il suffit de suivre la règle suivante : tout ce qui n’est pas explicitement utile (option sortie de nulle part, trop précise ou spécifique à un matériel) on jette. On ne va pas faire la liste de toutes les options révolues, mais notons quand même ce deux options que l’on retrouve encore et qu’il faut éviter :

  • dans l’identification des périphériques d’entrée : l’option « Option "Device" "/dev/input/event1 » est à éviter car elle identifie le matériel avec un numéro (ici 1, mais il varie) qui change parfois au démarrage ; ainsi cette option ne permet pas d’identifier correctement les périphériques ;
  • les options « Option « IsolateDevice » « 1:10:0 » » et « Option « SingleCard » « True » » n’ont plus lieu d’être.

3. Configuration de LightDM :

3.1. Introduction :

Nous venons de configurer le serveur X afin qu’il utilise correctement le matériel connecté à l’ordinateur. Nous avons donc créé nos deux postes et nous pouvons utiliser l’un ou l’autre en précisant au serveur X lequel doit être chargé. Toutefois, on ne peut encore se servir que d’un poste à la fois, la configuration est par conséquent limitée à un utilisateur. Pour utiliser le matériel restant, nous devons lancer un second serveur X puis permettre la connexion du deuxième utilisateur sans altérer celle du premier. En d’autres termes, nous devons lancer une seconde session graphique, totalement indépendante de la première. C’est le gestionnaire d’affichage qui est chargé de démarrer et gérer la session graphique des utilisateurs. C’est donc à lui qu’il faut indiquer de lancer deux sessions graphiques et de les gérer en parallèle. Ce n’est pas une tâche triviale, elle est le cœur même du multiseat et les outils nécessaires doivent être intégrés au gestionnaire d’affichage. On ne peut donc pas utiliser n’importe quel gestionnaire d’affichage, il faut qu’il soit pensé pour cela. Heureusement, bien que le multiseat soit peu connu du grand public, les « experts » de Linux qui développent ces logiciels le connaissent et le soutiennent, et font donc le nécessaire pour que le multiseat soit possible. Parmi les gestionnaires d’affichage supportant le multiseat, on trouve LightDM, KDM et GDM (support par GDM assuré par Brian Cameron, voir ici).

3.2. Configuration :

Les gestionnaires d’affichage ont tous une configuration différentes, avec une syntaxe et une sémantique propre. Fort heureusement, ils ne possèdent qu’une liste restreinte d’options (une quarantaine pour LightDM) dont le nom est explicite et ils sont bien documentés. Nous utiliseront ici LightDM, le gestionnaire d’affichage par défaut d’Unbuntu 12.04 LTS. Il n’y a pas de documentation officielle, mais la doc d’Ubuntu (fr)-(en) est très détaillée et il existe un fichier de référence (/usr/share/doc/lightdm/lightdm.conf) qui liste de manière exhaustive toutes les options possibles et les décrit brièvement. Il est ainsi très aisé de faire le tour de la configuration de ces logiciels, contrairement à xorg.conf. C’est pour cette raison que nous ne reviendrons pas sur cette configuration ici, les ressources citées étant complètes. Le fichier de référence que nous utiliseront provient directement de la documentation d’Ubuntu sur le multiseat avec quelques arrangements qui seront détaillés. Sans plus tarder, voici le fichier utilisé :

3.2.1. Version de référence d’Ubuntu :

[LightDM]   # Options générales pour LighDM
minimum-display-number=0    # Nombre minimal d'écrans à utiliser pour le serveur X.
minimum-vt=7   # Première console virtuelle à utiliser, on utilisera celle-ci et celles qui suivent. On peut ne omettre cette option ou indiquer une autre console de départ.

[SeatDefaults]   # Options communes à tous les postes (équivalent au ServerFlag de xorg.conf)
xserver-command=/usr/bin/X   # Commande pour lancer le serveur X, on peut utiliser les options que prend le serveur, elles seront recopiées dans la commande.
greeter-session=lightdm-gtk-greeter   # Écran d'accueil à utiliser, on trouve la liste des valeurs possibles ici : /usr/share/xgreeters/ et on peut en installer d'autres.
greeter-show-manual-login=true    # Permet de se connecter en entrant le nom d'utilisateur et le mot de passe, au lieu de cliquer sur un utilisateur de la liste affichée.
user-session=xubuntu   # Environnement de bureau (Gnome, Unity, etc.), on trouve la liste des valeurs possibles ici : /usr/share/xsessions/ et on peut en installer d'autres.
exit-on-failure=true   # Indique au démon de LightDM de quitter en cas d'erreur. Ainsi, si un serveur X ou un écran d'accueil plante, LightDM stoppe toute l'interface graphique et on se retrouve en mode console.

[Seat:0]   # Options du premier poste, on peut utiliser les même que dans SeatDefaults, les valeurs ci-dessous seront prioritaires.
xserver-command=/usr/bin/X :0   # On précise juste le numéro de l'affichage ; inutile car LightDM l'inclut, voir plus bas.
xserver-config=xorg_seat0.conf   # Indique au serveur X quel est le matériel à utiliser (ici il y a un fichier par poste donc on indique celui voulu).
xserver-layout=Seat0   # Indique au serveur X quel est le matériel à utiliser (ici il y a un unique fichier donc on indique le ServerLayout voulu).

[Seat:1]
xserver-command=/usr/bin/X :1 -sharevts   # On doit obligatoirement rajouter l'otpion -sharevts sur tous les postes excepté le premier, aucune raison logique trouvée.
xserver-config=xorg_seat1.conf
autologin-user=htpc   # Un poste au moins doit avoir un utilisateur qui se connecte automatiquement → désormais inutile.
autologin-user-timeout=15

3.2.2. Version de référence modifiée (détaillée) :

[LightDM]
minimum-display-number=0
minimum-vt=7
[SeatDefaults]
# Commande « /usr/bin/X » inutile
greeter-session=unity-greeter   # écran d'accueil par défaut d'Ubuntu 12.04 LTS
# Option « greeter-show-manual-login » inutile
user-session=gnome-session-fallback    # Bureau proche de Gnome 2
exit-on-failure=true
[Seat:0]
xserver-command=/usr/bin/X   # LightDM indique déja le bon affichage par défaut dans la commande.
xserver-layout=Seat0
[Seat:1]
xserver-command=/usr/bin/X -sharevts
xserver-layout=Seat1
# Aucune connexion automatique n'est nécessaire.

3.2.3. Version de référence que l’on utilise :

[LightDM]
minimum-display-number=0
minimum-vt=7
[SeatDefaults]
greeter-session=unity-greeter
user-session=gnome-session-fallback
exit-on-failure=true
[Seat:0]
xserver-command=/usr/bin/X
xserver-layout=Seat0
[Seat:1]
xserver-command=/usr/bin/X -sharevts
xserver-layout=Seat1

3.3. Informations complémentaires :

Un peu de vocabulaire :

  • Gestionnaire d’affichage (display manager) : logiciel chargé de lancer la session graphique (Xorg + connexion utilisateur + environnement graphique) au démarrage de l’ordinateur.
  • Environnement de bureau : package logiciel incluant le bureau (interface principale de l’utilisateur, les différents bureaux n’ont pas le même design ou la même ergonomie), un gestionnaire de fenêtre et parfois une liste de logiciels par défaut. Les divers environnements de bureau proposent une expérience très différente. Ubuntu, Xubuntu, Kubuntu ou encore Lubuntu ne diffèrent que par ce dernier (on peut donc passer de l’un à l’autre à chaque connexion) mais ont tous une interface et une consommation de ressource très différente.
  • Écran d’accueil, ou écran de connexion (greeter en anglais) : écran s’affichant au lancement de l’interface graphique, permettant la connexion des utilisateurs. Il en existe plusieurs, proposant une configuration plus ou moins fine (cacher certains utilisateurs, image de fond, outils d’ergonomie, etc…).

Afin d’éclairer un peu le choix de ces options, revenons un instant sur les étapes successives du démarrage d’Ubuntu 12.04 (similaire pour toute distribution Linux avec interface graphique). Dans un premier temps, les éléments vitaux de Linux se charge, laissant apparaître un écran de chargement ou un texte décrivant les actions réalisées. Dès la fin de cette étape le système est utilisable à 100%, mais en mode console uniquement. Afin d’avoir une interface plus chatoyante, le système lance alors la partie graphique. Afin d’avoir une interface graphique pleinement exploitable, nous devons lancer les divers éléments la composant et les faire travailler de concert. C’est le rôle du gestionnaire d’affichage. Ce dernier est donc le premier élément composant l’interface graphique. Il va lancer un serveur X avec les options appropriées (dont celles données dans le fichier de configuration), sur les bonnes consoles virtuelles, puis il va démarrer l’écran d’accueil (celui demandé ou celui par défaut). Après ces quelques étapes, l’utilisateur voit apparaître l’écran de connexion et peut se connecter. C’est encore le gestionnaire d’affichage qui s’occupe de la connexion de l’utilisateur, du lancement du bureau et de la gestion de la session graphique durant toute sa durée. C’est donc un logiciel aussi vital que le serveur X, s’il plante, c’est toute la session graphique qui se stoppe brutalement (si X plante, l’utilisateur est juste déconnecté) et on a alors accès au mode console uniquement. Nous voyons donc que l’interface graphique est composée de plusieurs éléments différents, ayant chacun un rôle précis et qu’à chaque étape, on peut intervenir pour modifier le logiciel utilisé. Ainsi, que ce soit le gestionnaire d’affichage, l’écran d’accueil ou encore le bureau, tout est modifiable facilement, un peu comme des légo. Seul le serveur X est imposé, son rôle est bien trop important (il gère absolument toute la partie graphique) et difficile pour qu’on puisse modifier. Le gestionnaire graphique est un logiciel console, qui se lance en amont du serveur X et ne s’occupe « que » de lancer et gérer les outils graphiques, il ne fait rien de tout cela lui même. Pour le multiseat, il suffit donc d’une instance du gestionnaire d’affichage, configurée pour lancer deux serveurs X, deux écrans d’accueil et étant capable de gérer le tout convenablement (avec une grande stabilité ! ).

Enfin, il semble nécessaire de préciser que pour un multiseat fonctionnel, on doit lancer le serveur X avec plusieurs options précises (dont nous ne connaissons pas le rôle exact). Toutes ces options (sauf -sharevts) sont indiquées par défaut par LightDM car il gère nativement le multiseat. Ainsi, bien que la commande de lancement du serveur X est invisible dans le fichier de configuration, il est utile de savoir qu’elle est plus complexe qu’un simple « startx — :0 » et que tous les gestionnaires d’affichage ne nous mâcheront pas le travail (il faudra indiquer nous même les bonnes options). Dans cette commande, LightDM indique lui-même le numéro de l’affichage par exemple. Dans les logs, nous trouvons donc : « usr/bin/X :0 -layout Seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch ». Il ne faut donc pas préciser nous-même le numéro de l’affichage car il ferait doublon avec celui donné par LightDM. De plus, dans le fichier lightdm.conf, il ne faut surtout pas mettre de commentaire sur la ligne « xserver-command » car la commande indiquée est recopiée telle quelle, même le commentaire ! Et comme les options indiquées sont placées au début de la commande, on commenterait tout ce qui suit. Par exemple, « xserver-command=/usr/bin/X #commentaire » donnerait la commande « /usr/bin/X #commentaire :0 -layout Seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch ».

3.4. Problèmes rencontrés :

La configuration ci-dessus fonctionne parfaitement, ou presque… En effet, LightDM plante au démarrage de l’ordinateur pour une raison indéterminée (voir plus bas). En revanche, en le lançant manuellement depuis un terminal tout fonctionne.

Parmi les autres problèmes rencontrés, nous avons noté :

  • la mise en veille est possible, mais au réveil le second poste est annihilé, on peut même éteindre le PC normalement ;
  • quand l’utilisateur du poste 2 se déconnecte, celui du poste 1 est envoyé vers le terminal 8 alors qu’il est censé rester sur le 7 ; un simple ctrl+F7 suffit au retour à la normale mais ce bug est gênant ;
  • on ne peut éteindre le PC qu’avec la commande «# sudo shutdown -hP now », même un compte admin ne suffit pas ;
  • seul le premier poste a accès aux périphériques externes et au son ;

Nous pensons que LightDM est configuré pour ce comporter ainsi, mais nous n’avons pas encore cherché de solution, ni même confirmé que c’est bien lui le responsable. Tout cela fait parti de la liste importante des détails à régler pour obtenir un multiseat propre et totalement fonctionnel.

Retour sur le problème rencontré au démarrage :

Lorsque le système démarre, LightDM n’arrive pas à lancer correctement les deux sessions graphiques. L’analyse des logs a montré un comportement étrange et non expliqué au moment de l’erreur. LightDM parvient à se lancer et à démarrer les deux serveurs X mais une erreur l’empêche de charger l’écran d’accueil du premier poste. L’autre écran d’accueil n’a pas de souci. Nous avons paramétré LightDM pour qu’il quitte s’il rencontre une erreur, nous nous retrouvons donc avec un système sans interface graphique. Ce bug est d’autant plus étrange que lorsque nous lançons ensuite le logiciel depuis la console, il démarre très bien et le multiseat fonctionne sans heurts. C’est en comparant les fichiers de log entre l’échec de lancement et le lancement réussi que nous avons détecté une anomalie dans le comportement du logiciel. Nous ne savons pas d’où elle provient ni comment la régler. Toutefois, l’analyse des logs résultants de plusieurs tentatives de démarrage avec diverses options de configuration ont montré que le comportement de LightDM est imprévisible et parfois incohérent. Avec une même configuration on observe des actions différentes. Si on autorise LightDM à continuer après une erreur, un des deux postes se lance, souvent le 2 mais parfois le 1. De plus, avec la configuration plus haut, nous avons eu une fois un lancement réussi dès le démarrage. Et nous observons un comportement très différent au lancement de LightDM entre deux installations identiques d’Ubuntu (même matériel, même version, à jours, et avec les même fichiers de configuration) : sur l’un le poste 2 se lance puis le 1 (bien que les logs affichent le contraire), sur l’autre le 2 se lance à moitié, puis le 1 entièrement et enfin le 2 termine le lancement, switchant le poste 1 sur le VT-8.

Par manque de temps, après plusieurs heures passées à corriger ce souci sans pouvoir comprendre quoi que ce soit au comportement de LightDM nous avons abandonné temporairement.

4. Problèmes rencontrés lors de l’établissement de cette configuration multiseat :

La réalisation de ce premier multiseat n’a pas été aisée. Avant ce projet, le multiseat nous était totalement inconnu ainsi que les outils nécessaires à sa mise en place. Il a donc fallu une grande recherche pour se familiariser avec ce concept, comprendre son fonctionnement général et trouver le moyen de le réaliser. Il a fallu faire le tri entre les nombreuses méthodes disponibles, éliminer celles qui sont obsolètes ou qui ne fonctionnent pas et comprendre les méthodes opérationnelles. Sur le web, toutes les méthodes sont différentes, chaque sujet sur les forums soulève des problèmes différents et tente de le résoudre. Étant néophyte sur le sujet, il est très difficile d’avancer quand on lit des informations partant dans tous les sens, on ne voit pas le bout du problème, uniquement de nouveaux embranchements à explorer, rendant labyrinthique le chemin vers la solution.

Après de nombreuses lectures, on a décidé de partir sur la solution utilisant plusieurs serveur X. Il a ensuite fallu entrer plus en détail dans la configuration et apprendre le fonctionnement de X.org et surtout de son fichier de configuration. Le plus long a ensuite été de découvrir toutes les options nécessaires, elles aussi changeant totalement en fonction du site web. Cela a impliqué de se documenter sur chacune des options (ce qui peut prendre 30 minutes), tester son utilité réelle et ensuite faire un choix. Les documentations ne sont pas toujours claires, des options sortent d’on ne sait où (aucune liste exhaustive des options possibles), il y en a des centaines, la plupart ne nous concernent pas. Un tri s’est imposé, ce qui est long. De plus, les informations récoltées sur le web ne sont pas seulement incomplètes, certaines sont erronée et l’on s’en aperçoit après de longues minutes de tests et de recherche sur le web. Cela a été particulièrement vrai pour l’identification des périphériques où de nombreuses méthodes ont été trouvées, mais certaines fonctionnent mal voire pas du tout.

Enfin, à chaque modification du fichier de configuration il faut relancer le serveur X en se déconnectant. C’est à ce moment là que l’on détecte les erreurs (X.org refuse de se lancer), qu’il faut ensuite trouver. Pour cela, il faut se connecter en mode console, lancer un éditeur de texte et relire tout le fichier à la recherche de l’erreur (car elle n’est pas toujours indiquée dans notre cas), ensuite, il faut redémarrer l’ordinateur. Cela est arrivé au moins 50 fois durant les tests (pour bien comprendre comment ça fonctionne, il faut tester les limites), et certaines fois le clavier et/ou la souris n’étaient plus reconnus (comme on les associait à des postes, cela posait des soucis), obligeant à démarrer sur un autre système d’exploitation, à modifier le fichier puis à redémarrer.

Pour résumer, beaucoup de temps passé à rechercher et tester énormément de choses. Et ce n’est pas fini, il reste encore pas mal d’options inconnues et une section à regarder : « InputClass » (qui sera utile pour la gestion des périphériques d’entrée). Les imprécisions de la documentations sont très gênantes, amenant à de graves erreurs comme pour le lancement de plusieurs serveurs X sur une même carte (voir plus bas) alors que c’est impossible. En revanche, l’allocation des périphériques d’entrée fonctionne à merveilles.

Terminons en revenant en détail sur une erreur commise, qui nous a particulièrement posé problème. En lisant une première fois les ressources trouvées, nous avons commis une grosse erreur. Nous avons cru que nous pouvions lancer plusieurs serveurs X sur un même carte vidéo à partir du moment où l’on se servait de l’option « Screen » pour identifier chacune des sorties dans la section « Device ». Cela s’est révélé être totalement faux, l’erreur ayant été découverte très tard, après plusieurs essais. Une seconde lecture de toutes les sources s’est révélée nécessaire pour clairement identifier l’erreur ainsi que ses causes. De nombreuses personnes sur les forums disent qu’elles ont réussi à lancer plusieurs serveurs X sur une même carte graphique, d’autres disent que cela est impossible ou l’était à l’époque de la discussion. Par manque total de connaissance, nous avons donc pensé qu’il y avait un moyen de faire cela, au vu des nombreux messages en parlant. Cette information mise en relation avec la possibilité d’identifier chaque sortie vidéo nous a conduit à une grosse erreur, vouloir lancer plusieurs serveurs X sur la carte. Cela ne fonctionnait pas car c’est impossible de cette manière, tout simplement. Ainsi, une des configurations possédait le moniteur connecté sur la sortie n°1 alors que celui sur le n°0 était absent de la configuration (du ServerLayout), causant une erreur. Dans la première lecture, il est possible que certains éléments nous aient échappé, car quelques personnes précisaient qu’il fallait utiliser Xéphyr pour partager une carte entre deux postes. La seconde lecture nous a permis d’éclaircir la situation en trouvant de nombreuses sources, qui associées à notre expérience prouvent que nous nous étions trompé.

Messages ayant amené à l’erreur :

Messages montrant que c’est faux :

5. Conclusion et limites de la solution actuelle :

La méthode actuelle a été testée rapidement. Le multiseat est possible sous Ubuntu 12.04 LTS et fonctionne correctement, tout est stable pour le moment, seul le démarrage est compliqué. Nous avons donc réussi à mettre au point un multiseat opérationnel est facile à mettre en place, il suffit de suivre ce tutoriel [sera bientôt rédigé] et tout se fait rapidement. L’utilisation est ensuite simple, car très similaire à celle d’un ordinateur classique, les sessions sont totalement indépendantes et tout se passe bien tant que l’on se cantonne à de la bureautique ou du web. L’usage familial est donc possible. Malgré tout, nous n’avons pas trouvé la solution miracle. La méthode actuelle est entièrement manuelle, chaque fichier doit se configurer à la main, ce qui est long (installation de logiciels, mise à jour, fichiers de configuration) et entrave toute installation sur un parc conséquent. De plus, les contraintes du système actuel sont très fortes. En effet, la configuration multiseat est statique, on ne peut pas changer de place les périphériques d’entrée (on peut toujours intervertir deux claviers ou deux souris, mais ils seront changés de poste), auquel cas il ne seraient plus reconnus et il faudrait alors modifier les fichiers de configuration. De plus, les nouveaux périphériques n’étant pas activés, si on débranche puis rebranche la souris ou le clavier, ils ne seront plus reconnus, forçant le redémarrage du serveur X. Ensuite, les périphériques de stockage (clé usb ou partitions du disque dur) et le son ne sont accessibles que par le premier poste. Ces contraintes devront être surpassées plus tard par l’amélioration de l’allocation des ressources. La solution actuelle n’est ni robuste (pas de branchement à chaud car pas de gestion dynamique des périphériques) ni sécurisée (aucun contrôle de l’allocation des périphériques ou des ressources). En plus de ces limitations, il y a le comportement étrange de LightDM (décrit dans les problèmes rencontrés avec lui ; IV – 3.4) qui est gênant. Ce sont donc des points fondamentaux à améliorer. Il faut des scripts pour automatiser l’installation puis gérer le multiseat au quotidien.

Il faut noter que l’on ne parle même pas de la gestion du son dans tout ça. Il faudra s’en occuper plus tard.

V – Cahier des charges de la solution envisagée :

L’objectif du projet est d’automatiser le multiseat pour le rendre facile et rapide à mettre en œuvre, d’avoir une méthode fiable, performante, robuste, économe et viable à long terme. La solution sera un ensemble de scripts (uniquement shell dans un premier temps), éventuellement sous forme de paquet dans les dépôts, qui devra respecter les contraintes ci-dessous. Il est important de noter que ces spécifications ne seront pas forcément toutes mises en œuvre, notamment si elles sont impossibles à respecter ou trop contraignantes. Et elles pourront être complétées / modifiées tout au long du projet et seront implémentées au fur et à mesure.

1. Installation totalement automatisée :

L’installation se fera par le biais d’un script qui se chargera d’identifier le matériel, éventuellement en demandant à chaque fois la confirmation de l’utilisateur, puis créera tous les fichiers de configuration nécessaires. Par précaution, les versions précédentes des fichiers modifiés seront sauvegardées et une option du script permettra de remettre le système dans l’état antérieur. On peut aussi proposer à l’utilisateur de fusionner les fichiers de configuration, en concaténant ceux générés par le script dans ceux existant. Il faudra alors prévenir l’utilisateur des problèmes possibles : sections de même identifiant, conflits entre les sections et autre ; cette option se fera aux risques et périls de l’utilisateur. En fin d’installation, le script proposera de redémarrer l’ordinateur.

Tout le long, l’utilisateur sera guidé, des textes détaillés pourront être mis à sa disposition pour lui expliquer le principe général du multiseat, les précautions à prendre ainsi que diverses indications utiles pour le bon déroulement de l’installation et du débogage s’il y a des problèmes. Il faut qu’il comprenne ce que fait le script, pourquoi il fait cela et ce qui va changer dans son système afin qu’il puisse rapidement trouver une piste en cas de soucis et décrire correctement le problème dans le cas d’une demande sur un forum. Il semble également évident qu’il faut apprendre à l’utilisateur comment se connecter en mode console et rétablir les fichiers de configuration sauvegardés en cas de crash du serveur X, on pourra donc lancer le script en mode console. Le script devra aussi vérifier que l’on utilise le bon système d’exploitation, que les logiciels nécessaires sont bien présents, à jour et demander à l’utilisateur d’entrer les informations relatives à son écran cathodique s’il en branche un (car leur réglage est délicat et non automatique ?). On lui dira également que les fichiers de configuration sont très génériques et qu’il peut à loisir les retoucher s’il rencontre des problèmes, en lui rappelant de les manipuler avec prudence. Enfin, on conseillera aussi l’utilisation d’un hub USB par poste pour faciliter les choses.

L’installation pourra se faire en console ou via une interface graphique comme celles de multiseatfx ou bicefalo (plus d’informations sur ces logiciels dans la partie VII). Le script tentera d’identifier chaque écran (la méthode de bicefalo est excellente) et proposera des réglages pré-définis, en permettant à l’utilisateur de les modifier avec précaution. Ensuite, chaque périphérique d’entrée sera détecté et affiché (le nom et l’adresse physique) afin qu’ils soient associés à chaque poste. Enfin, le script demandera de brancher une clé USB sur chaque port USB (ou la même clé port après port) afin d’identifier les ports actifs et de les allouer à chaque poste (bicefalo procède ainsi et cela fonctionne). On doit pouvoir partager un port USB entre plusieurs postes et la liste du matériel reconnue doit être actualisée au cours du déroulement du script. Il est impossible de corriger les erreurs de configuration des utilisateurs, il faudra donc les prévenir que même s’ils mettent un clavier en tant que souris, la configuration sera acceptée (bien qu’elle ne fonctionnera pas).

Au-delà de l’installation, le script permettra la maintenance en proposant de la documentation et une FAQ, en proposant de désinstaller le multiseat (en remettant les fichiers de configuration d’origine) et de modifier tout ou en partie la configuration (soit directement les fichiers, soit via une interface similaire à celle de l’installation qui proposera de tout modifier).

2. Allocation des périphériques et gestion dynamique de ceux-ci :

Le script pourra et devra empêcher d’associer le même matériel d’entrée à deux postes différents (cela va de soi qu’il est impossible de partager une souris entre deux personnes). Ainsi, les ports sur lesquels sont connectés le clavier et la souris ne devront appartenir qu’à un seul poste. Si on les branche sur des ports mutualisés, il seront ignorés par le script. Par contre, on doit pouvoir brancher les périphériques à notre guise à partir du moment où l’on reste sur des ports liés exclusivement à un poste. Si un hub USB est branché, les ports de ce dernier suivront les mêmes règles que celles du port de connexion du hub. On pourra ainsi brancher et débrancher divers hub USB, le script se chargeant de détecter les modifications et de gérer les ports. La répartition des périphériques se fera donc par l’allocation des ports USB de la machine, chose importante car on ne pourra changer la répartition qu’en modifiant les fichiers de configuration. Enfin, le script prendra en compte les ports PS/2 pour les claviers et souris.

Il est absolument impératif que seuls les postes associés aux ports de connexion puissent accéder et utiliser les périphériques qui s’y trouvent. Les autres ne doivent même pas être mis au courant que d’autres ports existent. Chaque poste sera complet et isolé (logiciellement) des autres, comme s’il était un ordinateur à part entière, ce qui explique que l’utilisateur ne doit pas être au courant de ce qu’il se passe à côté. Cela explique aussi que l’on ne puisse voir que ses périphériques, de même que dans une configuration classique, on n’a pas accès aux périphériques du voisin, qui sont eux isolés matériellement. De plus, le fait de pouvoir brancher les périphériques sur le port de notre choix (comme sur un ordinateur classique), implique une gestion dynamique de ceux-ci. Chaque événement doit être pris en compte par le script pour activer / désactiver le matériel, le paramétrer et l’affecter au poste correspondant. En d’autres termes, le script permettra le branchement à chaud de périphériques et créera en quelque sorte des « machines logiques ».

3. Gestion des ressources matérielles partagées (quotas) :

À l’exception des cartes graphiques, toutes les ressources internes à l’ordinateur sont partagées par tous les postes, il faut donc imposer des règles assurant leur bon partage afin qu’un utilisateur ne puisse pas consommer la majorité des ressources. Les parties concernées sont le processeur, la mémoire vive, l’espace de stockage (problème qui ne sera pas traité par notre script car ce n’est pas son rôle), les connexions réseau, le son, les lecteurs DVD et autres « périphériques » connectés en interne (en IDE,  SATA ou PCI par exemple).

Pour le processeur, l’idéal est d’avoir plus de cœurs que de postes afin d’associer un cœur par poste avec un réserve de cœur supplémentaires partagés par tous et alloués dynamiquement à un poste précis en cas de besoin (à condition que cette allocation ne perturbe pas les autres postes, c’est à dire que la charge du processeur causée par les autres utilisateurs est faible) afin d’avoir des performances maximales. Le processeur utilisé est donc supposé très performant. Toutefois, si le nombre de cœurs est égal au nombre de poste, on affecte de manière statique un cœur par poste, sans se soucier de répartir la charge. Si le nombre de postes est supérieur au nombre de cœur, le processeur est entièrement partagé, aucune règle de quota n’est mise en place. Ce seront les paramètres par défaut, mais l’utilisateur doit pouvoir les modifier afin de les personnaliser fortement. Il pourra affecter chaque cœur à un ou plusieurs postes (qui le partageraient) et définir les cœurs de réserves (même s’il y a plus de postes que de cœurs) avec une totale liberté. Note : on peut aussi allouer un temps processeur. Une fois le quota atteint, aucun dépassement n’est autorisé (hormis s’il y a des cœurs en réserve), l’utilisateur continue avec ses ressources CPU allouées. Si un utilisateur n’est pas connecté (ce qui arrivera), le cœur associé sera utilisé avec ceux de réserve, afin de ne pas gâcher de ressource inutilisée. Il faudra voir comment cela se passe s’il se connecte alors que le cœur est utilisé, et oublier cette fonctionnalité si elle pose des soucis de stabilité.

La mémoire vive étant partagée par tous et vitale pour le système d’exploitation, il faut empêcher un utilisateur d’en utiliser une trop grande quantité, ce qui nuirait aux performances et à la stabilité de la machine. Encore une fois, on alloue une quantité égale aux postes, avec si possible une quantité de réserve utilisée pour un utilisateur ayant besoin de plus de ressources. On partage la totalité de la mémoire (pas de quotas donc) s’il y en a très peu en prévenant l’utilisateur de faire attention. Tout comme pour le processeur, l’utilisateur peut modifier les règles de quota pour les ajuster à son goût. En cas d’approche du quota, l’utilisateur est alerté et une fois ce dernier atteint il faut voir quels sont les actions possibles qui garantissent la stabilité du poste. Un système sans mémoire vive disponible n’est plus très opérationnel. Tuer des processus gourmand en ram peut être une solution, ne rien faire et attendre (c’est à dire ne pas donner accès au swap et à plus de ram) en est une autre. Fonctionnent-elles ? Il faudra essayer. Si un utilisateur n’est pas connecté, la mémoire vive allouée est utilisée comme réserve. Il faudra voir comment cela se passe s’il se connecte alors que la mémoire vive dédiée est utilisé, et oublier cette fonctionnalité si elle pose des soucis de stabilité.

La carte réseau est supposée performante, ainsi que le câble Ethernet utilisé (1Gbps), mais il est plus prudent de limiter la bande passante de chaque utilisateur. La vitesse de connexion étant inconnue et impossible à déterminer (une mesure n’est pas représentative), on ne peut malheureusement  trouver de quota simple à gérer de façon automatique. En l’absence de solution, il faudra demander à l’utilisateur la bande passante de sa connexion Internet et de la diviser de manière égale entre les postes. Dans le cas d’une salle de TP ou d’un cybercafé, le seul quota à vraiment gérer serait celui de l’utilisation du câble reliant les postes au commutateur/concentrateur le plus proche et donc il faudrait demander la bande passante du câble réseau. De plus, il faut que les quotas pour la connexion à Internet (réparti le débit de la connexion Internet) et ceux pour les connexions locales (réparti débit du câble réseau) soient indépendants afin que le premier quota ne ralentisse pas les connexions locales. Si un utilisateur n’est pas connecté, la bande passante allouée est distribuée aux autres utilisateurs, de façon équitable (sauf réglage contraire de l’utilisateur). À la connexion de l’utilisateur, la bande passante lui revient de façon exclusive, cela ne posera pas de souci de stabilité.

Les lecteurs DVD et autres doivent être accessibles à tous, soit de façon partagée (si l’un s’en sert, tous y ont accès), soit en attribuant une exclusivité temporaire au poste en ayant besoin. L’utilisateur emmétra alors une requête auprès du script indiquant qu’il va se servir d’une de ces ressources et qu’il ne souhaite pas la partager. Il pourra alors utiliser le matériel de façon confidentielle. En l’absence de demande explicite d’usage exclusif, le matériel sera accessible à tous s’il est utilisé. Si la ressource est réservée par un poste, tous les autres ne pourront y accéder pendant ce temps afin de ne pas gêner l’usage de la machine. De plus, le temps d’utilisation ne peut pas être limité (si on coupe l’accès au lecteur DVD en pleine gravure, c’est quelques peu désagréable pour l’utilisateur), ainsi la ressource est rendu disponible dès lors qu’elle n’est plus utilisée. Le script le détectera si possible, ou l’utilisateur l’indiquera. Par conséquence, la bonne gestion de ces ressources se fera en fonction de la capacité des usagers à vivre en communauté.

Il reste alors le son qui sera géré plus tard, lorsque le multiseat fonctionnera déjà correctement.

4. Stabilité :

La stabilité de la solution est une condition sine qua non à sa mise en place. En théorie, si le programme respecte toutes les contraintes ci-dessus, il devrait pouvoir gérer tous les cas de figure. Toutefois, nous n’avons pas pu penser à tout, chaque bug rencontré devra être répertorié et corrigé. Si un utilisateur a une application qui plante ou même sa session, il ne faut pas que le problème atteigne les autres. Seule la personne concernée doit rencontrer des soucis. Le seul problème général qui puisse être toléré est la panne matérielle contre laquelle un logiciel ne peut pas lutter.

Actuellement, une seule situation est connue pour poser problème : si le serveur X démarre et que l’écran est débranché, il plante. Une fois lancé il gère ça très bien mais pas au démarrage. Cela n’empêche pas le démarrage de lightdm (sauf si on lui indique de quitter en cas d’erreur), mais le poste concerné n’est pas utilisable jusqu’au redémarrage de lightdm, donc de l’ordinateur. Éteindre l’écran puis fermer sa session rend le poste inopérant. Il faudra essayer de forcer le démarrage du serveur X même sans écran.

VI – Matériel nécessaire au multiseat et étude économique :

1. Configuration choisie :

Le multiseat permet de partager un ordinateur entre plusieurs utilisateurs. La puissance requise pour quatre personnes est forcément supérieure à celle pour une personne. Afin de garantir de bonnes performances, l’ordinateur utilisé pour le multiseat est plus performant et plus onéreux qu’un ordinateur classique. Avec l’aide de forumschoixpc.com, nous avons établi une configuration possible pour le multiseat afin de se faire une idée du matériel nécessaire et de son coût :

Pour un total de 1838€, soit 459,5€ par poste complet. Sans les écrans, le coût est de 1038€, soit 259,5€ par poste.

Les cartes mères compatibles avec 4 cartes graphiques sont rares et chères, c’est le désavantage de la solution.

2. Comparaison de cette configuration avec une installation classique (un ordinateur par utilisateur) :

Le principal intérêt du multiseat est d’économiser de l’argent en limitant l’achat initial de matériel, ce qui réduit les coûts de fonctionnement (électricité), de maintenance (installations, mises à jour, pannes, licences, etc…) et de renouvellement. Il est évident qu’en divisant le matériel par 4, on divise d’autant le temps de maintenance passé sur chaque poste et la consommation électrique, ce qui est un gain non négligeable. En revanche, il est bien plus difficile d’estimer le gain sur l’achat du matériel tant les prix sont variables (de 400€ à plusieurs milliers d’euros) pour un ordinateur complet. On peut trouver ce genre de PC bas de gamme complet, avec windows [le produit peut ne plus être disponible] à 380€ (490€ avec 3 ans de garanti), ou ce PC très haut de gamme à 1700€ (garanti 1 an) [le produit peut ne plus être disponible]. Ainsi, en fonction du choix du PC auquel on compare le notre, et donc du choix des performances désirées, les prix sont très différents. Cependant, il va de soi que le multiseat vise à remplacer les PC entrée-moyen de gamme car son principe est de se servir la puissance non utilisée de nos ordinateurs pour les tâches quotidiennes. En effet, la majorité des personnes n’utilisent leur PC que pour naviguer sur le web ou faire des tâches de bureautique, ce qui ne demande généralement que peu de puissance. Le multiseat tire profit des ressources inexploitées pour permettre de partager le matériel tout en conservant de bonnes conditions d’utilisations, on utilise ainsi beaucoup mieux la grande quantité de ressources mise à notre disposition. En revanche, pour du jeu, de la 3D ou tout autre activité lourde, l’ordinateur est fortement sollicité  et il ne dispose donc pas d’une importante réserve, dans ce cas le multiseat n’a pas de sens.

Nous devons donc comparer notre solution avec des ordinateurs à moins de 800€ (on suppose que le prix d’achat du PC est étroitement lié à son utilisation). Mais là encore, comment peut-on comparer les performances d’un ordinateur classique à un ordinateur mutualisé, dont les ressources sont partagées par plusieurs personnes ? D’habitude, on compare la puissance des ordinateur à l’aide de benchmarks, qui sont un indicateur assez précis et permettent de calculer le ratio performance/prix. Mais ces benchmarks utilisent toutes les ressources de l’ordinateur, car il n’y a normalement qu’un utilisateur qui est donc le seul à exploiter ces ressources. Mais dans notre cas, on répartie le matériel entre quatre personnes. Pour connaître la puissance disponible pour chaque utilisateur, on ne peut pas utiliser des tests classiques. Il faudrait donc d’abord créer des quotas au niveau des ressources, puis lancer des benchmarks sur cet ordinateur « bridé », afin de déterminer les performances que l’on peut atteindre si 4 personnes sont simultanément sur le PC.

Il faut aussi tenir compte de l’usage prévu pour notre ordinateur. Ses cartes graphiques entrée de gamme seront parfaite pour de la bureautique ou du multimédia, mais très mauvaises pour le jeu ou tout autre activité demande un puissant GPU. Pour 4 personnes, avec notre processeur chacun aurait un cœur physique (donc deux logiques), ce qui peut sembler peu maintenant que les processeurs quatre cœurs se généralisent dans les ordinateurs moyen de gamme. Mais dans le contexte de la bureautique, posséder plus de deux cœurs est inutile. En effet, très peu de logiciels gèrent le multi-threading (utilisation des différents cœurs). De plus, nous avons fait un test avec un AMD Athlon II x3, un triple cœur cadencé à 3,1 GHz. Nous avons désactivé le 3ème cœur et bridé les deux restants à 2GHz. L’ordinateur ainsi bridé a été utilisé plusieurs mois à titre personnel, pour des tâches quotidiennes similaires à celle pour lesquelles notre configuration est destinée. Et même avec un processeur entrée de gamme, plus tout jeune, sans les technologies du i7 choisi et bridé à 2GHz, les performances étaient au rendez-vous, aucun ralentissement ou autre désagrément n’a été noté, que ce soit sous Windows 7 ou Ubuntu 10.04 LTS. Il n’y a donc pas de crainte à avoir sur la performance de notre solution, mais il est impossible de la situer par rapport aux performances d’un ordinateur classique. Sachant que la mémoire vive ou le SSD ne devraient pas être limitant dans notre usage.

Nous ne pouvons donc que faire des suppositions, rien de concret. Pour notre configuration, nous avons sélectionné des composants haut de gamme, en conservant un bon rapport performance/prix. Notre ordinateur coûte tout de même 1838€, ce qui est énorme et revient à 460€ (tout compris) par poste, soit le prix d’un PC d’entrée de gamme. La comparaison entre quatre ordinateur bas de gamme et celui choisi et à notre avantage, il sera plus performant et avec des composants de très bonne qualité (carte mère, alimentation, écran). Mais l’objectif c’est de comparer les prix de notre ordinateur avec celui de quatre ordinateurs de puissance par utilisateur équivalente, ce que l’on ne peut pas faire. Mais dès que cela sera possible, il sera aisé de créer différentes configurations pour avoir des équivalents avec les ordinateurs entrée de gamme et moyen de gamme. Il faut juste avoir le matériel et faire des tests. Enfin, les écrans à 200€ que nous avons choisi faussent totalement le prix, car ce choix est indépendant du multiseat et un simple écran à 80€ fait l’affaire. Le prix à retenir est celui de 260€ tout compris, sauf l’écran ; tout en prenant en compte que l’on n’a pas la licence de Windows dans ce prix (car on ne peut pas l’utiliser pour le multiseat).

En conclusion, on ne peut pas encore chiffrer les bénéfices du multiseat, mais on peut rester optimiste, il est évident que le coût ne sera pas plus élevé que celui d’un ordinateur par utilisateur. Pour 250€, on trouve quand même ceci, assez impressionnant pour le prix, il aurait une configuration « comparable » à la notre, reste à voir les performances réelles et la qualité des composants.

VII – Deux logiciels existent pour automatiser en partie l’installation :

1. Multiseatfx :

1.1. Présentation du logiciel :

Multiseatfx est un programme entièrement développé par olaf-10, un membre du forum ubuntu-fr.org. L’histoire de ce logiciel commence en 2009 lorsque olaf-10 (alors nommé C2-PO) décide de réaliser un multiseat et demande l’aide de la communauté. Après avoir réussi, il se perfectionne en aidant d’autres personnes à réaliser un multiseat. Il décide ensuite de créer un script qui automatise le tout et le distribue sur le forum (script sous licence GNU GPL). Tout cela se passe sur ce sujet où des membres testent le script et aident olaf-10 à l’améliorer jusqu’à la version actuelle, sortie en mai 2010. Le script a connu de nombreuses versions et d’améliorations. de la version de base très lourde, simpliste et non optimisée réalisée par un débutant du shell jusqu’au paquet debian actuel il y a eu un long chemin. On trouve sur ce sujet une personne essayant une des premières versions du script et réglant les problèmes rencontrés en discutant avec son créateur.

Actuellement, le script n’est plus mis à jour et sa compatibilité s’arrête à la version 10.04 d’Ubuntu. Mais le projet, bien qu’abandonné est mature et sa reprise est très intéressante.

1.2. Test du logiciel :

Nous avons utilisé Ubuntu 10.04 64 bits, à jour et deux cartes graphiques Nvidia GeForce 8800 GT avec le pilote nvidia.

Le script se lance via un terminal après installation du paquet, et ouvre une interface graphique qui nous guide pour l’installation. On choisit le clavier à associer au premier poste, puis au second, puis les souris et enfin les cartes vidéo. À chaque fois, on nous donne la liste complète des périphériques de saisie, avec un identifiant mélangeant le nom et le port de connexion. C’est une solution qui fonctionne mais pas entièrement ergonomique et on peut mettre une souris en tant que clavier… Après l’installation, on est invité à redémarrer le PC.

Le script ne fait que modifier des fichiers de configuration et créer des règles udev, il est donc totalement transparent pour l’utilisateur, on se connecte normalement et utilise l’ordinateur comme d’habitude. La solution semble fonctionner comme si on modifiait nous même les fichiers nécessaires. Toutefois, les fichiers de configuration créés ne sont pas utilisés par le système, il semble manquer quelques éléments au script pour terminer le travail. Du coup, il est sans effet, mais en faisant manuellement les quelques réglages restant, on doit pouvoir s’en sortir. Mais le script ne faisant pas tout le boulot nécessaire, nous n’avons pas poussé plus loin.

Outre l’installation, le script nous permet de modifier nous même les différents fichiers de configuration et d’ajouter des utilisateurs (lance alors l’interface classique du système pour la gestion des comptes).

Ce script mais il semble très prometteur bien qu’il ne fonctionne pas totalement. Le vrai  point noir est l’absence totale de documentation et l’abandon du projet par son créateur qui empêchent d’exploiter totalement le script sans passer par une analyse complète et minutieuse de son code source. Nous retenterons l’expérience après avoir réalisé cette analyse.

1.3. Quelques captures d’écran :

1

Écran d’accueil.

2

Configuration du multiseat, affiche la liste des périphériques et sélectionne celui que l’on souhaite associer au poste.

3

Choix de la carte vidéo

4

Plusieurs écrans apparaissent lorsque l’on modifie les fichiers de configuration.

5

Liste des fichiers que l’on peut modifier (chemins non-indiqués).

2. Bicefalo :

Bicefalo est un programme permettant la configuration d’un multiseat facilement via une interface graphique. C’est un logiciel libre, peu connu qui n’a pas de site officiel mais seulement quelques pages ici hébergées par google. Bicefalo utilise la méthode avec plusieurs serveurs Xephyr pour fonctionner, permettant l’usage d’une seule carte graphique pour plusieurs personnes mais ne permettant pas des performances excellentes. Il est compatible avec Ubuntu 11.05 (32 et 64 bits) et Ubuntu 12.04 (32 bits).

2.1 Test du logiciel :

2.1.1 Installation :

L’installation de Bicefalo est rapide et aisée. Il suffit de lancer un script python via un terminal et une interface graphique sobre et claire nous permet de configurer rapidement notre matériel. Un wiki est disponible ici détaillant chaque étape de l’installation à l’aide de captures d’écran. Nous avons utilisé Ubuntu 12.04 32 bits, à jour et une carte graphique ATI Radeon 9550 avec le pilote radeon pour le test.

Le script détecte d’abord les écrans connectés et les résolutions possibles pour chacun d’eux, il nous suffit de sélectionner celle voulue. À cette étape, on reconnaît les écrans grâce à leur résolution et au nom de leur sortie vidéo (VGA-0, DVI-0, etc.). On choisit aussi le nombre de postes à créer, puis une autre page référence tous les claviers et souris connectés, que l’on doit associer à chaque poste. Il est possible de les brancher au fur et à mesure et d’actualiser la liste pour faciliter l’installation. Les périphériques sont identifiés par leur port de connexion, il est préférable de ne pas le changer par la suite (non testé en revanche). Ensuite, on associe chaque port USB à un poste. On branche une clé sur chaque port (ou la même port après port), le script détecte le port USB activé et permet de l’allouer à un poste. Une fois tout cela fait, on redémarre l’ordinateur. Trois utilisateurs sont créés (car deux postes configurés dans l’exemple), un par poste et un pour activer le multiseat.

L’installation est simple et rapide, seule l’identification des périphériques d’entrée est laborieuse car leur nom n’est pas donné, seulement leur port de connexion. Mais en les branchant un à un on y arrive. Le seul souci c’est que le script ne s’arrête pas à la fin, ce qui laisse penser à une erreur mais ce n’est pas le cas.

2.1.2. Utilisation :

Pour utiliser le multiseat fraîchement configuré, on doit se connecter à un compte spécial nommé « multiseat » et utiliser l’environnement de bureau « multiseat », le mot de passe est donné sur le wiki de bicefalo. Un bureau se lance alors sur chacun des écrans, avec une console ouverte qui demande le mot de passe de l’utilisateur correspondant au poste. Ce n’est pas très ergonomique car la première fois on ne comprend pas bien ce que l’on doit faire. De plus, les utilisateurs sont imposés, donc on ne peut pas envisager une telle solution pour permettre à diverses personnes d’utiliser leur compte personnel. Une fois le mot de passe entré, un script se lance dans la console, ne s’arrêtant jamais et affichant de nombreux messages d’erreurs. Le bureau utilise Unity mais dans une version très bogué et inutilisable (cf. photos). Le lanceur de gauche n’apparait pas (mais est bien présent), tout comme la barre horizontale en haut. Rien ne fonctionne vraiment. Pour en finir avec les soucis d’affichage, le bureau ne prend pas tout l’écran, mais qu’une partie, une superbe « image » de fond prenant la partie non utilisée. Le clavier et la souris sont bien séparés, ainsi que les ports USB (tentative de connexion d’une clé ; tests peu poussés à cause des problèmes de l’interface). Les utilisateurs ne peuvent pas éteindre le PC, ils doivent tous se déconnecter et on doit ensuite appuyer sur le bouton d’alimentation. Enfin, cette solution implique un temps de démarrage très long, beaucoup trop long.

2.1.3. Conclusion :

Bicefalo utilise une méthode peu performante et qui visiblement ne fonctionne pas du tout. Seul bon point, l’installation qui est astucieuse et bien pensée.

2.2. Photos prises lors de l’utilisation :

Comme il était impossible de faire des captures d’écran, quelques photos de mauvaise qualité illustrent toute la magie de ce logiel :

1

Écran de connexion de lightdm (un seul, l’affichage est dupliqué).

2

Choix de l’environnement de bureau.

3

Multiseat actif…

5

Le bureau que l’on a après connexion, on voit clairement tous les problèmes.

3. Conclusion sur ces logiciels :

Le test de ces deux programme a été très intéressant, ils utilisent tous deux une méthode d’installation bien pensée. Malheureusement, aucun des deux ne nous satisfait, le premier est incomplet et le second ne fonctionne pas. Toutefois, bien que ces programmes ne nous conviennent pas, multiseatfx est une bonne base qu’il suffit d’améliorer pour l’adapter à nos besoins. Il y a beaucoup à faire, mais c’est toujours mieux que je repartir de la page blanche.

VIII – Travail à réaliser pour atteindre l’objectif :

Le tout premier objectif du projet est de créer un multiseat statique pour deux utilisateurs simultanés. Ce travail, quasiment achevé et est en cours de test. Divers bugs ont déjà été rencontrés, il faudra les corriger avant d’aller plus loin. Pour préparer la suite, on tâchera de séparer chaque poste dans un fichier de configuration dédié, le fichier xorg.conf ne servant alors qu’au options de base.

Ensuite, il faudra modifier la méthode d’identification des périphériques pour associer des ports USB et PS/2 aux différents postes et permettre le branchement à chaud des périphériques sur ces port ainsi que l’isolation logicielle des ports entre les postes. Chaque poste simule un ordinateur indépendant sur lequel on peut brancher plusieurs écrans (en utilisant une ou plusieurs cartes graphiques pour ce même poste) et les périphériques de notre choix, même plusieurs claviers. Ces modifications très importantes du fonctionnement du multiseat se feront petit à petit. Dans un premier temps, on ne fera que permettre de brancher à chaud les périphériques d’entrée sur des ports bien précis (à l’aide des InputClass) et on partagera les autres. La seconde étape consistera en l’écriture de règles udev (se renseigner sur udev et HAL) et peut-être d’un script ou autre pour séparer les ports USB puis reconnaître convenablement tout ce qui s’y trouve. Des règles d’allocation s’appliqueront sur chaque port USB et seront héritées par tous les ports d’un hub qui y serait branché. Lorsque le travail sur cette partie débutera, elle sera découpée en différentes sous-étapes plus détaillées et traitant des règles imposées par notre « cahier des charges ».

Il restera encore de nombreuses choses à faire, mais il est trop tôt pour prévoir un planning complet ou même une liste de tout ce qu’il y a à faire. Le travail à effectuer sera compléter au fur et à mesure.

Phase 1 : Recherche massive de renseignements

Le projet débute par une grande recherche sur le Web afin de trouver un maximum de sources traitant du sujet. Cet article répertorie tous les liens trouvés, donnant une brève description du contenu de la page. Les liens sont classés par catégorie et dans chaque catégorie, du plus utile au plus dispensable.

1. Documentations officielles :

  • Documentation Gentoo : multiseat TUTORIEL PLUTÔT COMPLET
    • recommande un hub/seat pour le branchement à chaud, même de périphériques inconnus ;
    • recommande d’utiliser les mêmes cartes graphiques -> plus stable et simple à gérer ;
    • son : plusieurs options :
      • utiliser une carte son par seat ;
      • utiliser une seule carte son -> son partagé entre les seats ;
      • utiliser une seule carte son muti-canal et séparer les canaux dans des cartes sons virtuelles ;
    • la façon la plus simple d’obtenir la première option est d’utiliser des cartes son USB ou des cartes vidéo avec des sorties HDMI ;
    • recommande un fichier de configuration par seat et l’usage des InputClass (qu’il décrit) ;
    • les options communes à tous les seats devraient être dans /etc/X11/xorg.conf.d et le fichier xorg.conf devrait être peu rempli ;
    • donne des conseils sur udev et l’identification des périphériques ;
    • donne des conseils pour la gestion du son.
  • Documentation Arch Linux : multiseat : TUTORIEL MULTISEAT STATIQUE
    • exactement comme on a fait ;
    • donne un exemple des fichiers de configuration.
  • Documentation Ubuntu : udev : TRÈS UTILE
    • tutoriel sur Udev.
  • Documentation X.org : multiseat : QUELQUES LIENS VERS D’AUTRES SITES
    • deux approches différentes :
      • plusieurs serveurs X -> plus performant mais soucis de compatibilité ;
      • plusieurs serveurs Xephyr -> moins performant mais compatibilité accrue.
  • Documentation Ubuntu : multiseat : UTILE MÊME SI INCOMPLET
    • tutoriel sur le multiseat donnant les pistes importantes à suivre.
  • Documentation Debian : multiseat
    • exemple d’un multiseat statique.
  • Documentation Fedora : multiseat : RIEN DE TRÈS UTILE

2. Solutions commerciales :

3. Forums :

4. Blogs et sites francophones :

5. Blogs et sites anglophones :

Objet de ce blog

Je suis étudiant en L1 Informatique à l’université de Pau. Dans le cadre de mes études, j’ai été chargé d’étudier les solutions d’informatique multi-postes (multiseat) existantes dans le but de trouver la solution la plus adaptée à un déploiement dans des salles informatiques.

Ce blog me permettra de rédiger mes avancées quotidiennes afin d’avoir une trace de tout ce qui a déjà été traité, et de tenir informé l’enseignant qui m’encadre. L’objectif final est de réaliser une installation multi-poste sur la distribution Linux « Ubuntu » dans sa version 12.04 LTS, ce sans utiliser de logiciel payant ou propriétaire. Une fois la méthode trouvée, mon but est de l’automatiser au maximum et de créer un mode d’emploi, pour en rendre la mise en œuvre la plus aisée, rapide et stable possible.