Matériel #
Commande #
J’ai commandé deux packs de 23 switches cherry red qui me conviennent bien sur Amazon, un corne présoudé (les CMS sont trop petits et surtout je n’ai aucune compétence en soudage, et pas le temps d’apprendre) sur Amazon également. Il vient de Chine et met 3 semaines à arriver. Enfin, des keycaps compatibles Cherry et Corne, entièrement customisés sur yuzu key caps.
Le kit présoudé est plus ou moins conforme. Il a fallu dévisser le cadre supérieur pour réajuster latéralement, les tolérances ne permettant pas initialement d’insérer correctement les switches dans la partie gauche du clavier.
On note également la prise jack du clavier gauche très dure, sans que je ne comprenne pourquoi. En fin de compte, il est possible de connecter le jack, mais il faut assez bien forcer. A mon avis, le jack devrait rester à poste, sous peine de devoir un jour dessouder le composant pour en mettre un neuf après la bataille de trop lors du branchement. Ce n’est pas un problème si je trouve une housse de transport permettant de les transporter dos à dos, ce qui me semble être la meilleure option.
Spécificité du clavier Corne #
Après essai, il y a quelques adaptations à faire. La disposition Ergo-L proposée par défaut est adaptée à un clavier 105 touches standard. Or, mon Corne n’en fait que 46 (2x [3*6 + 5]). Il y a plusieurs layers, accessibles soit par maintien de touches dédiées, soit par frappe d’une touche morte. La touche morte donnant accès au layer de la ponctuation fonctionne, parce qu’elle fait partie du layout « de base » de l’ERGO-L, mais pas les autres touches (« rouge » et « bleu » dans mon jargon perso, c’est-à-dire l’accès au layer déplacements/chiffres et au layer ponctuation). Ils ont d’autres attributions par défaut.
Plus grave, les deux touches centrales des pouces ne produisent pas de signal détecté par l’OS. Les LEDs ne sont pas un indicateur fiable du fonctionnement du switch, puisqu’elles sont soudées sur le PCB. Les switch Cherry sont mis hors de cause par une interversion standard de deux touches voisines. Soit la touche n’est mappée sur rien dans le firmware, soit le PCB comporte un défaut au niveau de cette touche centrale de pouce. Je veux être optimiste et croire à une absence de mapping, puisque les deux touches non fonctionnelles sont à chaque fois les touches centrales du pouce. La coïncidence est trop grosse. Il me semble incontournable dès lors d’aller vers le flashage du firmware (https://github.com/foostan/crkbd/blob/main/docs/firmware/rev4/firmware_en.md). Toutes les autres touches sont vues même si elles n’ont pas l’effet attendu initialement (les touches de lettres sont OK, mais il y a du travail autour). Retournement de situation : l’OS ne voit pas non plus la touche Fn de mon clavier intégré, mais il fonctionne pourtant correctement, en me donnant accès aux fonctions correspondantes. Alors, c’est sans doute un défaut dans le layer qui n’attribue pas la bonne fonction (accès aux autres layers) à ces touches. L’enquête rebondit.
Sous Linux #
Comprendre la gestion des dispositions clavier #
Il semble que Wayland ait des difficultés avec la gestion des dispositions clavier. Le sujet est peu documenté d’après ce que j’ai trouvé. Il fallait donc redémarrer sous X11. Redémarrage, le choix se fait sur l’écran de connexion. Pas de différence notable à l’utilisation… Quelle est la différence réelle ?
Dans le choix linguistique, Ergo-L apparaît dans le groupe français. Quelle tristesse cet autocentrage français, comme si les québécois, belges, suisses et francophones d’Afrique comptaient pour du beurre. Bref.
Le fichier décrivant les layouts est : /usr/share/X11/xkb/symbols/fr. Dans ce fichier, les layouts sont définis à la suite les uns des autres pour une langue/situation géographique donnée. Chaque layout peut être dérivé d’un autre layout déjà présent dans le fichier, et qui est préchargé par include "nom". Les lignes qui suivent sont alors juste une modification de l’existant. (https://staticf0x.github.io/2021/custom-keyboard-layout-in-x11-and-wayland.html)
Chaque ligne contient une identification de la touche et ses différents effets dans les différents layers. La subtilité, c’est qu’il n’est pas toujours simple de connaître l’identification de la touche. En effet, elles sont identifiées par une chaîne alphanumérique de 4 caractères, qui pour les lettres notamment est du genre AD13. Le programme xev (en ligne de commande) permet de monitorer les entrées-sorties, et notamment l’appui des touches. Dans la sortie de xev, on peut voir une pseudo-identification de la touche par un nombre et une identification textuelle (exemple : keycode 66 (keysym 0xffe5, Caps_Lock), qui nous indique donc la touche 66, son identifiant hexadécimal parfaitement inutile, et l’information qu’il s’agit de la touche de caps lock). Mais cela ne me donne pas la chaîne de 4 caractères attendue dans le fichier fr.
Pour traduire, il faut aller lire le fichier /usr/share/X11/xkb/keycodes/evdev, qui contient une telle traduction. Les codes à 4 caractères y sont associés au numéro de la touche tel qu’on le lit dans la sortie de xev.
Le schéma est donc : xev -> appuyer sur la touche -> lire le numéro de la touche -> le chercher dans evdev -> encoder la bonne fonction de la touche dans fr.
Solution mise en oeuvre #
- Lister les touches non correctement identifiées
- Flasher le firmware pour modifier les choix que j’ai faits au niveau de la disposition des touches. En profiter pour comprendre ce qui arrive aux touches centrales des pouces, qui ne sont pas vues pour le moment.
- Adapter le layout pour certaines ponctuations dont j’ai fait le choix au moment de la conception des keycaps.
Linux-style : l’hyper-personnalisation, au prix de mouiller le maillot.
1. Lister les touches non correctement identifiées #
J’ai mappé mes touches et identifié leur numéro par xev, et leur identifiant associé :
| Touche | Numéro xev | Code alphanumérique |
| rouge | 36 | <RTRN> |
| bleu | 134 | <RWIN> |
| lierre | 65 | <SPCE> |
| ALT | 37 | <LCTL> |
| CTRL | ||
| espace | ||
| tab | 9 | <ESC> |
| ESC | 66 | <CAPS> |
| left shift | 50 | <LFSH> |
| right shift | 119 | <DELE> |
| enter | 48 | <AC11> |
| backspace | 22 | <BKSP> |
| delete | 62 | <RTSH> |
| cut | 105 | <RCTL> |
| copy | 64 | <LALT> |
| paste | 23 | <TAB> |
Il est évident que, plutôt que de s’user à remapper un ESC parfaitement fonctionnel, on peut avantageusement flasher le firmware pour associer l’actuelle touche 9 à l’actuelle touche 66. CAPS est sur ma layer rouge, donc sa disparition des touches physiques ne me dérange pas. L’actuelle touche 23 doit, elle, venir à la place de la touche 9 pour que les TAB soient aussi associés correctement. Il faudra que j’utilise une touche absente du corne, par exemple la rangée numérique du clavier traditionnel, pour y associer mes touches cut, copy et paste.
2. Flasher le firmware #
C’est malheureusement difficilement contournable vu la disparition de mon CTRL et de ma touche espace. Mais c’est terrible. Car il me faut à présent ENTIEREMENT redémonter les claviers afin d’accéder au PCB où la légende raconte que se trouvent des boutons BOOT et RESET sur lesquels il faut appuyer pour pouvoir flasher le firmware.
Démontage effectué du clavier droit : ce n’est pas infaisable, mais la faible section des pins des switches m’incite à éviter de reproduire l’expérience autant que faire se pourra. Je marque l’emplacement des boutons sur le fond du boîtier du clavier en vue de percer un jour permettant d’actionner lesdits boutons à l’aide d’un cure-dents. C’est certainement plus viable qu’un démontage par flashage. Le gauche sera pour demain. J’en profiterai pour chercher des défauts sur la prise jack.
Le flashage doit se faire par navigateur compatible WebHID. En gros, Chrome, Edge, ou Opera. Optons pour la solution norvégienne.
VIAL voit le clavier et permettra de faire les changements appropriés. Reste que les touches centrales des pouces sont actuellement affectées à « Fn1 (Fn3) » et « Fn2 (FN3) ». Se peut-il que l’OS ne voie rien, car ma configuration matérielle de clavier est « clavier générique 105 touches », sur lequel il ne s’attend pas à voir ces touches ? Elles seraient… Hors range, compte tenu de ses attentes ? Mais alors comment configurer le clavier du point de vue de l’OS pour qu’il s’attende au bon nombre de touches sur le Corne sans flinguer le clavier intégré ? Je pourrais attribuer à ces touches des valeurs attendues par l’OS, telles que celles de la rangée de symboles (&é »‘…). Et attribuer au niveau logiciel (dans la définition du layout, dans le fichier fr) la fonction d’accès aux autres layers à ces touches. Mais, alors, je dois déjà prévoir de générer ma propre disposition clavier sous Windows pour répliquer cette configuration. Il faut donc prendre le temps d’évaluer dès à présent deux options : trouver un moyen de convaincre Linux d’accepter la touche Fn1 ou Fn2 à ces touches sans perdre l’usage du clavier intégré, ou examiner la génération de dispositions sous Windows. La deuxième option me semblera de toute façon nécessaire : c’est elle que j’explore donc en premier.