[OpenBSD]

[Index de La FAQ] [Section 10 - Gestion du Système] [Section 12 - Questions Spécifiques Aux Plates-Formes Et Au Matériel]

11 - Le système X Window


Table des matières


11.1 - Introduction à X

Le système X Window (parfois dénommé simplement "X" ou, incorrectement "X Windows") est l'environnement qui fournit les services graphiques à OpenBSD et les autres systèmes de type Unix. Cependant, seul, X n'apporte que très peu de fonctionnalités : il faut également avoir un gestionnaire de fenêtres afin d'offrir une interface utilisateur. La plupart de ce que l'on percevra de X viendra du gestionnaire de fenêtres et non de X lui-même. OpenBSD fournit une version libre des gestionnaires de fenêtres fvwm(1) et cwm(1), bien que vous puissiez utiliser également un des autres gestionnaires présents dans les paquetages. Effectuez une recherche avec le mot-clé "window manager" afin d'obtenir une liste des gestionnaires de fenêtres disponibles.

X est considéré comme un protocole fonctionnant sur le mode "client-server" mais cette terminologie peut parfois prêter à confusion. L'ordinateur avec l'affichage graphique à l'écran est le "serveur X". L'application qui définit ce que le serveur X doit afficher à l'écran est le "client X" même s'il s'agit d'une machine bien plus puissante dans un centre d'hébergement. Ce modèle peut être utilisé afin d'avoir des applications gourmandes en ressources processeur (clients X) tournant sur une machine très puissante mais utilisant un serveur X tournant sur une petite machine de faible puissance sur votre bureau pour afficher leurs interfaces.

Il est possible de faire tourner des clients X sur un système sans support graphique. Ainsi, on pourrait avoir une application (le client X) tournant sur un mvme88k et affichant son interface sur un alpha (le serveur X). Puisque X est un protocole bien défini et multiplate-forme il est même possible d'avoir une application X tournant (par exemple) sur une machine Solaris et utiliser une machine OpenBSD pour l'afficher.

Le client et le serveur peuvent également tourner sur la même machine et pour la majorité de cette documentation, c'est ce que nous supposerons.

11.1.1 - Quelle puissance d'ordinateur est nécessaire pour faire tourner X ?

X en lui-même est un programme très lourd et un ordinateur rapide sera idéal si vous le lancez et l'arrêtez régulièrement. Cependant, une fois démarré, il reste très réactif même sur une machine modeste. Afin d'avoir une meilleure réactivité sur certaines plates-formes même si vous ne travaillez qu'avec du texte, il vous sera nécessaire de faire tourner X. Ces plates-formes, telles que sparc et sparc64 ont été prévues pour fonctionner avec une interface graphique, et le mode console est très lent.

Ceci dit, l'utilité de faire tourner X est généralement d'utiliser des applications X. Certaines de ces applications sont très peu gourmandes, d'autres vous sembleront utiliser tout le processeur et la RAM que vous leur octroierez. Évidemment, certains utilisateurs n'utilisent X qu'afin de bénéficier de nombreux xterm(1)s, ce qui reste possible même sur du matériel modeste.

11.1.2 - Puis-je bénéficier d'une interface graphique sans X ?

Si l'on considère que les graphiques ASCII ne sont pas satisfaisants, cela nécessiterait un pilote framebuffer pour console. Quelques systèmes d'exploitation offrent un tel pilote ce qui n'est pas le cas pour OpenBSD et il n'y a pas vraiment d'intérêt pour cela parmi les développeurs.

11.2 - Configurer X

Bonne nouvelle : Dans la vaste majorité des matériels de la plupart des plates-formes, X ne requiert pas de configuration du tout, il fonctionne sans rien faire.

Le détail de la configuration détaillée de X varie considérablement d'une plate-forme à l'autre. Dans tous les cas, il y aura des instructions et des informations propres à la plate-forme dans le fichier /usr/X11R6/README du système sur lequel il est installé.

Plusieurs plates-formes requièrent le pilote d'aperture xf86(4) qui offre un accès à la mémoire et aux ports d'entrée/sortie de la carte VGA ainsi qu'aux registres de configuration PCI nécessaires. Ce pilote doit être activé avant d'être utilisé soit en répondant "yes" à la question suivante posée durant l'installation du système :

Do you expect to run the X window System [no]
soit en changeant la valeur de machdep.allowaperture en une valeur non nulle appropriée à votre plate-forme dans le fichier /etc/sysctl.conf et en redémarrant la machine (pour raisons de sécurité, cette valeur sysctl ne peut pas être changée après le lancement de la machine). Il existe des conséquences sur la sécurité, ne le faites pas si vous n'en avez pas vraiment besoin.

11.2.1 - alpha

/usr/X11R6/README pour alpha.

Mettez machdep.allowaperture=1 dans /etc/sysctl.conf.

Les cartes TGA ainsi que certaines VGA sont supportées. Aucune configuration supplémentaire ne devrait être nécessaire.

11.2.2 - amd64

/usr/X11R6/README pour amd64.

Mettez machdep.allowaperture=2 dans /etc/sysctl.conf.

Pour la vaste majorité des utilisateurs, X sous amd64 se configure automatiquement avec succès, aucune manipulation supplémentaire ne devrait être nécessaire. Si une configuration spécifique est nécessaire, utilisez la procédure X -configure comme expliquée plus bas.

11.2.3 - armish

Pas de serveur X, seulement des clients.

11.2.4 - hp300

/usr/X11R6/README pour hp300.

11.2.5 - hppa

Pas de serveur X, seulement des clients.

11.2.6 - i386

/usr/X11R6/README pour i386.

Mettez machdep.allowaperture=2 dans /etc/sysctl.conf.

Pour la vaste majorité des utilisateurs, X sous i386 se configure automatiquement avec succès, aucune manipulation supplémentaire ne devrait être nécessaire. Si une configuration spécifique est nécessaire, utilisez la procédure X -configure comme expliquée plus bas.

11.2.7 - landisk

Pas de serveur X, seulement les clients.

11.2.8 - loongson

Pas besoin de configuration.

11.2.9 - luna88k

Pas de serveur X, seulement les clients.

11.2.10 - macppc

/usr/X11R6/README pour macppc.

Mettez machdep.allowaperture=2 dans /etc/sysctl.conf.

Les systèmes PPC Macintosh peuvent fonctionner sous deux modes différents : "accéléré" et "framebuffer" (non accéléré).

En mode "framebuffer", le système tournera avec 8 bits par pixel et la résolution vidéo sera contrôlée par l'environnement Macintosh, vous devrez donc garder une petite partition sous MacOS sur votre disque afin de pouvoir changer la configuration. Ce mode à l'avantage de "fonctionner tout simplement" mais il peut apparaître comme statique et frustrant (par exemple, changer la résolution peut demander un redémarrage sous MacOS).

Si votre Macintosh possède un système vidéo basé sur de l'ATI il peut tourner en mode X accéléré ce qui offre de meilleures performances et plus de contrôle sous l'environnement OpenBSD. Les cartes vidéo NVIDIA présentes dans certains systèmes macppc devraient également fonctionner dans la plupart des cas. Le fichier README contient des détails sur la configuration du pilote accéléré, basez-vous sur l'exemple qu'il fournit.

Bien que le fichier README contienne des détails pour utiliser une souris Apple standard à un bouton sous X, à moins d'utiliser un portable, il vous est vivement recommandé d'acheter une souris tierce plus moderne avec trois ou plus de boutons.

iMacs CRT et X

Les iMacs ont très rarement un CRT (de nos jours), en ce sens qu'il a un balayage de fréquence horizontale fixe. La tentative d'utilisation d'un balayage horizontal de vitesse en dehors d'une fourchette très étroite fera que le moniteur ne s'allume pas. Les lignes suivantes, ajoutées à xorg.conf dans la Section "Monitor" semblent faire que beaucoup d'iMacs CRT dans la plage 333MHz à 500MHz (et probablement plus !) fonctionnent bien :
        HorizSync       60.0 - 60.0
        VertRefresh     43.0 - 117.0
Vous pouvez restreindre la limite inférieure de VertRefresh pour des valeurs que vous êtes plus susceptibles de trouver acceptables, par exemple 70.

11.2.11 - mvme68k

Pas de serveur X, seulement les clients.

11.2.12 - mvme88k

Pas de serveur X, seulement les clients.

11.2.13 - sgi

X fonctionne sur les systèmes framebuffer O2 en mode non accéléré.

11.2.14 - sparc

/usr/X11R6/README pour sparc.

Avec un seul framebuffer supporté il n'y a pas besoin de configuration. Si vous souhaitez utiliser une configuration multi-affichage, lisez le README ci-dessous pour plus de détails.

La résolution est contrôlée par le firmware avant de démarrer OpenBSD.

11.2.15 - sparc64

/usr/X11R6/README pour sparc64.

La plupart des configurations simples "fonctionne" normalement. Si la vôtre ne fonctionne pas ou si vous souhaitez obtenir de la fantaisie, consultez le fichier README ci-dessus.

11.2.16 - vax

Lisez /usr/X11R6/README pour vax.

Le serveur X ne fonctionne pour l'instant que sur les modèles VAXstation 4000 en utilisant soit le framebuffer lcg(4) soit le framebuffer lcspx(4).

11.2.17 - zaurus

/usr/X11R6/README pour zaurus.

Pas de configuration nécessaire, X "fonctionne tout simplement".

11.3 - Configurer X sur amd64 et i386

Si vous n'avez pas essayé juste le démarrage de X, stop ! Ne travaillez pas si vous n'en avez pas besoin ! La plupart des utilisateurs i386 et amd64 trouveront que X fonctionne sans aucune configuration manuelle.

11.3.1 - Configuration de X.Org

Parfois, X ne "fonctionne pas simplement" comme désiré, et parfois, vous aurez besoin de configurer quelque chose qui ne fonctionne pas.

Si X ne fonctionne pas comme désiré avec votre système, vous devrez créer un fichier de configuration. Un bon endroit pour démarrer (et quelquefois le seul bon endroit !) est d'exécuter Xorg(1) lancé avec le mode "X -configure". Cela chargera tous les pilotes disponibles, détectera le matériel et se basant sur ce qu'il trouve, écrira un fichier xorg.conf qui pourra ou non fonctionner. Même s'il ne fonctionne pas il représentera un bon point de départ à la création d'une configuration qui fonctionnera comme souhaité.

Une autre façon de configurer X mais qui demande du temps est d'utiliser votre moteur de recherche favori afin de trouver quelqu'un d'autre qui aurait rencontré et résolu votre problème. Il faut remarquer que les fichiers xorg.conf des autres OS Unix-like fourniront souvent une aide très utile dans la manière de faire fonctionner X sur un matériel similaire. Bien que cette méthode ne soit pas mauvaise, nous ne nous y attarderons pas plus.

11.3.2 - Notre machine d'exemple

Pour une démonstration de configuration X, nous utiliserons un vieux système équipé d'un Celeron 400MHz et d'un port AGP. La carte vidéo sera une ancienne carte AGP visible dans le dmesg à la ligne :
vga1 at pci1 dev 0 function 0 "3DFX Interactive Banshee" rev 0x03
Il s'agit d'une ancienne carte haut-de-gamme qui n'est à présent plus vraiment supportée par les nouvelles versions des systèmes d'exploitation "principaux". L'écran relié au système est un moniteur CRT "Sony Multiscan G400 19" et il serait plaisant de pouvoir afficher une résolution de 1280x1024 sur celui-ci avec une fréquence de rafraîchissement décente et des couleurs 24 bit.

En premier lieu, après avoir installé OpenBSD avec X (et être certain que le pilote d'aperture est activé dans le noyau), voyons ce que la détection et la configuration automatique de X.Org nous propose, après tout nous pourrions être chanceux. Nous allons nous identifier puis utiliserons donc la commande startx(1). L'écran devient blanc quelques secondes puis nous obtenons le fond d'écran en "échiquier" de X, le curseur X et enfin une fenêtre xterm.

Ça marche !

Plus ou moins. Bien que le système soit pleinement fonctionnel, il ne paraît pas avoir détecté une quelconque des fonctionnalités de l'écran et tourne à très basse résolution (640x480). Nous espérons pouvoir faire mieux que cela. Bien mieux en fait. Cependant, cela signifie que nous aurons besoin de créer notre propre fichier de configuration xorg.conf.

Servons-nous de la commande "X -configure" afin de créer un fichier xorg.conf de base. Vous devrez lancer la commande suivante en tant qu'utilisateur root :

# X -configure
 [...]
Your xorg.conf file is /root/xorg.conf.new

To test the server, run 'X -config /root/xorg.conf.new'
Au fait, ce message est sérieux ; utilisez le chemin complet vers votre fichier xorg.conf.new même s'il repose dans votre répertoire actuel par défaut. Sinon, X(7) ne trouvera pas le fichier et il utilisera la configuration par défaut, et si cela a fonctionné, vous ne devrez pas utiliser ce processus ! Cela permettra de vous éviter de déboguer le pourquoi cela ne fonctionne pas. Faites-nous confiance là-dessus.

Donc, faisons comme il dit et voyons ce que nous obtenons :

# X -config /root/xorg.conf.new
À présent, tout ce que nous avons est un écran noir. Les choses avaient pourtant si bien commencé...

Le moment est peut-être venu de vous parler des différentes manières de sortir de X lorsqu'il démarre de cette façon. Par ordre de préférence :

Heureusement pour nous, CTRL-ALT-Backspace fonctionne bien et nous voici revenu à l'invite de commandes. Bien, à présent nous devons regarder si nous pouvons comprendre ce qui s'est mal passé. Tout d'abord, nous devrions jetez un œil sur ce à quoi X s'imagine et qui est enregistré dans le fichier /var/log/Xorg.0.log. Dans ce cas, il semble que X pense que tout tourne bien et il n'y a pas d'erreurs flagrantes dans le journal d'événements (les lignes commençant par "(EE)" sont des erreurs).

Maintenant, il est utile de connaître votre matériel. Brancher ce système sur un moniteur différent alors que l'écran noir est toujours présent affiche le message "Sync. Out of Range" sur l'écran. Apparemment donc, la configuration que X nous a fourni ne fonctionnera pas sur ce moniteur et peut-être même sur AUCUN si le mode sélectionné ne fonctionne pas avec cette carte particulière (souvenez-vous que X détecte la puce sur la carte et ce qu'elle est potentiellement capable de faire, pas la façon dont le fabricant a intégré tous les éléments). Différents moniteurs réagiront différemment lorsque le rafraîchissement est mauvais, certains tenteront tout de même d'afficher ce qu'ils peuvent, d'autres passeront en mode de conservation d'énergie alors que d'autres émettront d'horribles bruits ou afficheront des messages informatifs à l'écran. Ce moniteur ne semble rien faire de tout cela. On notera de ne PAS utiliser cet écran pour une configuration initiale de X dans le futur.

En jetant un œil au fichier xorg.conf.new l'on peut voir ceci :

Section "Monitor"
        #DisplaySize      370   270     # mm
        Identifier   "Monitor0"
        VendorName   "SNY"
        ModelName    "SONY CPD-G400"
 ### Comment all HorizSync and VertSync values to use DDC:
        HorizSync    30.0 - 107.0
        VertRefresh  48.0 - 120.0
        Option      "DPMS"
EndSection
Pour le test, essayons d'utiliser DDC ("Data Display Channel", une façon que possède le moniteur de renseigner l'ordinateur et la carte vidéo sur ses capacités) et voyons ce qu'il se passe. Cette fois, nous obtenons le maillage X et un curseur de souris mobile ce qui est tout ce à quoi nous pouvons nous attendre lorsque nous démarrons X de cette façon (nous quittons X en utilisant CTRL-ALT-Backspace comme expliqué plus haut). Cela reste (encore) dans une très basse résolution, mais cela fonctionne ce qui signifie certainement que la résolution et la fréquence de rafraîchissement posent problème. Nous restaurons "HorizSync" et "VertRefresh" à leur valeur précédente car nous avons vérifié les spécifications de ce moniteur en recherchant sur Internet.

Essayons de forcer Xorg à une résolution spécifique et voyons si nous avons de la chance. Dans la partie Section "Screen" du fichier xorg.conf, nous ajouterons deux lignes. Celles-ci sont montrées en gras :

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        DefaultDepth   24
        SubSection "Display"
                Viewport   0 0
                Depth     1
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     4
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     8
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     15
        EndSubSection
        SubSection "Display"
                Viewport   0 0 
                Depth     16
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes	"1280x1024"
        EndSubSection
EndSection
Ces deux changements indiquent que nous souhaitons faire tourner X à une profondeur d'affichage de 24 bit et, pour cette profondeur, bénéficier d'une résolution de 1280x1024. Puisqu'aucune autre résolution n'est précisée pour le mode "Depth 24", le système sera forcé de l'utiliser.

Nous testons nos changements et... SUCCÈS ! Nous obtenons ce qui semble être un très bel affichage en haute résolution. Notez bien que TOUT ce à quoi vous devez vous attendre est un maillage X (appelé "rootweave", il est parfait pour voir la qualité de votre moniteur et pour calibrer les écrans LCD) et un curseur mobile. À ce point, rien ne se doit d'être fonctionnel.

À présent, installons ce fichier xorg.conf afin de voir comment cela fonctionne avec un X fonctionnel qui tourne.

# cp xorg.conf.new /etc/X11/xorg.conf
Nous pouvons maintenant utiliser la commande normale startx(1). Ca marche !

Il serait probablement bon de vérifier que nous sommes bien à la résolution et à la profondeur que nous désirons et que nous tournons à une fréquence de rafraîchissement correcte. Nous pouvons le vérifier avec les commandes xrandr(1) et xdpyinfo(1). Entre autres, xdpyinfo(1) nous dit :

    [...]
screen #0:
  print screen:    no
  dimensions:    1280x1024 pixels (433x347 millimeters)
  resolution:    75x75 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0x44
  depth of root window:    24 planes
    [...]
Donc oui, nous tournons bien à 1280x1024 avec une profondeur de 24 planes (bits).

xrandr(4) nous dit :

 SZ:    Pixels          Physical       Refresh
*0   1280 x 1024   ( 433mm x 347mm )  *85   75   60  
 1   1280 x 960    ( 433mm x 347mm )   85   60  
    [...]
ce qui signifie que nous tournons avec une fréquence de rafraîchissement de 85Hz, ce qui devrait être confortable pour la plupart des utilisateurs.

11.3.3 - Et si ce n'est pas si "facile" ?

Parfois, les choses ne vont pas de soi. Voici quelques conseils.

11.4 - Démarrer X

Il existe deux méthodes génériques pour démarrer X :

11.4.1 - À la demande :

Identifiez-vous sous une console en tant qu'utilisateur puis lancez startx(1).

11.4.2 - Démarrer directement sous X :

Cela se fait en utilisant le gestionnaire de connexion graphique ("X Display Manager") xdm(1). Normalement, xdm(1) est démarré en tant que root par rc et présente un invité d'identification. En cas d'identification correcte, il démarre une session X pour cet utilisateur. Si, ou lorsque cette session X doit se terminer (cela inclut l'enchaînement CTRL-ALT-Backspace), xdm(1) réapparaîtra avec son invité d'identification. C'est pour cette raison que vous ne devez PAS démarrer xdm(1) à partir du fichier /etc/rc.conf.local avant d'être certain d'avoir vérifié que X fonctionne comme vous le souhaitez sinon votre machine risque de devenir difficile à gérer ! (dans le pire des cas : démarrez en mode "single user" comme si vous aviez perdu votre mot de passe et commentez la ligne xdm_flags de votre fichier /etc/rc.conf.local).

Sur certaines plates-formes, vous aurez besoin de désactiver la console getty(8) pour utiliser xdm(1).

11.5 - Personnaliser X

11.5.1 - Introduction

L'environnement X par défaut de OpenBSD est complètement fonctionnel, mais vous désirez peut-être le personnaliser. Vous pouvez avoir envie de changer l'image ou la couleur du fond d'écran, ou vous pouvez avoir envie de changer de Gestionnaire de Fenêtres (le programme qui définit le plus votre environnement X) ou changer les applications qui sont démarrées quand X démarre.

Le gestionnaire de fenêtres par défaut dans OpenBSD est fvwm(1). Fvwm est un bon gestionnaire de fenêtres généraliste, mais c'est difficilement votre seul choix; ce n'est même pas le seul gestionnaire de fenêtres fournit avec OpenBSD (voir cwm(1) et twm(1)). Un grand nombre de gestionnaires de fenêtres est également disponibles via les paquetages.

De manière similaire au script de démarrage système, X possède un processus qu'il exécute pour mettre en place l'environnement de l'utilisateur. Plus concrètement, il possède plus d'un processus qui sont utilisés en fonction de la façon dont vous démarrez X. La compréhension de la façon dont X démarre vous aidera à comprendre comment personnaliser votre environnement de travail comme vous le désirez.

Il faut remarquer que vous pouvez personnaliser l'environnement pour tous les utilisateurs ou par utilisateur. Il est préférable de faire des changements au niveau utilisateur plutôt que de changer les options du système par défaut, comme les scripts utilisateurs sont stockés dans le répertoire home de l'utilisateur, vous aurez moins de fichiers à fusionner quand vous mettrez à jour votre nouvelle version d'OpenBSD. Les options par défaut générales du système se trouvent dans /etc/X11 et sont chargées initialement de xetcXX.tgz, qui n'est pas rechargé par une procédure de mise à jour suggérée, donc si vous faites des changements sur le système général, ils persisteront, mais vous devrez fusionner ces changements dans les nouvelles versions de ces fichiers.

11.5.2 - Démarrage de startx(1)

startx(1) recherche le fichier .xinitrc dans le répertoire home de l'utilisateur. .xinitrc est habituellement un script shell qui peut démarrer autant de programme "client" X (applications qui utilisent X) que désiré. Quand le script se termine, le serveur X s'arrête aussi. Généralement, la plupart des programmes exécutés par ce script doivent être exécutés en tache de fond, mais le dernier doit fonctionner en avant-plan (typiquement le gestionnaire de fenêtres); quand il se termine, le script se terminera et X s'arrêtera.

Dans le cas le plus simple, cela peut être aussi petit que le nom du gestionnaire de fenêtres que vous invoquez :

cwm
Ou vous pouvez y mettre un peu plus de fantaisie :
xconsole -geometry -0+0 -fn 5x7 &
oclock -geometry 75x75-0-0 &
xsetroot -solid grey &
cwm
Cela démarrera la xconsole(1) qui fournit une copie de tout le texte que le noyau peut avoir envoyé à la console (qui est maintenant couverte par l'écran graphique), une horloge analogique, oclock(1), et configurer le fond d'écran avec du gris via xsetroot(1), tout cela avant d'invoquer le gestionnaire de fenêtres cwm(1). Remarquez que seulement le gestionnaire de fenêtres n'est pas "mis en tache de fond" avec un caractère "&". Cela signifie que X restera exécuté jusqu'à ce que cwm(1) se termine.

Si le répertoire home de l'utilisateur ne possède pas de fichier .xinitrc, le fichier système /etc/X11/xinit/xinitrc est utilisé. Ce fichier peut vous fournir d'autres idées pour votre script .xinitrc.

11.5.3 - Démarrage de xdm(1)

xdm(1) est habituellement démarré par les scripts de démarrage système, mais pour des raisons de test (recommandé tant que vous n'avez pas votre config X correct !), il peut être exécuté sous root.

xdm(1) possède beaucoup d'autres fonctionnalités dont nous ne parlerons pas ici, mais pour nos besoins, xdm affichera l'utilisateur avec un écran de connexion, récupérera et vérifiera le nom de l'utilisateur et le mot de passe, et fournira à l'utilisateur son environnement X. Quand X s'arrête, de façon délibérée ou accidentelle, xdm le redémarrera de lui-même. C'est pour cette raison que vous devez configurer correctement X avant d'utiliser xdm(1) et avant d'avoir xdm(1) démarrer automatiquement au démarrage de la machine, autrement, vous aurez des difficultés à prendre le contrôle de la machine.

Quand xdm(1) démarre, il exécute /etc/X11/xdm/Xsession, qui vérifiera si l'utilisateur possède un fichier .xsession dans son répertoire home. Mais, si vous désirez changer votre gestionnaire de fenêtres par défaut, invoquez-le simplement (et peut-être d'autres choses) dans .xsession. Encore un fois, tous les programmes que vous désirez démarrer avec X (par exemple, peut-être que trois xterm(1)s peuvent être placés ici, mais ils doivent tous être en tache de fond excepté votre gestionnaire de fenêtre, qui encore une fois, quand il se terminera, terminera votre session X. Dans ce cas, xdm(1) redémarrera X et retournera à l'écran de connexion.

11.5.4 - Essayer un nouveau gestionnaire de fenêtre

Vous pouvez invoquer un gestionnaire de fenêtre particulier quand vous démarrer X sans altérer les paramètres par défaut comme ceci :
$ startx /usr/local/bin/fluxbox
Plusieurs gestionnaires de fenêtres (incluant cwm(1) et fvwm(1)) offrent la possibilité de changer de gestionnaire de fenêtres à la volée, sans redémarrer X ou vos applications. Votre nouveau gestionnaire de fenêtres remplace le précédent; quitter le nouveau gestionnaire de fenêtres terminera X, il ne retournera pas à votre précédent gestionnaire de fenêtres. fvwm(1) vous permet de démarrer un gestionnaire de fenêtres différent en cliquant à gauche sur le fond d'écran ("root window"), choisir "(Re)Start", puis sélectionner votre gestionnaire de fenêtre préféré (cependant, il faut remarquer que vous devez ajouter votre gestionnaire de fenêtres alternatif à votre fichier .fvwmrc (celui par défaut pour le système est /usr/X11R6/lib/X11/fvwm/.fvwmrc)). cwm(1) vous permet d'invoquer un autre gestionnaire de fenêtre en tapant Ctrl-Alt-w puis en sélectionnant le gestionnaire dans lequel vous voulez aller.

Dès que vous avez trouvé un gestionnaire de fenêtre que vous aimez, vous pouvez le configurer comme le programme final exécuté par vos scripts de démarrage comme décrit ci-dessus.

[Index de La FAQ] [Section 10 - Gestion du Système] [Section 12 - Questions Spécifiques Aux Plates-Formes Et Au Matériel]


[back] www@openbsd.org
$OpenBSD: faq11.html,v 1.61 2013/11/01 18:04:04 ajacoutot Exp $