Le blues du clavier avec la console en mode texte d'Ubuntu©

Désolé, la punition de la terminologie d'abord : la « disposition de clavier » s'assimile normalement à un fichier dans lequel sont définis les caractères en relation avec telle ou telle touche. Cette relation peut concerner les touches ordinaires isolées, mais peut également se rapporter à des touches modifiées, par exemple, par un appui préalable sur Ctrl ou Maj.gauche. Dans le fichier de disposition, l'ensemble des mises en correspondance des touches en association avec un modificateur donné va constituer une nouvelle disposition ; donc nous aurons une disposition des touches avec modificateur Ctrl, une autre avec modificateur Alt et ainsi de suite. Maintenant, tenez vous bien Ubuntu© définit 64 dispositions de clavier. Toutes les combinaisons possibles entre modificateurs y sont. Ne me demandez pas pourquoi les combinaisons bizarres avec 3, 4 ou 5 modificateurs sont là, étant donné qu'elles ne pourront pas selon toute vraisemblance être frappées tant que les hommes ne disposeront que de deux mains. Mais elles sont là, et c'est comme ça. Comparez avec openSUSE© ou Fedora© : vous n'y trouverez que des combinaisons associant un ou deux modificateurs pris dans le jeu des Maj—ctrl—alt—altgr— et non toutes la combinatoire de ceux-ci. Ce qui est sensé. L'incidence est peut-être marginale, mais laissez moi signaler que le fichier de cartographie d'Ubuntu© est vingt fois plus gros que celui d'openSUSE© ou de Fedora©, et de ce fait, doit avoir un certain impact sur la mémoire disponible. Je n'ai jamais remarqué de différences lors de l'utilisation d'openSUSE© ou Ubuntu©, mais l'effet doit bien être là.

https://bugs.launchpad.net/Ubuntu/+source/console-data/+bug/279973 … et vous apprendrez qu'en appuyant sur Impr.écran la console Ubuntu© génère un Control_backslash (^\ : Ctrl barre inclinée inverse), alias le caractère 28 (décimal). Le rapport de bogue est relatif à la version 8.04, mais cette « fonctionnalité » est toujours présente dans la version 8.10 : sachez que le caractère 28 a des appétences de vandale dans certaines applications, et que, de la sorte, des travaux peuvent être perdus—et que cela est arrivé, bien sûr, comme le lien précédent le signale. Control_backslash peut également être généré par CtrlImpr.écran ; il n'y a aucune objection à cela, et peut-être est-ce même intentionnel. Mais appuyer sur la touche Impr.écran isolément et par inadvertance est un incident tout à fait possible.

La disposition de clavier américain par défaut et celle de quelques autres langues que j'ai testées (allemand, français, espagnol, italien, russe) définissent des chaînes pour les variables F1 à F20 (NdT: bien différencier la variable Fn de la touche Fn) . Il y a aussi des variables au delà de F20 (F21 et au-dessus), mais sans que des chaînes aient été définies pour celles-ci. Cette dernière singularité pose problème pour toutes les distributions, mais dans cet article nous nous sommes penchés sur les différences entre Ubuntu© et les configurations conventionnelles, c'est à dire entre l'approche héritée de console-tools par opposition à celle de kbd. Les distributions fondées sur kbd sont une écrasante majorité. Montrons leurs différences avec Ubuntu©, en ce qui concerne les correspondances pour Maj.F1 et au-delà :

 	
                 kbd             console-tools
                (openSUSE)      (Ubuntu)

    <Maj.><F1>     F13             F11
    <Maj.><F2>     F14             F12
    <Maj.><F3>     F15             F13
    <Maj.><F4>     F16             F14
    <Maj.><F5>     F17             F15
    <Maj.><F6>     F18             F16
    <Maj.><F7>     F19             F17
    <Maj.><F8>     F20             F18
    <Maj.><F9>     F21 (vide)      F19
    <Maj.><F10>    F22 (vide)      F20
    <Maj.><F11>    F23 (vide)      F21 (vide)
    <Maj.><F12>    F24 (vide)      F22 (vide)
	 
		     
	    

Ma première remarque, ici, sera de dire que les touches F9, F10, F11, F12 combinées avec Maj. ne sont utilisables ni avec openSUSE©, ni avec les autres parce que les variables F21 et au delà ne sont pas définies ; c'est uniquement une chaîne vide à laquelle aucune application ne peut associer de fonction. De la même manière, Maj.F11 et Maj.F12 ne sont pas disponibles chez Ubuntu©.

Toutefois, à cause de la fatale décision de Debian© de basculer vers console-tools il y dix ans passés, ce que nous constatons aujourd'hui est mauvais : une application en mode ligne de commande reliant une fonction à, disons, Maj.F4 verra cette fonction exécutée, soit sous openSUSE©, Fedora© et compagnie, soit sous Debian© et Ubuntu©, mais cela ne sera pas possible pour l'ensemble de ces deux groupes.

C'est pourquoi, nous formulerons ici une respectueuse demande à Ubuntu©, Canonical©, et Mark Shuttleworth : il est temps de corriger ces affectations, et d'accepter les valeurs par défaut du paquetage kbd pour les touches de fonction modifiées.

En plus de cela, veillez à introduire des chaînes pour F21, F22 et au delà. À quoi cela sert-il d'assigner des variables à des touches modifiées, si ces variables ne délivrent qu'une chaîne vide ?

Avec ces deux mesures d'un réformisme timide, deux à trois douzaines de touches de fonctions modifiées deviendraient instantanément disponibles pour les applications en mode texte. Ainsi par exemple, Ubuntu© installe l'éditeur nano par défaut. Pourquoi donc nano n'utilise-t-il que les touches de fonctions non modifiées, et fait appel à des règles absconses comme l'utilisation de altunderscore (Alt_souligné) pour étendre le champ des combinaisons de touches ? C'est parce que les touches de fonctions avec modificateur ne sont pas définies de façon cohérente entre les distributions. Faut-il passer tant de temps pour résoudre ce problème ? D'autant que les touches de fonctions modifiées sont internationales par essence. Jetez juste un coup d'œil sur altunderscore sur des claviers non-US.

La touche Secure Attention Key (SAK, NdT: mot à mot Touche Prévenances en toute sécurité —si on est amoureux de son ordinateur— ou bien Mise au garde-à-vous en toute sécurité— si l'on a l'esprit militaire—les deux mènent au même résultat) n'est pas à proprement parler une touche ; il s'agit d'une fonctionnalité à laquelle on peut (ou ne pas) faire correspondre de touche lors la compilation du noyau. Si cela a été prévu lors de la compilation du noyau, la fonctionnalité est déclenchée par altImpr.écrank. Toutefois, quelles que soient les options de compilation du noyau, SAK peut être affecté à n'importe quelle autre touche de votre choix. Cette fonctionnalité tue tous les processus de la console active, et vous déconnecte. Cela est pratique quand vous manipulez quelque application et trouvez le moyen d'obtenir un clavier totalement muet : tant que le noyau est actif, SAK vous répondra toujours.

Le noyau de 8.10 incorpore la fonctionnalité SAK—mais un SAK bogué:

http://ubuntuforums.org/showthread.php?p=6169912

Appuyer sur SAK vous met la panique dans le noyau, et votre seule possibilité est de couper l'alimentation de l'ordinateur. Une bizarrerie en quelque sorte, n'est-ce pas ? La fonctionnalité SAK incorporée ne peut pas être désactivée, et donc les utilisateurs peuvent juste planter leur ordinateur le cœur léger. Ubuntu© se spécialise-t-il dans la sécurité ?

Le remède à cela ne consiste pas à modifier la disposition du clavier ; il consiste à ne pas activer l'option SAK (SysReq) à la compilation. Les utilisateurs auront toujours la possibilité de rétablir la fonctionnalité sur leur clavier s'ils le souhaitent—après que le bogue SAK aura été débusqué, bien sûr.

( Entre parenthèses, il a été démontré que le bogue SAK était spécifique à certains matériels, voir :http://article.gmane.org/gmane.linux.ubuntu.user/165993/match=sak+producing+kernel+panic.)