Le clavier Happy Hacking Lite 2

Je rédige actuellement cet article avec ma dernière acquisition, le Happy Hacking Keyboard Lite2, une petite merveille de clavier pour la frappe rapide, très apprecié des programmeurs notamment. J'avais lu un article dans Planète Linux No 8 (Août 2000), et j'avoue qu'il m'avait tapé dans l'oeil... Mais à l'époque, ma trop petite expérience de Linux, le prix et le fait de devoir le commander à l'étranger m'avaient dissuadé...

Cette année, la société PFU, filiale de Fujitsu, a sorti le modèle Lite2, avec connexion PS/2, et les touches fléchées en bas à droite, suite aux demandes des premiers utilisateurs de ce "frappodrome" peu commun. J'ai donc fini par craquer, et je l'ai commandé la semaine dernière, pensant le recevoir au bout de 5 à 10 jours. En fait, je l'ai reçu deux jours plus tard seulement, grâce à FEDEX, qui vous livre avant que vous n'ayez le temps de dire : " Vive Linux, à bas Windows ! ". Sérieusement, même les Actualis et autres e-stores, pourtant situés à Paris ou Lyon, ne font pas mieux. Le colis est super-léger, je me demande même s'il y a quelque chose dedans ! Je sort la bête de son emballage : superbe ! Trop petit ! Trop bien ! Quel gain de place !

Je savais qu'il allait falloir le configurer, avec peu de doc à l'appui. D'ailleurs pour la présentation du clavier Happy Hacking, voir Planète Linux no 8, ici où bien là...

Je ne m'attacherai dans cet article qu'à apporter de nouvelles infos concernant sa configuration sous Linux Mandrake 8.0, car le problème, c'est que nous avons à faire à une version HHK Lite2, avec des valeurs de keycodes différentes de celles données par nos amis rédacteurs des précédents articles sur le Happy Hacking Keyboard. En effet, je n'ai pas immédiatement réussi à saisir les lettres accentuées, et je dirais même que j'ai galéré quelques heures.

Je vais donc ici résumer les manips' à réaliser pour bien le configurer le Happy Hacking Lite2, sous Linux Mandrake 8.0.

Mode console (pas d'interface graphique)

La manip est relativement simple. Téléchargez le petit fichier hhkl.map.gz, donnant la carte clavier du HHKL, comme le préconise le premier article de Planète Linux, mais attention au répertoire de destination, qui n'est pas le même que celui indiqué alors (/usr/share...) ! Pour une Mandrake 8.0, nous allons le placer dans le répertoire /usr/lib/kbd/keymaps/i386/qwerty.

On se connecte en mode console "pur" (Crtl+Alt+F1 par exemple, ou /sbin/init 3), et on saisit : loadkeys hhkl. Normalement, la carte est chargée en QWERTY, et pour saisir un "é", on fait : touche diamant de droite, puis apostrophe " ' ", puis "e". Pour un " ô ", touche diamant, puis Shift+6 pour attraper le " ^ ", puis " o ". C'est vrai que c'est déroutant les premières fois, mais on s'y fait vite pour peu qu'on pratique un minimum. Pour éviter d'avoir à taper cette commande à chaque fois, on l'insère dans le fichier script rc.local du dossier /etc/rc.d, à l'aide d'un éditeur quelconque, et on enregistre. La carte QWERTY devrait être chargée à chaque démarrage, pour le mode console " pur ".

Sous KDE

La carte du clavier peut être définie graphiquement avec le KDE Control Center.. pourquoi s'en priver ? Il suffit de sélectionner le clavier générique PC101, en langue US, et de le mettre par défaut. Comme tout clavier américain, le HHK n'a pas de touches accentuée comme "é" "à", etc... Il faut donc redéfinir quelques codes pour pouvoir y accéder. Mais avant, un petit échauffement. Nous allons voir les notions de base nécessaires pour bien tout comprendre.

Primo, si la carte clavier a été chargée graphiquement, le fichier /etc/X11/XF86Config (ou XF86Config-4 selon la version de Xfree) doit au moins contenir des lignes dans ce style :

Option " XkbRules " "xfree86"

Option " XkbModel " "pc101" ! pas de pc104 ou 105 !

Option " XkbLayout " "us" ! pour avoir la config QWERTY !

Le cas échéant, reprendre tout ça en éditant le fichier à la main...

Secundo, on ouvre un terminal, et on tape la commande : xmodmap -pke afin d'avoir la liste des keycodes, correspondant à chaque touche. C'est ainsi qu'est définie la carte clavier. On note que certains keycodes sont vides, associés à rien du tout. Chaque pression de touche envoie un code au système, qui l'identifie et affiche le caractère associé. On peut enregistrer cette carte dans un fichier caché .Xmodmap avec la commande : xmodmap -pke > ./Xmodmap ( ou bien xmodmap -pke > ~/.Xmodmap ). Nous avons défini notre clavier en US, mais il nous faut les accents. Comme pour le mode console, nous allons utiliser une touche " Compose ", toujours la touche diamant de droite, pour nous aider dans la saisie de ce type de caractère. Ces keycodes sont différents de ceux donnés dans Planète Linux, comme dit plus haut, tout simplement parce que le Lite2 est une version différente du HHK. En plus, je n'avais pas le Xev, ce super petit prog qui vous donne la correspondance des touches et des keycodes.

Encore mieux, j'ai lu sur le site MandrakeUser.org que la Mandrake posait des petits problèmes avec certaines touches " exotiques ", et que KDE et Gnome posaient des prob avec les fichiers Xmodmap.

Finalement, je me suis aperçu que Xev était présent sur un des CD fournis avec le Grand Livre Linux ( Distrib Corel), que j'ai depuis l'année dernière. Il ne s'installe pas, il faut seulement le copier sur votre disque dur, se placer dans le répertoire de destination, et saisir la commande Xev (ou xev) dans un terminal. C'est vraiment le top quand on a un doute : il balance directement la valeur de keycode correspondant à chaque touche.

Les codes à compléter pour le HHK Lite2 sont donc :

keycode 115= Multi_key

keycode 116= Meta_L

Ceci est à rajouter simplement dans le fichier .Xmodmap, généré lui-même par la commande xmodmap -pke > ./Xmodmap ( ou bien xmodmap -pke > ~/.Xmodmap ) Attention, ceci est réalisé en root, puis on copie le fichier dans chaque répertoire personnel des utilisateurs. Pour que tout cela soit activé dès la connexion sous KDE, il suffit de mettre un script de une ligne dans le dossier /root/.kde/Autostart, ainsi que dans chaque dossier utilisateur /home/user/.kde/Autostart. Ce serait apparemment le seul moyen : j'ai testé dans /etc/X11/xinit, xinitd, xinitrc, rc.local, les fichiers Xsession, etc... rien n'y fait !

Le script, à taper dans un éditeur de votre choix :

#!/bin/bash

xmodmap .Xmodmap

# c'est tout !

on enregistre sous le nom keyhhkl, par exemple, et on rend exécutable avec la commande : chmod +x keyhhkl

Il reste just à placer ce fichier script dans le dossier personnel /home/user/.kde/autostart de chaque utilisateur.

Sous Win98

Ce clavier étant " spécialisé " Unix dirons-nous, on peut néanmoins l'utiliser sous Windaube. Par contre, exit les sales touches Zindozs. On a des touches diamant de part et d'autre de la barre d'espace, dont une peut éventuellement servir de touche Win. Pour le configurere, la manip est rapide, on va dans Poste de travail/Panneau de configuration/Clavier, et on choisit la langue Anglais (Etats-Unis international). Il demande le CD de Win 98, et c'est fini ! Pour saisir les accents, c'est comme pour Linux, sans la touche Compose. Pour saisir un "é", on fait apostrophe " ' ", puis "e". " ü " est obtenu avec " '' " puis " u ". " ç " avec apostrophe " ' " puis "c", etc...

Je vais vous parler dans cette partie d'un problème que toute personne s'adonnant aux joies de l'info sous Windaube a déjà rencontré, le bug des VxD.  En effet, qui ne s'est jamais retrouvé face à l'écran de la mort, bleu et froid, qui nous indique " Erreur Fatale du bidule truc...VxD ". De nombreuses rumeurs circulent à ce sujet, et je dois dire que lorsque je me suis attaqué à ce problème l'année dernière, j'ai été immédiatement dérouté : certains disaient qu'il fallait absolument installer manuellement des pilotes *.vxd, car Windows ne les mets pas par défaut, et qu'ils apparaissent entre parenthèses dans le gestionnaire de périphériques. J'ai cru à cette légende, et c'est vrai que dans le gestionnaire de périphériques, une fois la manip d'installation à partir des dossiers *.cab du CD Win98 réalisée, ces mêmes pilotes n'apparaissaient plus entre parenthèses, on se disait alors que c'était une affaire classée. Mais perso, l'écran bleu est revenu. Donc...

Jusqu'au jour où je suis tombé sur un site traitant de ce problème. C'était en Anglais, et je décidai donc de l'imprimer pour le lire à tête reposée... Je vous livre ici ma traduction de ce document et vous laisse vous faire une opinion tout seul comme des grands...

Avec l'aimable autorisation de son auteur, Roy Lehrer (je n'ai plus l'adresse du site, mais ça doit pouvoir se retrouver),  et l'aide de my friend Micky Pernette pour traduire précisément quelques lignes...

  Avant d'aller plus loin en vous disant comment reconstituer un fichier vmm32.vxd corrompu, laissez-moi vous dire qu'il n'y a rien de vrai lorsque l'on dit que Win98 n'installe pas les fichiers *.vxd requis. Même s'il est possible qu'un tel bug ait existé dans une des premières versions beta de Win98 (alors appellée Memphis), il n'y a plus de bug comme celui-ci, sinon pourquoi n'aurait-il pas été reporté depuis Win95 ?

Il y a plusieurs sites sur lesquels vous pouvez lire des inepties sur ce soit-disant bug. Mon expérience montre que de tels sites vous informent mal en vous disant que tous les fichiers *.vxd ne sont pas installés, et que c'est là la cause de tous vos problèmes. Certains vont plus loin en vous conseillant d'installer à la main ces pilotes *.vxd : en allant dans le gestionnaire de périphériques (clic-droit sur le poste de travail puis propriétés et gestionnaire de périph...), on regarde dans les parties "détails des pilotes" si on a des trucs entre parenthèses, du type : C:\Windows\System\vmm32.vxd (configmg.vxd)...alors il faut extraire ces fichiers dits"manquants" à partir de certains répertoires *.cab du CD Win98, vers le répertoire  C:\Windows\system\iosubsys afin d'avoir plutôt : C:\Windows\System\configmg.vxd, ce qui serait l'entrée correcte.  Ceci est peut-être dû à quelqu'un qui a eut son vmm32.vxd endommagé, et comme sur l'Internet, tout va très vite, ça s'est transformé en un bug horrible...

Qu'est-ce que le vmm32.vxd ?

Vmm32.vxd est un pilote "monolithique" constitué de divers fichiers *.vxd. C'est un format d'archive W4, qui utlise la compression MRCI de Drivespace. De toute façon, pour faire simple, il suffit d'imaginer une archive de plusieurs fichiers *.vxd associés en une seule bibliothèque qui peut être chargée comme un seul fichier, à l'intérieur duquel les fichiers *.vxd peuvent être utilisés individuellement, comme s'ils étaient chargés un par un...  Le vmm32.vxd contient juste une collection de fichiers *.vxd nécessaires à votre système pour se lancer, et chaque fichier est débarassé des entêtes qui sont requises si ce même fichier était chargé séparément. Avec les entêtes en moins, et la compression utilisée dans vmm32.vxd, on arrive à une taille si petite, que ça contribue évidemment à avoir une vitesse de chargement plus rapide.

    Une des choses très importantes à propos de vmm32.vxd, est que l'ensemble des fichiers .vxd actuels qu'il contient est déterminé pour chaque système pendant l'installation de Win98, et que par conséquent, le fichier vmm32.vxd est différents d'une config à l'autre. Donc si votre vmm32.vxd est endommagé, il n'est pas possible d'aller en récupérer un chez le copain, à moins d'avoir exactement la même configuration et la même version Win98 que celui-ci...  Il faut aussi savoir que le vmm32.vxd qui peut être extrait des fichiers cab du CD Win98 n'est qu'un "squellette" de vmm32.vxd, qui sert à créer un "vrai" vmm32.vxd pendant l'installation, et que se contenter d'extraire le vmm32.vxd du CD Win98 ne suffira pas à restaurer l'intégrité dudit fichier. Si vous faites quand-même cette manip, en écrasant votre vmm32.vxd dans le répertoire  \Windows\system, vous ne pourrez certainement plus démarrer Win98.

Donc il est normal de ne pas trouver trace de certains autres fichiers *.vxd constituant le vmm32 (C'est peut-être pour cela qu'on appelle les *.vxd, pilotes de périphériques virtuels ! ). Et c'est sûrement pourquoi certains se sont dit que tous ces fichiers n'avaient pas été installés.   Dans le gestionnaire de périphériques, après avoir sélectionné un périphérique, on clique sur "Détails des fichiers pilotes", et on a une ligne  C\Windows\System\vmm32.vxd (configmg.vxd), qui est tout à fait correcte. Il nous dit que le pilote utilsé est configmg.vxd, mais que ce pilote est chargé depuis vmm32.vxd, au lieu d'avoir un fichier individuel. Si tel était le cas, on aurait plus un truc du genre : C:\Windows\System\configmg.vxd. Maintenant, il est possible qu'il faille actualiser les fichiers *.vxd à l'intérieur même de vmm32, et Win98 livre un moyen simple de le faire. Chaque système possède un répertoire \Windows\system\vmm32. Chaque fichier *.vxd de ce dossier sera automatiquement chargé et utilisé pour le démarrage de Win98 à la place de celui contenu dans le fichier vmm32.vxd, s'il existe au deux endroits. En d'autres termes, les fichiers de ce répertoire vmm32 sont "prioritaires" sur ceux du fichier vmm32.vxd. Donc si on écoute les personnes qui nous disent d'extraire manuellement ces fichiers, tout ce que l'on fera, ce sera de copier des fichiers déjà existants dans vmm32.vxd, dans le répertoire \windows\system\vmm32, ce qui aura pour effet de ralentir la bécane. Même l'entreprise du Billou nous dit que le fait d'extraire ces fichiers n'augmentera pas les performances de notre système, car une fois celui-ci démarré, il n'y aura pas de différences. Ces fichiers *.vxd se retrouvent regroupés en vmm32 pour gagner du temps au démarrage.

Pour voir la liste de tous les fichiers *.vxd inclus dans votre vmm32.vxd, lancer regedit, et aller dans la clé : 

HKEY_LOCAL_MACHINE \ System \CurrentControlSet \ Control \ VMM32Files. 

Tous les fichiers listés dans la partie droite de votre écran, sont dans votre copie personnalisée du fichier vmm32.vxd.  Vous remarquerez que c'est bien un fichier spécifique à votre config, qui ne peut être extrait du CD Win98, et dont on peut faire une sauvegarde immédiatement au cas où il serait effacé ou endommagé.

 - Si on l'a accidentellement effacé ou endommagé : le mieux est d'en faire une copie avant que ça n'arrive.

 - Si, à force d'installation de divers programmes, on a trop de mises à jour de fichiers *.vxd dans le dossier \Windows\system\iosubsys, on désire retrouver un vmm32.vxd plus rapide, ce qui en soit n'est pas d'une urgence extrême.

PROCEDURE :

Attention : certains passages vous indiquent que faire, mais pas forcément comment faire... Si vous n'êtes pas sûr de ce que vous faites, mieux vaut renoncer. D'autant plus que comme je l'ai déjà dit, la mise à jour de *.vxd n'est pas urgente, sauf s'il y a endommagement du vmm32.vxd. Je vous conseille donc de bien lire toute la manip avant de la tester, et surtout de faire des sauvegardes comme il est conseillé...

Vous allez devoir créer des fichiers BATCH ("équivalent" au script BASH sous Linux), qui vont permettre "d'automatiser" la manip...Il n'est pas nécessaire de passer en mode DOS (avant il le fallait), tout peut être fait depuis la GUI de Win98. Pour l'exemple, seules quelques lignes sont reproduites, en réalité, il y en a au moins une quarataine.

1)  En premier lieu, on va voir ce qu'il y a dans notre fichier vmm32.vxd. C'est donc dans la base de registre qu'il faut regarder : 

HKEY_LOCAL_MACHINE \ System \CurrentControlSet \ Control \ VMM32Files 

  On va exporter le contenu de cette clé dans VMM32.REG par exemple, pour l'étudier de plus près.

2) On ouvre ce VMM32.REG dans un éditeur (Wordpad), avec une fonctionnalité de "rechercher-remplacer", c'est préférable, et la possibilité d'enregistrer le résultat dans un fichier texte ASCII.

3)  Effacer les quelques premières lignes pour n'avoir qu'une liste du type : 

    "biosxlat.vxd"=hex:00

    "combuff.vxd"=hex:00

    "configmg.vxd"=hex:00

4)  Enregistrer sous le nom de WININIT.INI dont nous nous servirons tout à l'heure.

5) On ouvre à nouveau VMM32.REG dans l'éditeur, et on recherche la chaîne de caractères : "=hex:00 (avec le premier guillemet !), que l'on remplace partout par rien du tout, ce qui nous donne : 

     "biosxlat.vxd 

     "combuff.vxd 

     "configmg.vxd 

6)  Maintenant, on remplace toutes les chaînes : "  (un seul guillemet) avec l'une des lignes suivantes, selon votre version de Win9x :

   extract /a /y E: \win95\win95_02.cab         (avec un espace à la fin ! )     

ou bien : 

       extract /a /y E: \win98\base4.cab           (avec un espace à la fin ! )  

ATTENTION : il faut remplacer le E: par le chemin de vos fichiers *.cab, qui peut être un dossier quelconque sur votre disque dur, ou sur un CDROM. De plus, il faut respecter l'espace à la fin de la chaîne de caractère à replacer.

 On doit alors avoir un truc du style :   extract /a /y E: \win98\base4.cab  biosxlat.vxd

                                                            extract /a /y E: \win98\base4.cab  combuff.vxd

                                                             extract /a /y E: \win98\base4.cab  configmg.vxd

7) On ajoute les lignes suivantes au début de notre fichier (dans l'éditeur) :

 @echo off

c:

cd \windows\system

extract /a /y E: \win98\base4.cab  vmm32.vxd

cd \windows\system\vmm32

 Le c: dans la deuxième ligne indique la partition sur laquelle Win98 est installé. Il en est de même si votre répertoire Windows est à un endroit différent, c'est à vous d'adapter les chemins.

8) Maintenant, on ajoute les lignes suivantes, après les dernières lignes du fichier VMM32.REG, juste pour que le programme batch nous indique la fin du processus :

 cls

 echo extraction des fichiers terminée, vous pouvez fermer la fenêtre DOS !

9)  Il faut maintenant comparer votre liste de fichiers que vous voulez installer pour la mise à jour, avec celle présente dans le répertoire \windows\system\vmm32. Si un fichier de votre liste existe déjà dans ce dossier, il y a de grandes chances que ce soit une version plus récente que celle que vous voulez installer. C'est à vous de le déterminer. Si un fichier de \Windows\system\vmm32 est plus récent que celui que vous vous apprêtez à installer, bien sûr vous pouvez effacer ce fichier de votre liste de fichiers *.cab, pour ne pas écraser le fichier avec une version plus ancienne.

10) Enregistrer votre travail sous le nom de RECUPVXD.BAT (c'est un programme BATCH)

11) Charger le fichier WININIT.INI créé plus haut. voir 4)

12) Utiliser la fonction rechercher et remplacer pour la chaîne de caractères :  "=hex:00   à remplacer par :   =c:\windows\system\vmm32.vxd. Ce qui devrait donner : 

    "biosxlat.vxd=c:\windows\system\vmm32.vxd

    "combuff.vxd=c:\windows\system\vmm32.vxd

    "configmg.vxd=c:\windows\system\vmm32.vxd

13) On recherche alors la chaîne : "   que l'on remplace par  :   c:\windows\system\vmm32  ce qui donne :

    c:\windows\system\vmm32\biosxlat.vxd=c:\windows\system\vmm32.vxd

    c:\windows\system\vmm32\combuff.vxd=c:\windows\system\vmm32.vxd

    c:\windows\system\vmm32\configmg.vxd=c:\windows\system\vmm32.vxd

14)   Au début du fichier, on ajoute les sections suivantes :

 [SetupOptions]

 Combine=1

 [CombineVxDs]

    c:\windows\system\vmm32\biosxlat.vxd=c:\windows\system\vmm32.vxd

    c:\windows\system\vmm32\combuff.vxd=c:\windows\system\vmm32.vxd

    c:\windows\system\vmm32\configmg.vxd=c:\windows\system\vmm32.vxd

15) Enregistrer en gardant le nom WININIT.INI

16)  Déplacer les fichiers WININIT.INI et RECUPVXD.BAT dans votre dossier \windows

17) Au cas où, faites une sauvegarde de vos fichiers déjà existants dans votre répertoire c:\windows\system\vmm32, ainsi que du fichier vmm32.vxd et la base de registres.

18) Faites un Démarrer puis exécuter et taper :  RECUPVXD puis ENTRER. Le programme devrait se connecter au disque dur contenant Win98, et se rendre dans les répertoires appropriés, puis extraire tous les fichiers vers ces dossiers, en écrasant automatiquement ceux dont le nom existe déjà. La vitesse d'exécution de ce prog dépend évidemment de votre config, mais aussi du fait que ce prog extrait les fichiers un à un des archives cab. Mais bon, on demande pas la lune, vu le nombre de fois où l'on risque de s'en servir...

19) Redémarrer votre Win98 et vous devriez observer le process de WININIT.INI. On doit alors avoir un message : "Please wait while Setup update...(Merci d'attendre pendant la mise à jour...), qui indique qu'un nouveau fichier vmm32.vxd est en train de se créer à partir des fichiers individuels du répertoire c:\windows\system\vmm32. Pendant ce process, tous les fichiers utilisés pour créer vmm32.vxd seront effacés du dossier c:\windows\system\vmm32, laissant seulement ceux qui n'appartiennent pas à vmm32.vxd (c'est-à-dire ceux qui n'étaient pas listés dans notre fichier WININIT.INI), et qui auraient dû être là avant de faire cette manip de récupération.

 Voilà, notre vmm32.vxd est normalement reconstitué. Si tout fonctionne, faites une sauvegarde de ce nouveau vmm32.vxd afin de ne pas avoir à refaire tou ça !

Si vous avez des problèmes, comme l'impossibilité de relancer Win98, et si vous avez bien fait des sauvegardes, c'est très simple : il suffit  de remettre un fichier vmm32.vxd sain dans \windows\system, et d'effacer tous les fichiers du répertoire \windows\system\vmm32 qui n'étaient pas là quand vous avez commencé. Dans tous les cas, cette procédure n'effectue aucun changements dans la base de registres, donc vous n'avez pas à la restaurer. S'il y a un problème, ce sera sûrement dû à un endommagement de la base par vos soins...