mai 2009 Archives
11-05-2009 22:24:39
Posté par Philippe Latu | permalien | dans : Enseignement, Debian, M6300 | | | Read it in english with Google
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 !
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.
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-setupqui doit se charger de récupérer les paramètres. Ces paramètres sont ensuite transmis au démonhalqui sert à alimenter le serveur X.Org.Comme indiqué dans la documentation, il faut s'assurer que
console-setupdé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-synapticspour 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émonhal.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.fdifourni avec le paquetxserver-xorg-input-synapticsen 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 ».
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.
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
-gde 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é.
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 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





