Création d'un clavier - épopé logicielle !

robin_moussu · 12/3/2014 21:58:13

Salut à tous,

Comme certain le savent, vu que j'en avais parlé il y a quelque temps, je veux me fabriquer un clavier mécanique matriciel, et configurable.
Attention, c'est un peu long

= Introduction =
Aujourd'hui je vais vous parler de la partie logicielle embarqué dans mon clavier. Mon but est d'avoir un système d'évaluation d'évènements (un peu comme xkb sous linux) qui associe à une suite de touche un message. Afin de simplifier, j'ai considéré ici que le message de sortie sera systématiquement une lettre, mais en réalité (quand mon projet sera fini), les messages pourront être un simple caractère, une suite de caractère, ou même une macro. Ce message sera ensuite converti dans la langue des claviers, de manière à faire croire à l'OS que c'est un clavier configuré dans sa disposition préférée. Ainsi, mon clavier pourra être configuré en bépo pour moi, et s'occupera de faire les conversions qui vont bien si l'OS est configuré en azerty ou autre.

En résumé :
Appuie sur une où plusieurs touches => message => évaluation des macros => conversion en langage clavier dans la disposition de l'OS de destination => envoie dans la liaison USB.

Cette petite introduction n'était là que pour vous permettre de comprendre le contexte de mon problème.

= Problématique =

Je ne m’intéresse ici qu'a la partie « Appuie sur une où plusieurs touches => message », avec un message de type caractère unique.
« Quelle sont les killers features d'un clavier », autrement dis, quelle sont les actions type auxquelles on peut s'attendre ? J'ai essayé de recenser tout les cas tordu qui me viennent à l'esprit, et je me tourne vers vous afin de voir si je n'ai rien oublié ! (la voilà enfin ma question )

Afin de schématiser tout cela, je vais utiliser un clavier minimal ayant les touches suivantes
- key_a // alphabétique
- key_b // alphabétique
- key_maj // modificatrice
- key_accent // modificatrice + caractère au relâchement
- key_symbol // modificatrice + touche morte
Les touches key_a et key_b ont le comportement que l'on pourrait attendre d'une touche alphabétique, Les touches key_maj, key_symbol et key_accent ont le comportement d'une touche modificatrice. De plus key_accent est une touche morte (comportement similaire à celui des touches dans .Xcompose), et key_symbol envoie un caractère lorsqu'elle est relâché, si aucune autre touches ne sont pressées lors de son activation. Si vous n'avez pas compris, lisez la suite ça devrait aller !
Mon clavier sera capable d'envoyer les caractères « aAbB#$âÂIḃ ». J'ai pris ces caractères car ils sont bien visible et le comportement est simple à comprendre.

Je vais utiliser la convention suivante : « A » signifie que la touche key_ est enfoncée, « a » a quand la touche key_a est relâchée. Les actions sont effectuées dans l'ordre de lecture, sauf si elles sont entre parenthèse, dans ce cas l'ordre est indifférent. Le message émis est mis entre guillemets. Entre deux séquence de touches (chaque ligne de cas d'utilisation), elle sont toutes relâchées, et le clavier retrouve sont état d'origine.
ex : A B (ab) signifie que la touche key_a est maintenue le temps que key_b soit à son tour enfoncée, puis elles sont relâchées dans un ordre quelconque.

= Les cas d'usages =
A«a» a // La touche key_a est enfoncée, le message « a » envoyé, puis a est relâchée
B«b» b // Même chose pour la touche key_b
A«a» B«b» (ab) // Lors de l'appuie successif sans relâchement sur key_a et key_b les caractères «a» et «b» sont envoyés au moment de l'appuie sur la touche, et l'ordre de relâchement des touches n'a pas d'importance

MAJ maj // La touche key_maj seule n'a pas d'effet
MAJ A«A» (maj a) // Comportement classique d'une touche maj
MAJ B«B» (maj b) // idem
MAJ A«A» (a B«B») maj // maj reste actif tant qu'il est pressé

SYMBOL symbol«#» // Contrairement à key_maj, la touche key_symbol envoie le caractère «#» lors de son relâchement si elle est utilisé seule
SYMBOL A«$» (a symbol) // Si un caractère est pressé en même temps que key_symbol, «#» ne sera pas envoyé
(SYMBOL MAJ) symbol A«A» (a maj) // maj reste actif même si un autre modificateur a été relâché (même sortie que key_maj + key_a)
(MAJ SYMBOL) maj A«$» (a symbol) // même chose pour symbol qui est aussi un modificateur (même sortie que key_symbol + key_a)

ACCENT accent // accent seul n'a pas d'effet
ACCENT A«â» (a accent) // utilisation classique d'une touche morte
ACCENT accent A«â» a // autre utilisation classique d'une touche morte
ACCENT A«â» (a accent) B«b» b // l'effet de la touche morte était déjà "utilisé" pour b
ACCENT accent A«â» a B«b» b // variante
ACCENT A«â» (a B«ḃ») (b accent) // b subit l'effet du modificateur accent (et je n'avais pas de meilleur b accent )

(ACCENT MAJ) A«Â» (a accent maj) // les modificateurs se cumulent
ACCENT (accent MAJ) A«Â» (a maj) // key_accent étant une touche morte les modificateurs se cumulent toujours
(ACCENT SYMBOL) A«â» (a accent symbol) // symbol n'a pas d'effet sur accent + key_a, donc accent + key_a est utilisé
// je rajoute une touche key_grave qui est aussi une touche morte
ACCENT accent GRAVE grave a«à» // L'appuie sur une touche morte ne relâche pas l'effet des touches mortes précédentes

Voila. Merci pour votre attention
Et donc, est ce que vous voyez des cas que je n'ai pas prévu.

Dernière modification par robin_moussu (12/3/2014 22:00:53)

lawrent · 12/3/2014 23:14:12

J'ai une question stupide, mais est-ce que le plus simple ne serait-il pas de faire comme tous les autres claviers et te limiter à envoyer des keycodes qui sont ensuite gérés par xkb (ou autre)? J'ai un doute que l'OS gère directement des caractères en entrée…

rat bière sé · 13/3/2014 05:52:06

lawrent a écrit :

J'ai une question stupide, mais est-ce que le plus simple ne serait-il pas de faire comme tous les autres claviers et te limiter à envoyer des keycodes qui sont ensuite gérés par xkb (ou autre)? J'ai un doute que l'OS gère directement des caractères en entrée…

à mon avis robin sait déjà que les caractères ne peuvent être envoyés sinon on aurait déjà un clavier bépo ne dépendant pas de l'OS.
Ce qu'il veut dire, pour moi, c'est que dans « Appuie sur une où plusieurs touches => message => évaluation des macros => conversion en langage clavier dans la disposition de l'OS de destination => envoie dans la liaison USB. » la partie conversion c'est pour les keycodes. Donc pour que ça fonctionne correctement, ce clavier intelligent (en arm àmha, pas en atmel) doit connaitre la disposition du clavier (comme le switch qwerty-dvorak sur le TM) et dépend de celle ci : il reste donc impossible de faire les accents en us-qwerty par exemple sans spécifier l'OS utilisé pour sélectionne la bonne macro du raccourci unicode.

robin_moussu · 13/3/2014 14:44:44

C'est tout à fait ça. Il faudra que je regarde plus en détail comment c'est codé, mais si mon clavier est un bépo, et que l'ordi est en azerty, pour envoyer le message «â», j'enverrai le keycode «altgr» et même temps le keycode de la touche «8» puis le keycode de la touche «a» en azerty (sachant que c'est la touche associé au «b» en bépo).

L'idée est de manipuler des messages dans le clavier, ce qui simplifie l'utilisation des macro. La conversion en keycode n'ayant lieu qu'ensuite, ce qui fait que je peux changer d'ordi sans problème. Mon but étant de faire croire au pc que je possède un bête clavier tout ce qu'il y a de plus banal.

Sinon, vous avez des idées auxquelles je n'ai pas encore pensé dans les séquences de touches ?

Dernière modification par robin_moussu (13/3/2014 14:47:39)

jeff · 13/3/2014 22:26:48

Je n'ai pas vu le cas de l'appui prolongé sur une touche.

Est-ce que l'étude du code de TMK t'a apporté quelques éléments ?

Dernière modification par jeff (13/3/2014 23:05:59)

lawrent · 14/3/2014 09:37:38

Robin: et comment est-ce que tu comptes gérer que azerty et bépo n'ont pas les mêmes touches en Maj (pour la ponctuation) ni Altgr?

rat bière sé · 14/3/2014 21:40:10

lawrent a écrit :

Robin: et comment est-ce que tu comptes gérer que azerty et bépo n'ont pas les mêmes touches en Maj (pour la ponctuation) ni Altgr?

Il va utiliser les raccourcis unicodes U+un chiffre : en tout cas c'est le standard Windows. Pour un autre OS, ça dépend fortement de l'environnement de bureau et ÀMHA les raccourcis sont différents selon qu'on soit sur OSX, Gnome, KDE, Openbox, BSD… et pas forcément faisables en tty

robin_moussu · 14/3/2014 21:49:58

@jeff : merci beaucoup ! J'avais totalement oublié les appuis longs (j'y avais pensé il y a un bout de temps, mais depuis, ça m'est sortit de la tête). De toute façon, je risque d'avoir besoin de gérer le temps, alors ça ne devrais pas rajouter de travail.
Je ne vois pas ce que tu veux dire par TMK, est ce que tu peux me redonner les liens, je suis sur de ne pas les avoir lus.

@lawrent : Je comptais faire un post plus tard pour le détailler, mais imaginons que mon clavier soit en bépo, l'ordi A en azerty, et l'ordi B en qwerty.
J'appuie sur les touches «bépo<espace><majuscule><^>» ce qui correspond au message «bépo !».

Sur l'ordi A. Si mon clavier était un bète clavier, il s'attendrait à ce que j'ai appuyé sur les touches "K<2>JL<espace>F" (selon le placement des touches du bépo) ce qui est la même chose que «bépo<espace>!» (sur un clavier marqé azerty). Je parle bien sur du placement physique des touches.

Sur l'ordi B, le «é» n'existe pas. C'est donc un «e» qui sera envoyé à la place, et ce qui donne (sur un clavier marqué bépo) "KPJL<espace><majuscule><1>", soit "bepo<espace><majuscule><!>" sur un clavier marqué qwerty.

Est ce que je suis clair ? Si tu as une meilleure idée de reformulation, donne la moi, ça m'aiderai à mieux expliquer le concepte.

robin_moussu · 14/3/2014 21:51:03

@XavierC : merci pour l'idée des caractères unicodes, je ne connaissait pas l'astuce. Mais la méthode que j'ai donné au dessus, à défaut d'être parfaite fonctionnera tout le temps.

Dernière modification par robin_moussu (14/3/2014 21:52:04)

rat bière sé · 14/3/2014 22:10:36

Hmm ta méthode est intéresante et a le mérite d'être simple et plus universelle mais elle implique tout de même que tu doives indiquer au clavier quelle est la disposition utilisée par l'OS, et donc elle a aussi des limitations. En plus, selon les OS les dispositions diffèrent légèrement (OSX notamment). Pour avoir au moins les accents en qwerty, il est peut être plus intéressant de basculer la disposition dans un autre qwerty pour obtenir davantage de caractères : us international, uk ou portugais (qui ajoute «» et ç)

Sinon, en intégrant une carte sd ou une clé usb dans le clavier (qui contient donc un hub séparant le stockage du dispositif de saisie) tu peux ajouter l'exe de PKL, des pilotes bépo ou un script setxkbmap que tu lances au début de ta session sur un poste.

lawrent · 15/3/2014 11:00:13

Robin: je suis toujours coincé au stade où un clavier envoie un keycode qui est ensuite interprété par l'OS. S'il y a des autres moyens de faire, je serais intéressé d'en apprendre plus

robin_moussu · 15/3/2014 11:52:21

@lawrent : Ce que j'essayais de dire, c'est que l'OS n'aura aucune idée des touches physique que j'aurais appuyé. Il y aura une couche de compatibilité entre le message que je veux envoyer et la liaison usb. J'aurais donc un switch (matériel ou logiciel) qui me permettra de choisir la disposition source (sur le clavier), et la disposition de destination (celle de l'OS). Les deux étant totalement indépendante.
@XavierC : L'idée est de ne pas avoir à toucher la configuration de l'ordi sur lequel on arrive. Je sais que le qwerty international est bien plus adapté, mais je préfère pouvoir configurer mon clavier avec une simple combinaison de touches, plutôt que d'avoir à chercher dans les sous menus d'un OS inconnu. Je ne toucherai à la configuration de l'OS que si je souhaite accéder à tout les caractères, et à ce moment je modifierai la config de mon clavier en conséquence.
Pour l'idée du stockage sd/usb, c'est effectivement une bonne idée.

jeff · 15/3/2014 14:17:05

Pour TMK, tu peux consulter le message suivant http://forum.bepo.fr/viewtopic.php?pid=8092#p8092.

Par rapport à ce que tu veux faire il me semble que le code "cladeon" également cité dans le post précédent correspond à peu près. En tout cas je l'avais écrit dans un objectif similaire.

robin_moussu · 15/3/2014 15:36:08

@jeff : Concernant TMK, tu m'en avais déjà parlé, mais je n'avais pas pris le temps de m'y pencher plus sérieusement à ce moment la, je m'excuse. C'est effectivement un projet très abouti. Je vais regarder en détail comment il fonctionne, et voir si je peux l'utiliser tel quel, ou alors si j'aurais des modifications à soumettre.

Dernière modification par robin_moussu (15/3/2014 20:05:34)

zanobox · 25/3/2014 23:15:30

Bonjour à tous !
Je m'invite (un peu tardivement) dans la discussion parce que je suis coincé à peu près au même point que robin_moussu (cf. post #11). Et j'ai le nez dans TMK.
Pour l'instant j'envisage d'écrire un keycode total (keycode_multi.h) contenant trois variantes de la même dispo destinées à des machines en azerty, bépo et une dispo perso.
Avec un switch sur le clavier ou une combinaison de touches pour affecter la variable (ou le bit?) qui déterminera à quelle dispo on s'adresse côté hôte.
Je suis en train de faire une table de conversion, mais le keycode de TMK me paraît vraiment limité au qwerty, y compris le comportement de shift.
Je ne vois pas encore très bien comment faire pour l'étendre.
Comment comptes-tu procéder robin_moussu ?

@ rat bière sé : J'aimerais bien en savoir plus sur les possibilités d'utiliser Unicode, est-ce qu'un clavier peut se permettre de balancer de l'unicode brut comme ça à un hôte ? (je veux dire avec l'espoir d'un résultat !) Sans avoir à appliquer un post-traitement au niveau de l'hôte ?

@jeff : je vais retourner voir de plus près cladeon que j'avais trop brièvement survolé. Il faut dire que je suis encore un bleu en C et je commence seulement à piger à peu près comment fonctionne TMK.
Mais par exemple, dans cladeonkbd.cpp quand tu écris

const PROGMEM KeyWord K_SPACE = { 5,44,"","space",0,NULL};
...
const PROGMEM KeyWord K_A_60 = { 1,GRAVE_ACCENT_BITS + KEY_SPACE ,"","`",0,NULL};
...
const PROGMEM KeyWord K_A_7B = { 1,KEY_4 + ALTGR_MASK ,""," {",0,NULL};

est-ce que tu pourrais décrire en deux mots comment tu gères les accents et altgr, s'il te plaît ?

rat bière sé · 26/3/2014 02:37:45

zanobox a écrit :

J'aimerais bien en savoir plus sur les possibilités d'utiliser Unicode, est-ce qu'un clavier peut se permettre de balancer de l'unicode brut comme ça à un hôte ? (je veux dire avec l'espoir d'un résultat !) Sans avoir à appliquer un post-traitement au niveau de l'hôte ?

Bienvenu zanobox (oui je fais les choses à l'envers )

Il faut impérativement un post-traitement : les pilotes pour claviers n'interprètent que les keycodes donc pour balancer de l'unicode en brut il faudrait au minimum réécrire un nouveau protocole d'échange. Les raccourcis pour les caractères Unicode ne sont que des raccourcis et ils sont différents selon l'OS, voire l'environnement de bureau et je doute fort que ces codes soient interprétés dans une interface en ligne de commande (tty unix ou msdos)

Quand on regarde les problèmes soulevés par le piloté bépo ou bépo-azerty avec certains programmes Microsoft ou certains jeux basés sur la SDL, même si un protocole clavier d'envoi de donnée unicode brut se crée et qu'il est intégré à tous les OS, il ne serait pas pour autant universel. Le problème des Magic System Request keys du noyau Linux imposera lui aussi de pouvoir retourner à un mode "legacy" dans lequel le clavier reprend son comportement traditionnel et envoie des keycodes.

jeff · 26/3/2014 22:47:14

Bonjour

zanobox :

J'utilise l'environnement arduino pour programmer le teensy. Quand on paramètre l'environnement pour utiliser le teensy comme clavier ("outil/Board teensy" et "outil/USB Type keyboard") le préprocesseur C utilise le fichier «.../arduino-1.0.1-windows\arduino-1.0.1\hardware\teensy\cores\teensy/keylayouts.h» qui contient attribue un nom compréhensible aux codes binaires que le clavier doit transmettre à l'ordinateur :

#define MODIFIERKEY_CTRL ( 0x01 | 0x8000 )
#define MODIFIERKEY_SHIFT ( 0x02 | 0x8000 )
#define MODIFIERKEY_ALT ( 0x04 | 0x8000 )
#define MODIFIERKEY_GUI ( 0x08 | 0x8000 )
#define MODIFIERKEY_LEFT_CTRL ( 0x01 | 0x8000 )

et

#define KEY_A ( 4 | 0x4000 )
#define KEY_B ( 5 | 0x4000 )
#define KEY_C ( 6 | 0x4000 )
#define KEY_D ( 7 | 0x4000 )
#define KEY_E ( 8 | 0x4000 )

Dès que le préprocesseur voit le texte KEY_A dans le code du programme, il le remplace par 4.

Ce fichier contient également des codes fonction du paramétrage de langue
(outil/keyboard layout french)

Par exemple pour le français :

#define ASCII_41 KEY_Q + SHIFT_MASK // 65 A
#define ASCII_42 KEY_B + SHIFT_MASK // 66 B
#define ASCII_43 KEY_C + SHIFT_MASK // 67 C
#define ASCII_44 KEY_D + SHIFT_MASK // 68 D

On voit bien qu'un clavier Azerty envoi le code équivalent à un Q quand on appuie sur A.

Autant le lien nom de touche-code binaire m'intéressait pour que le programme soit lisible, autant la description du clavier français me paraissait limité.
C'est donc une partie que j'ai un peu étendue.

TMK ne m'a pas l'air particulièrement limité au QWERTY, il «suffit» (pas essayé) de bien renseigner le fichier keymapXX.h avec des codes adaptés à ce que tu veux.

Pour faire un peu violent, à la place de

static const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
/* 0: qwerty */
KEYMAP_ISO(\
A, B, C, D, E, F.....

tu fais un truc du genre

static const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
/* 0: monmien1 */
KEYMAP_ISO(\
TOTO0, TOTO1, TOTO2, TOTO3, TOTO4, TOTO5.....\

En ayant défini préalablement TOTOX comme présenté dans common/keycode.h (voir la doc https://github.com/tmk/tmk_keyboard/blo … keymap.md). Je n'ai pas retrouvé le fichier où étaient définis les codes KC_A, il faut se promener dans les sources.

En espérant que ça réponde un peu à la question.

robin_moussu · 27/3/2014 00:47:25

Merci pour les infos, c'était également quelque-chose qui me manquait.
Je manque de temps en ce moment, donc j'ai mis mon clavier en veille.

zanobox · 29/3/2014 14:06:38

Merci pour vos réponses et la bienvenue !
(désolé pour le temps de réponse, j'ai été déconnecté quelques jours)
Moi aussi je fais les choses à l'envers. En fait, j'allais ouvrir un nouveau topic où je me présentais et tout et tout quand je suis tombé sur ce fil, et j'y ai répondu directement.
Je ne vais pas tarder à faire une petite mise à jour de ma page utilisateur sur le wiki pour montrer où j'en suis (et servir, j'éspère, à d'autres débutants motivés).

Pour ce qui concerne l'unicode je me disais bien que si ça avait été si facile ça se serait déjà bien répandu...
En tout cas il est possible d'afficher de l'UTF8 en console tty à condition que la locale définie soit adequate ainsi que la fonte. Ça ne fonctionne donc pas «out of the box» sur n'importe quelle plateforme gnu/linux mais en France par exemple, on aura pas mal de chances de tomber sur une locale telle que 'fr_FR.UTF-8'. En théorie, la police de console par défaut devrait y être adaptée, sinon je pense qu'il faut les droits de root pour en changer.
Je ne sais pas comment fonctionnent les environnements de bureau (je n'en utilise pas). Je n'utilise que de petits gestionnaires de fenêtres (awesome, openbox, ratpoison) qui doivent se reposer, en ce qui concerne l'unicode, directement sur le serveur graphique X, lequel prend vraisemblablement en compte la locale de tout le système. Ça me surprendrait que les gros environnements de bureau procèdent autrement, mais ce ne sont que des hypothèses, ça mérite approfondissement. J'irai voir du côté de freedesktop.org un de ces jours.
Quoiqu'il en soit, il faudra effectivement sans doute écrire un pilote pour disposer de tout l'unicode (peut-être un module pour le kernel ?), je remets donc ça a plus tard, mais ne m'avoue pas vaincu !

En attendant, si vous avez ou trouvez des exemples d'implémentation (y compris pour Windows et MacOS), n'hésitez pas à nous les communiquer (je parle aussi pour robin_moussu que ça intéresse sûrement) !

@ jeff : en effet, c'est bien common/keycode.h que je pensais étendre. Mais ce qui m'a fait penser qu'on était limité au qwerty, c'est le comportement de shift.
Apparemment, les keycodes sont définis dans ce document : « www . usb . org/developers/devclass_docs/Hut1_11.pdf » (pp53-60), repris dans TMK/doc/keycode.txt et transposé dans common/keycode.h. Et il semble bien que le comportement de shift y soit inclus (et basé sur le qwerty).
Mais il suffit peut-être simplement de définir les niveaux Shift, AltGr et Shift+AltGr comme des couches à part entière pour écraser ce comportement par défaut. Ce qui, compte tenu du maximum de 32 couches, permettrait de définir par exemple 8 couches de 4 niveaux chacune. C'est là que j'aimerais ajouter des alphabets supplémentaires (cyrillique, grec, arabe, phonétique international, par exemple).

Je me demande quel est le nombre maximum de symboles qu'on peut définir pour chaque couche, parce qu'il semble qu'on puisse définir des virtual keycodes en plus de la liste de base.
Sinon, on a environ 220 keycodes disponibles, keypad et modificateurs inclus. Mais où sont les accents et touches mortes ? Et AltGr ?

Je vais continuer d'étudier les sources, et me pencher sur l'API d'arduino, je pense que le code de cladeon va soudain s'éclaircir et ouvrir des perspectives ! (D'ailleurs, en passant, la lecture de cladeonsnd.cpp m'a donné l'idée et l'envie d'essayer de faire une couche MIDI, pour jouer de la musique ! Mais on verra ça encore un peu plus tard !).

Bref il reste pas mal de boulot, de débroussaillage toujours, mais je vais bientôt pouvoir commencer à faire des tests sur un demi-clavier, ça avancera certainement un tout petit peu plus vite.
Merci pour vos indications, je vous tiendrai au courant de mes avancées et revers !

zorglups · 13/5/2014 15:47:40

Décidément, ce forum regorge de gens qui se posent les même questions que moi ;-)

Pour le firmware de mon ErgoDox, je me suis embarqué avec le TMK qui offre notamment les macros.
Je vais l'utiliser pour créer un ou deux layers (grosso modo navigation et pavé numérique).

Mon boulot me donne les contraintes suivantes:
- Mon clavier est connecté à un laptop Win7 (64bits).
- Je travaille régulièrement dans un terminal (putty ou cmd.exe).
- Je travaille régulièrement avec des images virtuelles Virtual Box et VMWare.
- Je me connecte souvent sur d'autres systèmes (souvent configurés en qwerty) au travers de RDP/VMWare/VNC/..., parfois en cascade (eg: un RDP dans un VNC tournant dans une image VMWare Win7 sur laquelle je me connecte avec un VMWare vSphere Client). Si si, je vous jure. (pour info, certaines couches (par exemple RDP) tiennent compte de MA configuration clavier et pas de la configuration clavier de la machine hôte (enfin... la plupart du temps).

Pour le moment, je suis resté sur un brave azerty et au pire, je me retrouve parfois à taper en qwerty.

Mon clavier actuel est un TEK blank. Le plus drôle est de taper à l'aveugle un mot de passe dicté par un client au téléphone avec un collègue debout en train derrière moi :-s

Je ne suis pas encore passé au Bépo pour ne pas empirer la situation.
Mon souhait serait de mettre mon laptop en qwerty étendu et faire en sorte que mon Ergodox lui envoies "ce qu'il faut" et que je puisse taper dessus en bépo.

Bref... un de plus qui va suivre cette discussion.

Et dire que j'aurais pu faire comme tout le monde ;-)

Forum bépo

#1 12/3/2014 21:58:13

Création d'un clavier - épopé logicielle !

#2 12/3/2014 23:14:12

Re : Création d'un clavier - épopé logicielle !

#3 13/3/2014 05:52:06

Re : Création d'un clavier - épopé logicielle !

#4 13/3/2014 14:44:44

Re : Création d'un clavier - épopé logicielle !

#5 13/3/2014 22:26:48

Re : Création d'un clavier - épopé logicielle !

#6 14/3/2014 09:37:38

Re : Création d'un clavier - épopé logicielle !

#7 14/3/2014 21:40:10

Re : Création d'un clavier - épopé logicielle !

#8 14/3/2014 21:49:58

Re : Création d'un clavier - épopé logicielle !

#9 14/3/2014 21:51:03

Re : Création d'un clavier - épopé logicielle !

#10 14/3/2014 22:10:36

Re : Création d'un clavier - épopé logicielle !

#11 15/3/2014 11:00:13

Re : Création d'un clavier - épopé logicielle !

#12 15/3/2014 11:52:21

Re : Création d'un clavier - épopé logicielle !

#13 15/3/2014 14:17:05

Re : Création d'un clavier - épopé logicielle !

#14 15/3/2014 15:36:08

Re : Création d'un clavier - épopé logicielle !

#15 25/3/2014 23:15:30

Re : Création d'un clavier - épopé logicielle !

#16 26/3/2014 02:37:45

Re : Création d'un clavier - épopé logicielle !

#17 26/3/2014 22:47:14

Re : Création d'un clavier - épopé logicielle !

#18 27/3/2014 00:47:25

Re : Création d'un clavier - épopé logicielle !

#19 29/3/2014 14:06:38

Re : Création d'un clavier - épopé logicielle !

#20 13/5/2014 15:47:40

Re : Création d'un clavier - épopé logicielle !

Pied de page des forums