mai 2009 Archives

11-05-2009 22:24:39

X.Org 1.6.1 / hal / KDE 4.2 / TwinView

Dans mon précédent billet sur la migration KDE 4.2, j'ai présenté un tableau sans doute trop optimiste de la situation. Voici donc un nouveau billet sur mes déboires récentes avec mon transportable M6300 !

Le contexte

Voilà de nombreuses années que j'ai pris l'habitude d'utiliser une configuration d'interface graphique à «double tête» : un écran pour les manipulations personnelles et un écran de vidéo-projection à destination des étudiants. De cette façon, il est possible de consulter des notes différentes des vues projetées lors d'un cours ou de préparer une configuration sur un équipement pendant que les étudiants traitent une série de questions lors d'une séance de travaux pratiques.

Du point de vue du gestionnaire graphique X.Org, cette configuration à «double tête» était basée sur l'extension Xinerama. Cette extension permet de disposer de deux écrans de configuration indépendante. Avec les version KDE 3.5.x, le gestionnaire de bureau est aussi indépendant : fond d'écran, icônes, raccourcis, etc. Depuis le passage à X.Org 1.6.1 et KDE 4.2, tout çà ne fonctionne plus du tout. L'interface X.Org redémarre de façon aléatoire et certaines touches du clavier bloquent l'interface graphique. Il a donc fallu reprendre la configuration à zéro.

Dans les sections suivantes, on trouve une description point par point des choix retenus pour revenir à un fonctionnement nominal.

Les périphériques d'entrée clavier/souris

Avec l'arrivée des paquets de la version 1.6.1 de xorg, on passe à un mode de reconnaissance dynamique des périphériques d'entrée. Normalement, les fichiers de configuration historiques comportant les définitions de ces mêmes périphériques devraient être correctement gérés. Force est de constater que ce n'est pas toujours le cas.

Le clavier

Pour la gestion du clavier, j'ai suivi les instructions de la page XStrikeForce/InputHotplugGuide qui explique que le branchement «à chaud» est devenu le mode opératoire par défaut dans la configuration des périphériques d'entrée.

Dans le cas du clavier, c'est le paquet console-setup qui doit se charger de récupérer les paramètres. Ces paramètres sont ensuite transmis au démon hal qui sert à alimenter le serveur X.Org.

Comme indiqué dans la documentation, il faut s'assurer que console-setup détient les bonnes informations.

$ grep -C 1 -i xkb /etc/default/console-setup
# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.
XKBMODEL="pc105"
XKBLAYOUT="fr"
XKBVARIANT="latin9"
XKBOPTIONS="lv3:ralt_switch"

Les mêmes informations doivent être disponibles dans le démon hal.

$ lshal | grep xkb
  input.xkb.layout = 'fr'  (string)
  input.xkb.model = 'pc105'  (string)
  input.xkb.options = 'lv3:ralt_switch'  (string)
  input.xkb.rules = 'base'  (string)
  <snipped/>
La souris ou le touchpad tapping

Là, c'est le paquet xserver-xorg-input-synaptics pour lequel l'utilisation du «click sur tapis» ou tapping a disparu. Comme dans le cas du clavier, il s'agit d'un problème lié aux propriétés du périphérique d'entrée qui doivent être transmises via le démon hal.

Après avoir consulté plusieurs rapports de bug sur la question, j'ai choisi d'éditer le fichier /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi fourni avec le paquet xserver-xorg-input-synaptics en ajoutant les 3 lignes suivantes.

$ tail -7  /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi
        -->
        <merge key="input.x11_options.TapButton1" type="string">1</merge>
        <merge key="input.x11_options.TapButton2" type="string">2</merge>
        <merge key="input.x11_options.TapButton3" type="string">3</merge>
    </match>
  </device>
</deviceinfo>

Une fois ces deux opérations effectuées, il reste à supprimer les sections InputDevice correspondantes du fichier /etc/X11/xorg.conf ainsi que les références dans la section ServerLayout. Voir la section intitulée « Le fichier de configuration xorg.conf ».

L'extension TwinView

Cette extension est une option propriétaire du constructeur NVIDIA disponible uniquement avec les pilotes propriétaires des cartes graphiques de la marque. Au moment de la rédaction de ces lignes, c'est la version 180.51 qui est utilisée.

L'outil nvidia-settings autorise la reconfiguration dynamique de la disposition des écrans avec l'extension TwinView.

Dans le cas qui nous intéresse, on place le deuxième écran ou le vidéo projecteur à droite de l'écran du portable. Du point de vue configuration, on active l'extension TwinView dans la section de l'écran du portable et on positionne le second écran à droite en ajoutant le nombre de pixels nécessaires.

Ici, la définition graphique du portable, référencé DFP est de 1920x1200. On ajoute donc 1920 pixels à la position du second écran référencé CRT. Ce mode d'utilisation de l'extension est appelé DynamicTwinView.

Option "metamodes" " DFP: 1920x1200 +0+0, CRT: nvidia-auto-select +1920+0"

Les options de l'extension sont présentées au chapitre 13 de la documentation NVIDIA dans le fichier /usr/share/doc/NVIDIA_GLX-1.0/README.txt. Cette même documentation est aussi disponible en ligne.

Voir la section intitulée « Le fichier de configuration xorg.conf » pour avoir une vue complète du fichier de configuration. Une fois que cette configuration est activée, on obtient le résultat suivant.

Dans le cycle amour/haine entre GNU/Linux et NVIDIA, on peut regretter qu'il n'existe pas encore de pilotes de carte graphique libres à 100% qui permettent d'obtenir le même mode de fonctionnement. Le fait qu'Intel ait publié l'ensemble des spécifications de ses composants graphiques finira peut-être par contraindre les autres constructeurs à suivre la même démarche.

Les présentations

Pour utiliser correctement la configuration «double tête» avec une présentation, il faut distinguer les applications utilisées.

MagicPoint

Avec MagicPoint, il est nécessaire d'utiliser l'option -g de façon à dimensionner l'affichage dans une fenêtre qui occupe seule l'écran du vidéo projecteur. Voici un exemple utilisant une résolution d'écran de 1280 par 1024 pixels.

$ mgp -g 1280x1024 -x m17n admin.reseau.fs.mgp

Auparavant, avec l'extension Xinerama, les définitions d'écran étaient totalement indépendantes. MagicPoint occupait un écran sans qu'il soit nécessaire de préciser la résolution à employer.

Côté conception de présentation, j'ai choisi de ne plus centrer les images inclues dans les vues. J'ai aussi abandonné le redimensionnement dynamique des images en pourcentage. La principale conséquence est visible dans les versions imprimables produites à partir de l'outil mgp2ps. Les images n'occupent pas très bien l'espace de la page.

OpenOffice.org Impress

Avec OpenOffice Impress, il faut accéder à la fenêtre des paramètres du diaporama pour spécifier l'écran à utiliser.

Dans la copie d'écran ci-dessous, l'écran du portable a été utilisé pour ouvrir l'application ooimpress et le second écran est utilisé pour le diaporama projeté.

Pour conclure

Voilài ! Ce billet est là pour relativiser l'enthousiasme de la migration de l'environnement graphique KDE 4.2. Sans sombrer dans la déprime et passer à Gnome, on constate simplement que toutes les difficultés ne sont pas soldées. Les évolutions sont tellement importantes que les migrations d'une version à l'autre entraînent pas mal de désagréments. Nous avons été bien mal habitués ces dernières années en utilisant les paquets de la branche unstable jour après jour sans rencontrer la moindre difficulté.

Je serais beaucoup plus sévère sur les distributions qui proposent des versions «intermédiaires» sans assurance qualité aux utilisateurs novices. Ce n'est définitivement pas le meilleur moyen d'attirer de nouveaux utilisateurs dans le monde du logiciel libre.

Enfin, il existe une extension du projet X.Org que je n'ai pas pris le temps d'évaluer : XRandR qui doit permettre d'obtenir les mêmes résultats avec des cartes graphiques d'autres marques ; Intel notamment. Si j'ai l'occasion de tester un netbook un jour, il faudra l'envisager sérieusement. Pour l'instant, je reste fidèle au transportable M6300 sur lequel on peut «faire tourner» une petite collection d'instances virtuelles de systèmes (et|ou) de routeurs.

Ce document est disponible en version imprimable au format PDF : xorg-hal-twinview.pdf.

$Id: xorg-hal-twinview.xml 1390 2009-05-11 20:24:10Z latu $

Le fichier de configuration xorg.conf

Le fichier ci-dessous est assez «léger» relativement à ce que l'on a connu dans le passé ! Toutes les sections InputDevice ont été supprimées. L'extension Xinerama a été désactivée globalement et l'extension TwinView a été activée dans la définition des paramètres de l'écran ; c'est à dire la section Screen.

Section "ServerLayout"
        Identifier     "Default Layout"
        Screen      0  "NVIDIA Quadro FX 1600M" 0 0
EndSection

Section "ServerFlags"
        Option         "Xinerama" "0"
EndSection

Section "Files"
        RgbPath         "/usr/lib/X11/rgb"
EndSection

Section "Module"
        Load           "dbe"
        Load           "extmod"
        Load           "glx"
EndSection

Section "Monitor"
        Identifier      "Laptop"
        ModelName       "Seiko"
        Option          "DPMS"
EndSection

Section "Device"
        Screen          0
        Identifier      "NVIDIA Quadro FX 1600M"
        Driver          "nvidia"
        VendorName      "NVIDIA Corporation"
        BusID           "PCI:1:0:0"
        Option          "Coolbits"              "1"
EndSection

Section "Screen"
        Identifier      "NVIDIA Quadro FX 1600M"
        Device          "NVIDIA Quadro FX 1600M"
        Monitor         "Laptop"
        DefaultDepth    24
        Option          "TwinView" "1"
        Option          "TwinViewXineramaInfoOrder" "DFP-0"
        Option          "TwinviewXineramaInfo"  "True"
        Option          "metamodes" " DFP: 1920x1200 +0+0, CRT: nvidia-auto-select +1920+0"
        SubSection "Display"
                Depth   24
        EndSubSection
EndSection