Recyclez votre vieille souris en capteur

C'est qu'il y a plein de choses sympathiques et bricolables dans une souris ! Surtout les plus anciennes, avant l'apparition des capteurs optiques et les liaisons Bluetooth. D'abord elles fournissent un câble USB, pour éviter de s'embêter à faire son câble soi-même, par exemple pour récupérer un peu de courant qui alimentera un petit circuit en 5V. Il est ironiquement moins cher d'acheter une souris « premier prix » et de lui couper la queue, que d'acheter du fil et des connecteurs à l’unité, en espérant que le montage soit fiable. Avec un peu de chance, le fil sera même branché dans la souris par un connecteur, que l'on pourra aussi récupérer. Et sur le cadavre de la souris restent encore des composants intéressants, à commencer par des boutons poussoirs (souvent d'assez bonne qualité). Il y a aussi des émetteurs et capteurs infrarouges avec leurs roues codeuses, comme sur la figure 1.

1. L'aspect matériel

Mais l'ensemble du circuit peut aussi être utilisé à d'autres fins que « dispositif de pointage », car si on regarde bien, il s'agit bêtement, pour ce qui nous concerne ici, d'un périphérique USB fournissant trois entrées « tout ou rien ». Cela permet d'éviter de dégainer votre plateforme embarquée préférée et vous pourrez ainsi développer et contrôler tout le montage confortablement sur votre PC. Sans avoir à développer le moindre pilote de périphérique, et garanti pour fonctionner partout.

Au passage, je ne peux m'empêcher de noter l'ironie de la situation actuelle de l'informatique, qui ne fait qu'empirer. Malgré les performances ahurissantes des ordinateurs disponibles aujourd'hui au grand public, leurs capacités de communications ont touché le fond. Un ordinateur actuel est habituellement un laptop doté d'un port Ethernet, de quelques ports USB (si vous avez fait attention en l'achetant) et parfois même d'une sortie vidéo complémentaire. En rognant sur tous les coûts, donc en réduisant les options, les laptops « grand public » d'aujourd'hui sont réduits à des tablettes à clavier...

L'industrie a misé sur le « tout passe par Wifi, Bluetooth ou USB » au détriment de la simplicité matérielle et logicielle. En effet, le « super hack » de cet article aurait juste requis un trombone dans la prise DB25 du port d'imprimante parallèle, sur un PC d'il y a 20 ans. À cette époque, le feu magazine Électronique Pratique regorgeait de montages utilisant cette interface ultra-bricolable et très aisée à programmer. Mais on doit vivre avec son temps alors j'espère que Saint MacGyver me pardonnera pour cette fois. Regardons donc en quoi consiste notre « trombone 2.0 ».

Du côté matériel, il n'y a pas beaucoup à dire, et c'est bon signe. Les boutons sont habituellement mécaniques, les contacts sont du type « normalement ouverts » et leur nombre varie d'un modèle à l'autre. Il est important de vérifier soi-même chaque caractéristique électrique afin d'assurer la compatibilité de votre montage (au risque de rendre le périphérique vraiment inutile pour de bon). Donc, comme l'énonce la loi fondamentale de l'électronique : « ne supposez rien, mesurez ! ».

Une des surprises que vous pourriez rencontrer est que la plupart des modèles essaient de conserver l'énergie (surtout pour les modèles sur batterie) et restent en veille la plupart du temps. Ainsi, la souris interrogera les boutons typiquement quelques centaines de fois par seconde, durant quelques microsecondes. Si vous cherchez à mesurer la tension aux bornes de l'interrupteur, vous ne trouverez qu'une faible valeur avec votre voltmètre. Ne paniquez pas et sortez l'oscilloscope (ou regardez la figure 2 si vous n'en avez pas un).

En conséquence, ce système n'est pas fait pour capturer des évènements à haute vitesse. Donc, contrairement à un bricolage d’antan sur le port d'imprimante parallèle, notre « trombone 2.0 » si sophistiqué sera en fait lent. Ainsi, ne vous attendez pas à une bonne fiabilité au-delà de quelques dizaines d’impulsions par seconde sur le signal d'entrée. C'est toutefois moins cher et plus facile que de sortir un Arduino ou un Pi pour lire juste deux ou trois boutons, et vous pourrez commencer à bricoler un prototype pour votre projet de domotique ou de robotique à moindres frais et avec peu de développement.

Cette lecture pulsée complique votre montage si vous souhaitez fermer le contact par un autre moyen qu'un interrupteur mécanique. L'idéal est d'utiliser un MOSFET [1] du genre BS170, mais vous devrez vérifier et valider les polarités et les tensions. Il est même possible que certains boutons ne puissent pas être contrôlés électroniquement à cause d'optimisations visant à faire des économies. Par exemple, sur le modèle que j'ai bricolé, on voit sur la figure 4 que le bouton gauche n'est pas connecté au 0V, contrairement aux deux autres. Il ne sera donc pas possible de mettre un MOSFET branché au 0V pour le déclencher. Il restera quand même 2 boutons... Puisque mon projet utilise seulement des contacts mécaniques isolés les uns des autres, je ne m'en préoccupe pas ici.

Après avoir effectué quelques tests au multimètre, pour vérifier les tensions et les résistances aux points stratégiques, on y soude des fils et on valide le fonctionnement général avec un ordinateur. Mais un nouveau problème très bête apparaît alors.

2. L'aspect logiciel

Eh oui ! Il fallait s'en douter : quand on appuie sur un bouton de la souris, l'ordinateur réagit et « clique ». Après tout, c'est à cela que sert une souris, non ? Nous allons devoir désactiver ce comportement sans pour autant désinstaller la souris. Il faut juste dire à l'ordinateur de ne pas en tenir compte pour l'interface graphique.

2.1 Détecter la souris

D'abord, voyons comment notre Linux détecte la souris. J'utilise Fedora, mais ces manipulations devraient fonctionner sur la plupart des autres systèmes basés sur Linux.

Si vous venez de brancher la souris juste avant d'exécuter la commande dmesg, les lignes ci-dessus devraient s'afficher en dernier. Sans ambiguïté, il s'agit bien là de notre souris sacrifiée. Le fabricant et le modèle correspondent bien, mais les informations associées sont totalement absconses. Il faudra les trouver autre part, par exemple avec la commande suivante :

Avec cette commande (spécifique à l'environnement Xorg), nous constatons à la dernière ligne que notre suppliciée a reçu le numéro 17. On avance...

Une autre source d'informations se trouve dans un des fichiers virtuels du répertoire /proc :

Nous y retrouvons la liste de tous les périphériques d'entrée, alors allons fouiller un peu plus :

Encore plein d'informations absconses, mais au milieu desquelles nous trouvons la ligne Handlers qui indique mouse3 event17. Cela correspond à des noms de fichiers virtuels situés dans le répertoire /dev/input :

Il y a 20 ans, la souris était juste de type PS2 et il existait un simple fichier appelé /dev/mouse ou /dev/psaux dans lequel on pouvait lire les données des mouvements. Mais aujourd'hui, tout passe par l'USB et plusieurs dispositifs de pointage peuvent coexister. Dans mon cas, j'utilise simultanément le trackpad intégré, la tablette graphique externe et la souris optique sacrifiée.

Tous ces périphériques sont présentés individuellement avec un fichier de nom /dev/input/mouseX (où X est un numéro de périphérique), et concentrés dans /dev/input/mice qui fournira dans un seul fichier toutes les données de tous les dispositifs de pointage.

Notre souris bricolée apparaît sous le nom /dev/input/mouse3, ce qui est facile à détecter, car je viens de la brancher et la date de ce fichier est la plus récente. L'étau est maintenant bien resserré et un dernier test confirmera cette attribution.

2.2 Lire la souris sans logiciel spécial

Des outils de base installés par défaut sur la plupart des distributions GNU/Linux permettent d'inspecter le flux de données provenant d'un périphérique de type « bloc », comme ceux du répertoire /dev. La première chose est d'obtenir le droit de lire le fichier en question, et le plus simple est de se connecter en tant qu'utilisateur root. su ou sudo bash fera l'affaire.

Ensuite, il suffit de lancer un petit utilitaire dont on entend rarement parler, mais qui permet, contrairement à hexdump ou hexedit, d'afficher les octets un à un, à mesure qu'ils arrivent. Ce programme s'appelle od et sa page de manuel montre l'étendue des formats qu'il peut afficher. Nous allons le lancer en désactivant l'affichage des numéros de ligne (option -An), pour afficher uniquement un octet (option -w1) au format hexadécimal (option -t x1).

Si on déplace la souris ou si un bouton est appuyé, le terminal crache une liste de nombres... Par exemple, en bougeant le doigt devant le capteur optique :

Cela ressemble à de la bouillie, mais tout devient clair quand on se contente d'appuyer et relâcher le bouton gauche :

Et si on appuie et relâche le bouton de droite :

On constate que le fichier renvoie des paquets de 3 octets, dont le premier contient un bit toujours à 1 pour marquer le début du paquet. C'est ce fameux 8 qui revient tout le temps. Les 3 bits suivants indiquent l'état de chaque bouton et sur les 3 octets, il est facile d'extraire les 3 bits désirés. Ainsi, le 8 se transforme en 9, A ou C selon le bouton appuyé, et toutes les combinaisons possibles si plusieurs boutons sont appuyés simultanément.

Les 20 bits restants correspondent aux mouvements sur les axes X et Y. Ils ne nous intéressent pas, car il n'y aura aucun mouvement et on lira toujours 0. Cela garantit qu'on détectera toujours le bon octet contenant l'état des boutons, avec son bit toujours à 1. Un algorithme se dessine alors : il suffit de lire un octet, voir si le bit 3 est à 1, puis de lire l'état :-)

2.3 Configurer Xorg

Mais voilà, lorsqu'on appuie sur un bouton, l'interface graphique réagit toujours. Je vous laisse imaginer les conséquences que cela peut entraîner en pratique, lorsque le montage fonctionnera. Alors non, je ne vais pas quitter le mode graphique et désactiver gpm dans la console, j'ai pris mes habitudes maintenant. Je vais choisir la solution intelligente qui consiste à lire la documentation et chercher sur Internet !

Et en effet, la solution est relativement simple et élégante, bien qu'elle ne soit ni évidente ni facile quand on n'a pas l'habitude de fouiller dans le système. Mais les informations sont faciles d’accès ! L'endroit-clé est le fichier de configuration de l'interface graphique Xorg (sur laquelle tournent vos gestionnaires de fenêtres comme GNOME, KDE, Xfce, etc.). La plupart des informations sont en anglais, mais pas trop difficiles à comprendre. Par exemple, j'ai trouvé les informations les plus utiles à l'adresse https://fedoraproject.org/wiki/Input_device_configuration#Blacklisting_a_device.

Donc l'option Ignore permet de désactiver un périphérique sans toucher au noyau, ce qui permet à la souris de continuer de fonctionner sans affecter l'affichage. Le tout est d'indiquer correctement quel est ce périphérique, et la page nous donne les informations nécessaires :

Avec ces informations (et quelques autres glanées ici et là), il est facile de créer une règle de configuration qui désactive notre souris et uniquement celle-ci :

On retrouve l'option Ignore, le type Pointer ainsi que le nom du produit et du fabricant. Je n'ai pas spécifié un chemin de périphérique particulier, car il peut changer après un redémarrage de l'ordinateur.

Il ne reste plus qu'à écrire cela dans un fichier, au bon endroit, avec les bons droits (appartenant à root, mais lisible par tout le monde). La documentation de Fedora spécifie que

Les utilisateurs sont encouragés à mettre leurs fichiers de configuration personnels dans /etc/X11/xorg.conf

Cependant, ce fichier a disparu dans les OS récents, et il a été remplacé (pour Fedora) par le répertoire /etc/X11/xorg.conf.d. J'ai donc créé un nouveau fichier appelé /etc/X11/xorg.conf.d/01-no_optical_mouse.conf. Maintenant, il faut fermer le serveur X pour qu'il accepte la nouvelle configuration. Refusant de sacrifier mon uptime, je ferme juste la session X.

Au redémarrage... la souris Logitech ne bouge plus ! Mais tout le reste est encore fonctionnel, comme prévu, donc.

3. Exemple d'utilisation pratique

Nous avons fait tout cela pour lire des boutons. Ce n'est pas très compliqué, mais il faut bien sauter le pas... Dans mon cas, j'ai choisi d'utiliser le langage C, bien que d'autres préfèreront Python.

Le fichier suivant propose une fonction pour ouvrir le fichier d'une souris particulière, puis une autre fonction pour interpréter le flux de données, par blocs de 3 octets. J'emploie une technique de lecture non bloquante, ce qui permet de continuer le déroulement du programme même lorsque la souris ne détecte aucune activité. Ainsi, le reste du programme peut scanner la souris à intervalle régulier, et réaliser du travail utile (ou pas) entretemps. Ici, on fait simplement tourner un caractère à l'écran (avec une syntaxe de ha><Or)...

Une fois le fichier téléchargé (vous n'allez quand même pas le retaper à la main ?), une petite commande compile le programme en activant la fonction main(), qui fournit un simple programme d'exemple :

Si vous n'êtes pas encore en root, c'est le moment de vous connecter, sinon cela donne :

Donc retournons à la racine :-)

Par défaut, le fichier à ouvrir est /dev/input/mice, mais on peut spécifier un autre fichier en argument sur la ligne de commandes :

ou bien, en l’absence d’argument, avec une variable d'environnement :

Et maintenant, il ne vous reste plus qu'à connecter les boutons à votre propre montage !

Conclusion

J'espère que ce petit tour d'horizon vous aura fait découvrir quelques subtilités et astuces très pratiques pour vos projets. Une bête souris peut résoudre des problèmes compliqués et nous n'en avons vu que la partie la plus simple, celle des boutons. Cela me suffit pour tester le fonctionnement de relais russes dans des conditions contrôlées [2] avec le petit montage de la figure 5, mais j'imagine qu'il existe d'innombrables applications, ne serait-ce que parce que le coût est minimal et la technologie reste très basique.

Nous n'avons même pas abordé le détournement des autres capteurs, comme les disques encodeurs, qui peuvent servir de compte-tours ou de fréquencemètre rudimentaire. Je laisse cette partie à Laura Bécognée, qui en aura besoin pour son projet de banc de test de moteurs électriques.

Je me suis aussi demandé comment on pourrait modifier le capteur optique pour faire de la détection de mouvements à quelques dizaines de centimètres, au lieu de millimètres. Selon les informations disponibles, les puces modernes contiennent une sorte de mini-caméra simplifiée. Si je résous ce défi que je m'étais posé il y a plus de dix ans, je pourrai bricoler des interfaces haptiques très économiques ! J'ai buté jusqu’à maintenant sur l'optique avant de choisir d'autres solutions d’autres types, mais qui sait si un de nos lecteurs y arrivera ?

Références

[1] Guidon Y., « Nos amis les MOSFET » Hackable n°12, mai 2016, pp70-83.
Article en Creative Commons consultable à https://connect.ed-diamond.com/Hackable/HK-012/Nos-amis-les-MOSFET

[2] Le projet du testeur de relais fournit aussi le code source ci-dessus, à https://hackaday.io/project/16961-retest-yg