12-Les passages à Xorg 1.5 puis Xorg 1.6 plantent clavier et souris !

Octobre 2009, suite à une mise à jour (update) j'installe la version 1.6 de Xorg. Je relance le serveur X (startx) et sous mon environnement fluxbox j'ai mon fond d'écran mais je n'ai ni accès au clavier ni au touchpad. Commence une longue quête ... car bien sûr ce que j'avais trouvé pour la version 1.5 (c.a.d neutraliser l'utilisation des fichiers .fdi par l'ajout de la ligne suivante :

Section "ServerFlags"
    Option    "AutoAddDevices"    "false"
EndSection

dans /etc/X11/xorg.conf) ne marche plus.
Et pour cause, il semblerait que Xorg 1.6 ne permet plus le choix de configuration soit par xorg.conf ou soit par fichiers .fdi. Seuls ces derniers sont utilisés. Donc « y a pas », il va falloir y passer.

12.1 - Toujours penser à jeter un oeil sur les log

Certes lors de l'installation, on voit les warning, mais lorsqu'on installe plusieurs logiciels, on peut perdre de vue ce qui a été écrit, d'où l'intérêt d'aller voir le log de portage. Voilà ce qu'il indiquait pour Xorg 1.6 :

# vi /var/log/portage/elog/summary.log
......
>>> Messages generated by process 6241 on 2009-10-18 23:44:19 CEST for package x11-base/xorg-server-1.6.3.901-r2:
WARN: postinst
Users of reduced blanking now need:
   Option "ReducedBlanking"
In the relevant Monitor section(s).
Make sure your reduced blanking modelines are safe!
You must rebuild all drivers if upgrading from xorg-server 1.5
or earlier, because the ABI changed. If you cannot start X because
of module version mismatch errors, this is your problem.
You can generate a list of all installed packages in the x11-drivers
category using this command:
emerge portage-utils; qlist -I -C x11-drivers/

12.2 - Mettre à jour Xorg-server (upgrade)

Donc avant toute chose, il faut mettre à jour proprement Xorg, hal et evdev comme indiqué aux 2 pages suivantes (en anglais) à lire dans cet ordre :

http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml

http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml

Voici, ce qui est dit :

Lors de la mise à jour de Xorg-server, il nous faudra très probablement mettre à jour libxcb également. La mise à niveau de cette bibliothèque n'est pas aussi simple qu'il peut sembler. Cependant, libxcb a son propre guide de mise à niveau. (le premier lien supra)

Avertissement : Il nous faut suivre le guide de mise à niveau de libxcb avant de mettre à jour xorg-server, sinon on risque de casser notre système.

Donc allons-y pour passer à libxcd 1.4

# emerge -1av x11-proto/xcb-proto x11-libs/libxcb
# emerge -1av x11-proto/xproto x11-proto/xextproto x11-libs/libX11 x11-libs/libXext

Nous avez maintenant tous les paquets nécessaires avec les supports du nouveau libxcb.

Je vous fais grâce de tout le texte sur l'ancienne bibliothèque (libxcb-xlib.so) qui pollue presque tous les fichiers .la.  En résumé il nous faut supprimer les références à l'ancienne bibliothèque dans tous les fichiers .la, pour cela :

# /usr/portage/x11-libs/libxcb/files/xcb-rebuilder.sh

Si aucun paquet cassé n'est signalé, c'est tout bon, le système est prêt à fonctionner. Si tel n'est pas le cas, il nous faut absolument faire ce qui suit.

Pour éviter de complètement casser le système utilisateur, nous avons décidé de garder libxcb-xlib.so pour que vous ayez la possibilité de fixer votre système à votre propre rythme. Si vous avez suivi les susdites instructions, votre système devrait travailler maintenant correctement.

Mais avant que vous puissiez enlever libxcb-xlib.so, vous devrez reconstruire quelques paquets. Si vous ne les reconstruisez pas, en enlevant la vieille bibliothèque vous casserez votre système.

Lancer la commande suivante pour reconstruire le sous-ensemble de paquets potentiellement cassés. Ne vous inquiétez pas, les paquets que vous n'avez pas installés ne seront pas installés.

# emerge --oneshot \
$(for i in x11-proto/ x11-libs/libxcb x11-libs/libX11 x11-libs/libXext \
           x11-libs/libX x11-libs/xcb-util x11-libs/cairo \
           x11-libs/pango x11-libs/gtk\\+ \
           x11-libs/qt-gui; do \
    qlist -IC $i; \
done) -av

Dès que c'est fait, vous pouvez utiliser revdep-rebuild (d' app-portage/gentoolkit) pour finir de fixer le reste de votre système.

# revdep-rebuild -L libxcb-xlib.so.0

Quand revdep-rebuild ne signale plus de paquets cassés, vous pouvez enlever en toute tranquillité libxcb-xlib.so.0 de votre dossier de bibliothèques.

# rm -i /usr/lib/libxcb-xlib.so*

Maintenant on peut passer à la lecture du guide de mise à jour de Xorg server qui ne donne pas grand chose finalement :

Xorg ignore maintenant le Ctrl-Alt-Backspace par défaut. Si vous voulez remettre cette possibilité de terminer la session X, il y a plusieurs possibilités :

• en ligne de commande et de manière ponctuelle :
  

  $ setxkbmap -option terminate:ctrl_alt_bksp

• Et pour rendre le changement permanent, vous avez 2 options :

1. Si vous utilisez HAL pour gérer vos dispositifs d'entrée, copier ce bout de fichier fdi suivant dans le fichier fdi que vous utilisez pour contrôler votre clavier et qui se trouve sous /etc/hal/fdi/policy/.
   

   <merge key="input.xkb.options" type="string">terminate:ctrl_alt_bksp</merge>

   Si vous n'avez pas de règles de clavier personnalisées, vous pouvez copier et adapter des règles de /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi
2. Si vous utilisez encore xorg.conf pour diriger vos dispositifs d'entrée, ajoutez juste la ligne suivante à la section InputDevice de votre clavier : Option "XkbOptions" "terminate:ctrl_alt_bksp".
   Nota : cette dernière ligne laisse supposer que l'on peut encore utiliser xorg.conf avec Xorg 1.6, mais ce n'est pas le cas (ou je n'ai pas trouvé)

12.3 - Configurer Xorg

Une fois que j'avais fait tout ce qui précède, je me suis retrouvé avec un clavier anglais (qui de plus ne reconnaissait pas la touche « flèche Haut ») et une souris (touchpad) erratique car trop sensible. Après quelques tâtonnements, j'ai opté pour :

• un copier/coller du fichier /usr/share/hal/fdi/policy/10osvendor/11-x11-synaptics.fdi sous /etc/hal/fdi/policy/. Ce qui me stabilise la souris (touchpad), sans cependant me donner le tap = clic. Mais ce dernier point devrait se régler après la (longue) lecture du man synaptics. Pour l'instant mon fichier 11-x11-synaptics.fdi se résume à cela :

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.touchpad">
        <merge key="input.x11_driver" type="string">synaptics</merge>
    </match>
  </device>
</deviceinfo>

• et un copier/coller du fichier /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi sous /etc/hal/fdi/policy/. Ce qui me permet de séparer les fichiers de configuration souris et clavier, et pour ce dernier de mettre le « layout » à « fr ». Nous avons ceci (la dernière ligne merge a été ajoutée au fichier original) :

 <?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keymap">
      <append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
    </match>

    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.rules" type="string">base</merge>

      <!-- If we're using Linux, we use evdev by default (falling back to
           keyboard otherwise). -->
      <merge key="input.xkb.model" type="string">keyboard</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.xkb.model" type="string">evdev</merge>
      </match>

      <merge key="input.xkb.layout" type="string">fr</merge>
      <merge key="input.xkb.variant" type="string" />
      <merge key="input.xkb.options" type="string">terminate:ctrl_alt_bksp</merge>
    </match>
  </device>
</deviceinfo>

A partir de là, mon clavier fonctionne à peu près correctement (je n'ai toujours pas ma « flèche Haut »), mon touchpad également (mais je n'ai pas le tap=clic) et bien évidemment mes 4 boutons spéciaux de mon Evo N600c ne fonctionnent pas.

12.4 - Pour aller plus loin, comprendre !

Il faut bien reconnaître que si xorg.conf n'était pas très lisible, ce n'est rien en comparaison des fichiers .fdi qui sont carrément incompréhensibles au premier abord avec son écriture XML/SGML et ses clés « /org/freedesktop/Hal/devices/computer:system... » qu'on se demande d'où elles sortent.

Alors essayons de comprendre.

D'abord HAL pour Hardware Abstraction Layer.
Pour les différentes releases, notamment pour Hal-Info qui est un package à part, voir http://hal.freedesktop.org/releases/

Pour trouver de l'info, vous avez :

• la classique man page # man hald
• et l'Internet avec http://www.freedesktop.org/wiki/Software/hal
  

Une autre page, toujours en anglais, explique un peu mieux ce que fait HAL même si l'environnement système est une RedHat.
Traditionnellement, les applications de bureau découvrent le matériel en parlant directement au noyau (kernel) du système d'exploitation (le noyau maintient la liste des appareils attachés au système). C'est un processus ennuyeux et qui n'est pas exact parce que quelquefois le kernel ne sait pas tout d'un appareil. Par exemple, certains appareils photo numériques et baladeurs apparaissent juste comme un autre disque dur dans l'interface d'utilisateur. Ainsi, peu d'interfaces d'utilisateur ont été construits pour la découverte du matériel.

Avec HAL, tous les renseignements intéressants sur  certaines classes de matériel sont facilement accessibles dans un format bien défini. Quand un nouvel appareil est ajouté au système, un signal asynchrone est diffusé sur le bus de message  (D-Bus) du système détaillant le type  d'appareil  ajouté. N'importe quelle application de bureau peut communiquer facilement au bus de message pour découvrir le matériel. En plus, les scripts de niveau du système peuvent être dirigés pour configurer l'appareil.

Intérieurement, le démon de HAL maintient une liste d'objets d'appareil qui contient des paires de clé/valeur bien définies décrivant ce que l'objet représente. Chaque objet d'appareil est identifié par un Identificateur d'Appareil Unique (UDI), qui est unique à travers tous les objets d'appareil. Les paires de clé/valeur, appelées propriétés d'appareil, sont tapées et sont définies dans la spécification de HAL, donc les utilisateurs de HAL savent quelle valeur peut prendre chaque propriété.

Les Device Information File (extendion .fdi), sont un des traits les plus puissants de HAL — ils permettent à HAL d'ajouter ou de régler des propriétés d'un appareil.
La commande lshal retourne tous les objets d'appareils dont hald a connaissance comme ici.

On obtient une (très) longue liste, dans laquelle on retrouve des noms de clefs qui nous interpellaient comme  "/org/freedesktop/Hal/devices/computer:system.kernel.name". Au passage on découvre une clef « input.keymap.data » qui va me permettre de réactiver mes boutons spéciaux.

Donc en résumé le démon HAL, entretient une liste à jour de tous les appareils (et autres périphériques) en cherchant les infos dans le noyau et/ou dans les fichiers .fdi.

Mais evdev dans cette histoire, qu'est-ce que c'est ?

Ben je ne sais pas trop. A priori, il est considéré comme un driver pour les composants d'entrée : clavier, souris, touchpad. Et c'est lui qui communique ce qu'il a trouvé à HAL. Donc contrairement à ce que je disais précédemment, HAL a 2 sources d'infos : le kernel et evdev.

La documentation là dessus est rare.

12.5 - Configuration définitive

Voici, in fine ce que j'ai fait (c'est une copie de ma réponse sur le forum Gentoo) :

Bon, une hospitalisation plus tard (mais pas à cause de cela je vous rassure ;-), une mise à profit de mon invalidité provisoire, et une "googlisation" excessive, voilà ce que j'ai trouvé pour que cela fonctionne (au moins chez moi):

• En réponse à limax, j'ai bien xf86-input-synaptics d'installé ainsi que xf86-input-keyboard et xf86-input-mouse qui ont du venir je pense avec l'installation d'evdev -indispensable. Pour le vérifier lancer:

  # equery -i list xf86-input

• hal & Dbus sont bien sûr en place et lancés au démarrage. Pour le vérifier lancer :

  # rc-status | grep -E "hal|dbus 

  si tel n'est pas le cas il faut les y mettre. Pour cela lancer :

  # rc-update add hald default

• la commande :

  #for x in $(hal-find-by-capability --capability input.keys);do lshal -u $x;done    

  me renvoie :

  udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input'
    info.addons.singleton = {'hald-addon-input'} (string list)
    info.callouts.add = {'hal-setup-keymap'} (string list)
    info.capabilities = {'input', 'input.keyboard', 'input.keypad', 'input.keys', 'input.keymap', 'button'} (string list)
    info.category = 'input'  (string)
    info.parent = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port'  (string)
    info.product = 'AT Translated Set 2 keyboard'  (string)
    info.subsystem = 'input'  (string)
    info.udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input'  (string)
    input.device = '/dev/input/event3'  (string)
    input.keymap.data = {'e023:www', 'e01a:search', 'e01e:email', 'e01f:homepage', 'e01e:mail'} (string list)
    input.originating_device = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port'  (string)
    input.product = 'AT Translated Set 2 keyboard'  (string)
    input.x11_driver = 'evdev'  (string)
    input.xkb.layout = 'fr'  (string)
    input.xkb.model = 'evdev'  (string)
    input.xkb.rules = 'base'  (string)
    input.xkb.variant = ''  (string)
    linux.device_file = '/dev/input/event3'  (string)
    linux.hotplug_type = 2  (0x2)  (int)
    linux.subsystem = 'input'  (string)
    linux.sysfs_path = '/sys/class/input/input3/event3'  (string)
  

  Donc le clavier détecté (par evdev ?) est un 'AT Translated Set 2 keyboard' et mes touches multimédias sont elles aussi bien détectées : input.keymap.data = {'e023:www', 'e01a:search', 'e01e:email', 'e01f:homepage', 'e01e:mail'}. Et à ce stade je n'ai pas, sous /etc/hal/fdi/policy/ le fichier 30-keymap-compaq.fdi qui permet normalement la reconnaissance des touches multimédia. 

• J'avais xev d'installé, cela me permet, sous X, de voir le keycode (associé au scancode que renvoie le clavier) et le keysym de chaque touche (nom associé; par ailleurs l'ensemble des noms possibles se trouvent sous /usr/share/X11/XKeysymDB, le path est peut-être différent pour vous, faites alors une recherche par le nom du fichier ). Ainsi xev lancé, un appui sur la touche 'flèche haut' me donne un keycode de 111 et un keysym Up.
• C'est là que je me souviens que j'avais associé des actions à certaines touches (touche Window, Fn+imp écr et mes touches multimédias). Sous fluxbox cela se fait dans le fichier .fluxbox/keys (voici la page que j'avais utilisée à l'époque -il y a 2 ans, mais elle est toujours intéressante : http://www.lea-linux.org/documentations/index.php/Hardware-hard_autres-clavier_multimedia ). J'avais entre autre, dans mon fichier keys :

   

  # Action de la touche Fn+imp écr
  none 111 :ExecCommand (scrot '%Y-%m-%d_%T.jpg' -e 'mv $f ~/Screenshots/')

  Et voilà mes premières erreurs détectées. Le fait de passer du model "presario" tel que paramétré dans mon xorg.conf en un "AT translated ..." a modifié les keycode. Il en est ainsi pour ma flèche haut, ma Fn+Imp Ecr, et mes touches multimédia.
  Du coup je modifie mon fichier .fluxbox/key, en associant les actions non plus aux keycode mais aux keysym, donc aux noms associés. Cela donne :

  # Action de la touche Fn+imp écr
  Print :ExecCommand (scrot '%Y-%m-%d_%T.jpg' -e 'mv $f ~/Screenshots/')
  # Actions de la touche Windows
  Super_L :RootMenu
  Control Super_L :HideMenus
  # Action des touches multimédias
  XF86WWW :ExecCommand firefox
  XF86Mail :ExecCommand thunderbird
  XF86HomePage :ExecCommand Eterm
  XF86Search :ExecCommand rox

  On relance le tout (hald et X) et cela ... marche ... sauf pour thunderbird :-(. Pourtant xev me renvoie bien XF86Mail. Mais j'essaie quand même email, Email, EMail, EMAIL, précédé ou non de XF86, mais rien n'y fait.
  Du coup, je rajoute une ligne à mon fichier 10-X11-input.fdi, qui associe e01e (scancode) à 'mail' et non à 'email', comme ceci :

  <?xml version="1.0" encoding="ISO-8859-1"?>
  <deviceinfo version="0.2">
    <device>
      <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.layout" type="string">fr</merge>
      </match>
      <!-- J'ai ajouté cette ligne car le détection automatique avec 'email' est fausse -->
      <match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" contains_outof="E500;Evo N610c;Evo N600c">
      <append key="input.keymap.data" type="strlist">e01e:mail</append>    <!-- XF86Mail key -->
      </match>
    </device>
  </deviceinfo>

  Et là cela marche ! :-))

• Reste mon paramétrage du touchpad, là je me doutais bien que la résolution passerait par une bonne mise au point des paramètres. Mais cette recherche m'a montré que la moindre erreur dans le fichier .fdi (un </merge-> par exemple - un tiret oublié suite à la suppression de la mise en commentaire) donne une interprétation plus qu'aléatoire du fichier. Pour ce qui me concerne, voici ce que j'ai dans mon fichier 11-synaptics.fdi (les lignes encadrées par <!-- abcdef --> sont des commentaires) :

  <?xml version="1.0" encoding="ISO-8859-1"?>
  <deviceinfo version="0.2">
    <device>
      <match key="info.capabilities" contains="input.touchpad">
          <merge key="input.x11_driver" type="string">synaptics</merge>
          <!--merge key="input.x11_options.Emulate3Buttons" type="string">yes</merge -->
  <!-- Tapping : rappel 1 = bouton Gauche, 3 = bouton Droit, 2 = bouton Molette,
       et TapButtonX = X doigts -->
      <merge key="input.x11_options.TapButton1" type="string">1</merge>
          <merge key="input.x11_options.TapButton2" type="string">3</merge>
          <!--merge key="input.x11_options.TapButton3" type="string">2</merge-->
      <!-- Maximum movement of the finger for detecting a tap -->
      <merge key="input.x11_options.MaxTapMove" type="string">2000</merge>
      <!-- Switch on shared memory, enables the driver to be configured at runtime, for version < 1.0 -->
      <!--merge key="input.x11_options.SHMConfig" type="string">true</merge-->
  <!-- Permet avec 1 doigt glissé sur le bord droit le défilement Vertical
       et sur le bord bas le défilement horizontal -->
      <merge key="input.x11_options.VertEdgeScroll" type="string">true</merge>
      <merge key="input.x11_options.HorizEdgeScroll" type="string">true</merge>
  <!-- Permet avec 2 doigts le défilement horizontal et vertical n'importe où sur le touchpad -->
      <merge key="input.x11_options.VertTwoFingerScroll" type="string">true</merge>
      <merge key="input.x11_options.HorizTwoFingerScroll" type="string">true</merge>
  <!-- For other possible options, check CONFIGURATION DETAILS in synaptics man page -->
      </match>
    </device>
  </deviceinfo>

  Et il marche comme je veux! :-))

Voilà, je n'ai toujours pas bien compris comment fonctionnaient Hal - evdev, la différence entre append et merge, pourquoi dans les fichiers fdi on "s'amuse" à mettre des lignes <match> (à part la portabilité des fichiers, mais sur une machine donnée on doit savoir ce que l'on a, non ?), mais cela marche chez moi.

12.6 - Quelques autres considérations

Quelques ressources supplémentaires :

• Installation du serveur X par Gentoo Quebec, la seule source d'une vague explication sur les rôles de Hal et de udev.
• Une autre basée sur Ubuntu, mais on y parle de la commande xinput, et donne l'usage de match et append (mais pas de merge !)