Low profile ANSI/ISO FR Hybrid — 01

Layout

Liste de courses

Plate - MX spacing

Combo Keyboard Plate Generator by Keebio (pour les formes des stabilisateurs low-profile) et Plate & Case Builder de SwillKB (pour les emplacements des vis et la forme de la plaque). J’ai longtemps hésité pour l’espacement des touches et me suis rabattu sur 19 mm (au lieu de 19,05 mm ou une valeur plus basse en fonction de la taille des keycaps MBK) en me basant sur l’espacement qu’Apple applique à tous ses claviers. Si ça fonctionne avec le Magic Keyboard pour cet espacement, ça devrait le faire pour du low profile aussi…

Paramètres

Keebio

Switch cutouts:      MX / 0 mm
Stabilizer Cutouts:  Choc / 0 mm
Keyspacing:          19 mm / 19 mm
Kerf:                0 mm

SwillKB

Switch Type:      MX {_t: 3}
Stabilizer Type:  osef
Case Type:        Sandwich
Mount Holes:      10 / 3.5 / 10
Edge Padding:     Yes, 10 / 10 / 10 / 10
Plate Corners:    Yes, 5
Kerf:             No
Key Unit Size:     19 mm

Par défaut, on ne peut pas avoir aucune découpe de stab mais en éditant la requête et la renvoyant, on peut obtenir le SVG (ou les autres fichiers) sans ces infos. Peut importe, cela dit, puisqu’on va éditer les SVG dans Inkscape après coup.

Retouche des fichiers

Édité le layer des switchs généré par SwillKB et placé les formes des stabilisateurs venant de celui généré par Keebio.

Plate - Choc Spacing

Testé un autre espacement (H:18mm, V:17mm) avec ai03 Plate Generator pour choisir l’espacement vertical et horizontal des touches (possible également avec celui de Keebio, vu que la dimension des switches Chocs est la même que pour des MX).

Paramètres

Keebio

Switch cutouts:      MX / 0 mm
Stabilizer Cutouts:  Choc / 0 mm
Keyspacing:          19 mm / 19 mm
Kerf:                0 mm

SwillKB

Switch Type:      MX {_t: 3}
Case Type:        Sandwich
Mount Holes:      10 / 3.5 / 10
Edge Padding:     Yes, 10 / 10 / 10 / 10
Plate Corners:    Yes, 5
Kerf:             No

J’ai ensuite refait le contour et replacé les trous pour les vis sur Inkscape. À voir si c’est plus agréable pour taper que l’espacement de 19mm standard (on verra sur les prototypes en carton).

Choix des switches

J’ai commandé via Keecapsss un support pour tester des switches (je n’étais pas sûr des brown au final). J’en ai profité pour commander les stabilisateurs et les sockets hotswap pour low profile en même temps. Je suis passé via splitkb.com pour les switches. J’ai commandé un de chaque avec des touches transparentes afin de faire mon choix.

Rien qu’en jouant un peu avec, je penche déjà pour les purples; je me laisse le temps de réfléchir et je commanderai quand je serai décidé.

Plate protoype

J’ai récupéré du carton épais, collé une impression des templates dessus et découpé (c’est long…) pour pouvoir tester le layout. Rien que comme ça, sans les switches, je me rend compte que le backspace (en haut à droite) serait mieux placé s’il était plus proche de la touche d’avant (+ / = / }), même si sur le papier ça rend plus joli. De toutes manières, le design est bancal, faut au moins que ça soit utilisable.

Layout v0.2

Après avoir fait quelques ajustements, j’ai déplacé la touche µ/* et Entrée et échangé la version 2u du backspace par celle en 1,5u (en vrai, c’était la suppr mais en la retournant…) pour me rapprocher le plus possible du ANSI. Pour que ça soit plus harmonieux et tant qu’à faire, j’ai rajouté les touches Del et déplacements dans la page pour arriver à un 65% plus équilibré et qui devrait être plus pratique. Je compte commander des touches blank MBK en plus pour compléter le set de keycaps.

Du coup, mon proto est déjà obsolète. Je vais devoir reprendre le layout du plate et me retaper de la découpe 🫠

[{c:"#4f4f4f",t:"#ffffff",p:"FLAT"},"Esc",{x:0.25,a:5},"1\n&","2\né","3\n\"","4\n'","5\n(","6\n-","7\nè","8\n_","9\nç","0\nà","°\n)","+\n=",{a:4,w:1.5},"Backspace",{x:0.25},"Del"],
[{w:1.5},"Tab",{x:0.25},"A","Z","E","R","T","Y","U","I","O","P","¨\n^","£\n$","µ\n*",{x:0.25},"Pg Up"],
[{w:2},"Caps Lock","Q","S","D",{n:true},"F","G","H",{n:true},"J","K","L","M","%\nù",{w:2},"Enter","Pg Dwn"],
[{w:1.5},"Shift",">\n<","W","X","C","V","B","N","?\n,",".\n;","/\n:","!\n§",{w:1.5},"Shift","Up","End"],
[{w:1.5},"Ctrl",{w:1.5},"Super",{w:1.5},"Alt",{a:7,w:2},"",{x:1,w:2},"",{a:4,w:1.5},"Alt-Gr","Fn","Super","Left","Down","Right"]

KLE Layout

Test PCB

J’ai commencé à regarder des tutos pour pouvoir faire un PCB tout en me renseignant sur quel MCU utiliser (le Pro Micro n’a pas assez d’entrées pour le nombre de touches de ce projet); je pense soit prendre un 0xCB Helios (open source, nécessite quelques ajustements au niveau du firmware), soit un Elite-C (ATMega32U4, même puce que pour le Pro Micro mais avec plus d’entrées, propriétaire).

J’avais déjà suivi le tuto d’ai03 mais j’en ai trouvé un autre plus récent (Kicad est quand même à la version 8.0…) –> Designing a Keyboard PCB from scratch using KiCad 7 qui est pas mal complet. J’ai récupéré les symboles et footprints conseillés par la team de l’Helios, la [mastarlib], qui comporte des symboles et empreintes pour les choc v1, entre autres. Les empreintes ont des repères pour un espacement MX (19,05mm) et Choc (18x17mm). Je vais tenter de tester les deux espacements avec les prototypes à venir.

Layout v0.4

La version 0.3 comportait une légère modification des touches alt-gr et menu.

J’ai trouvé des variantes 1.25u, 1.75u et 2.25u des MBK en POM, conçu par moergo; on peut les trouver sur splitkb.com sur lequel je les ai commandés. Ce qui fait que je peux allonger les barres d’espace (ça ne vaut pas le coup, selon moi de choper tout un kit à 50€ juste pour une barre d’espace en 6.25u) et ajuster les touches modifiers (ctrl, shift, etc). À voir également sur le placement des barres d’espace (v0.4.0 et v0.4.1), on verra à l’usage. J’ai également allongé la touche µ/* donc j’ai commandé une touche 1.5u supplémentaire. Pareil pour des 1u pour les touches del etc.

KLE Layout

[{c:"#4f4f4f",t:"#ffffff",p:"FLAT"},"Esc",{a:5},"1\n&","2\né","3\n\"","4\n'","5\n(","6\n-","7\nè","8\n_","9\nç","0\nà","°\n)","+\n=",{a:4,w:2},"Backspace","Del"],
[{w:1.5},"Tab","A","Z","E","R","T","Y","U","I","O","P","¨\n^","£\n$",{w:1.5},"µ\n*","Home"],
[{w:1.75},"Caps Lock","Q","S","D",{n:true},"F","G","H",{n:true},"J","K","L","M","%\nù",{w:2.25},"Enter","Pg Up"],
[{w:1.25},"Shift",">\n<","W","X","C","V","B","N","?\n,",".\n;","/\n:","!\n§",{w:1.75},"Shift","Up","Pg Dwn"],
[{w:1.25},"Ctrl",{w:1.5},"Super",{w:1.5},"Alt",{a:7,w:2.25},"",{x:0.5,w:2.25},"",{a:4,w:1.25},"Alt-Gr",{w:1.25},"Fn",{w:1.25},"Super","Left","Down","Right"]

KLE Layout

Reste à refaire des plateaux adaptés pour la v4.0 avec les différents espacements.

Firmware avec QMK

Après avoir installé l’outil CLI de QMK et forker le dépôt Github (et uploadé sur Codeberg –> qmk firmware fork, branche lopro_bybrid, URL sujette à changement si autohébergement), j’ai utilisé la commande ci-dessous (cf QMK Docs - CLI Commands - qmk new-keyboard):

qmk new-keyboard

On répond aux questions: nom du clavier, layout par défaut - ici ANSI 65 - mcu, etc.

Cela génère le dossier et les fichiers keyboard.json (info.json dans la doc) ainsi qu’un keymap.c dans le dossier keymap/default.

QMK et utiliser des layouts non-US

Pour mapper les touches du clavier français, on doit préciser à QMK qu’on utilise un layout non-US dans le fichier keymap.c. On utilisera les keycodes définis dans le header correspondant pour les lettres non dispo dans le clavier QWERTY de base. Lorsque le clavier sera connecté à un OS en FR, cela enverra le code correspondant à la touche version ANSI qui sera interprété par le bon caractère par l’OS.

De ce que j’ai compris, cela est dû au fait que la plupart des constructeurs ne s’embêtent pas à modifier leur hardware, mais modifient uniquement les touches imprimées… Ce serait également dû au fait que l’USB ne peut pas transporter de code Unicode (trop lourd) mais que de l’ASCII.

Les différents layouts sont décrits dans la doc de QMK –> QMK Docs - Language-specific Keycodes Plus d’infos dans cet article du blog de Pascal Getreuer –> QMK: Typing non-English letters

Vu qu’on veut faire un clavier ANSI-FR (une sorte de monstruosité), on aura juste besoin de spécifier le header sendstring de la langue, le header correspondant aux keycodes étant inclus dans celui-ci:

#include "sendstring_french.h"

Les headers sont dans le dossier quantum/keymap_extras/.

Fichier keyboard.json

On doit renseigner des infos dans ce fichier. Cela permettra ensuite de compiler le firmware. Les infos à remplir sont décrites dans la doc –> QMK Docs - info.json Reference.

Lorsque l’on a créé le clavier via la CLI, la plupart des infos ont été renseignées. On doit maintenant modifier les objets matrix_pins (les connexions sur le MCU) et layouts (les positions et les tailles des touches n’étant pas exactement les mêmes que celles du template 65_ansi utilisé). Le fichier du keymap par défaut se trouve ici –> layouts/default/65_ansi/default_65_ansi/keymap.c

Les connexions sur le MCU sont pour le moment définies comme montré ci-dessous:

Plus d’infos dans la partie PCB (si je me décide à le finir et le faire faire). Les connexions pourront changer mais pour l’instant on va partir là-dessus. Cela me permettra de tester de flasher le MCU avant le montage.

D’après la doc de QMK (voir QMK Docs - Raspberry Pi RP2040 - Pin nomenclature), les connexions sont à renseigner de la manière suivante:

To address individual pins on the RP2040, QMK uses the GPx abbreviation – where the x stands for the GPIO number of the pin. This number can likely be found on the official pinout diagram of your board.

Petite pause avant de reprendre

À la base, je voulais faire un build log qui retraçait tout le parcours suivi pour fabriquer un clavier mécanique low profile complètement DIY. J’ai bien lu que c’était compliqué, long, et coûteux. Sauf qu’en fait, je m’en fiche du temps que ça prend. Ça m’intéresse plus d’apprendre plein de trucs différents, de tester divers logiciels, de fouiller sur le net pour trouver (ou pas) une réponse à la question que je me pose sur le moment, ou l’hésitation que j’ai.

Sauf que je suis super mal organisé. Déjà, regarde ce build log. Aucune date; j’ai pas été fichu de noter les dates des diverses entrées. Je pensais que ça allait être un processus en ligne droite, sauf que, comme pour chaque projet que j’entreprend, c’est des aller-retours, des voies sans issue, de la perte de temps sur un sujet peut-être sans importance et surtout, surtout, aucun moyen de savoir où j’en suis.

Du coup, j’ai commencé à faire des listes de trucs à faire. Je m’y tiens pas forcément mais au moins ça structure. Le fait d’avoir séparé les dépôts Git du “boîtier” (‘fin le truc en sandwich 😅) et le PCB a déjà permis avoir un meilleur recul.

Ce que j’aurais dû faire dès le début, c’est intégrer le temps d’écriture dans le temps pris par le projet. C’est quelque chose que j’avais vaguement l’habitude de faire quand j’étais petit mais que je n’ai pas pris le temps de refaire depuis. Documenter, ne serait-ce que pour se relire des semaines ou années plus tard et se dire “ah ouais, c’est vrai, j’avais fait ça”.

Bref, je me perd un peu, je vais arrêter cette — longue — parenthèse, et je vais changer le mode d’écriture de ce build log. Déjà, je pense séparer les posts par date d’écriture, plutôt que de faire des aller-retours entre les différentes sections. Ça sera déjà plus réaliste et me donnera une meilleure idée de mon avancement (genre “ah oué, ça fait 2 mois que j’ai rien foutu, lol”).

Une fois que j’aurais fini ce projet, je verrai si je fais un post récap ou une doc plus “tuto” ou “technique” pour synthétiser ce que j’ai appris.

See you on the next post (or never, we’ll see).