Recyclez votre vieille souris en capteur

Magazine
Marque
Hackable
Numéro
28
Mois de parution
janvier 2019
Spécialité(s)


Résumé
Lorsque vous bricolez, le premier défi est de trouver la meilleure approche avec le matériel adéquat, tout en minimisant le coût matériel et le développement logiciel. Si vous avez juste besoin de lire l'état de quelques interrupteurs, sans contrainte de temps réel forte, la solution se trouve probablement dans une brocante à un sou, ou dans votre carton d'antiquités qui ont échappé à la benne depuis 20 ans. En effet, quoi de plus commun, économique, simple et pratique qu'une bonne vieille souris à fil ?

Body

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.

_M7_6115_4416

Fig. 1 : La souris mise à nu, hors de sa carapace, libère la mécanique de la molette.

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).

pic_22_3

Fig. 2 : Ne vous étonnez pas que la tension aux bornes d'un interrupteur soit un peu bizarre. Voici la forme de la tension capturée par mon oscilloscope, montrant des pulsations à différentes fréquences. C'est un peu bizarre pour un simple switch, et pourtant ça fonctionne.

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.

_M7_6121_3684

Fig. 3 : Le circuit imprimé, côté recto, montre tous les composants.

_M7_6125_4220

Fig. 4 : Côté verso, nous voyons les pistes qui connectent les composants. Nous repérons les points de soudure stratégiques, sur lesquels nous souderons des fils supplémentaires qui permettront de simuler l'appui sur les boutons.

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.

Je précise que toute la partie logicielle cible un OS de la famille Linux. Si vous utilisez Fedora, Gentoo, Ubuntu ou une autre distribution sur votre Raspberry Pi ou votre ordinateur, aucun souci. Je suppose qu'il faudra des adaptations nombreuses sous MacOS, et je n'ose même pas considérer réfléchir à ce que ce serait sous Windows. J'espère que cet article vous donnera envie d'essayer Linux, en voyant la facilité à explorer le système et développer des petits programmes sans devoir subir tout un environnement propriétaire ou traquer des informations réservées aux développeurs enregistrés. Linux a été fait par des hackeurs pour des hackeurs, et cet article en est une jolie illustration parmi tant d'autres !

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.

$ dmesg
[1015128.994372] usb 2-1.3: new low-speed USB device number 86 using ehci-pci
[1015129.078062] usb 2-1.3: New USB device found, idVendor=046d, idProduct=c077
[1015129.078069] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[1015129.078073] usb 2-1.3: Product: USB Optical Mouse
[1015129.078077] usb 2-1.3: Manufacturer: Logitech
[1015129.083902] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/0003:046D:C077.0007/input/input62
[1015129.084707] hid-generic 0003:046D:C077.0007: input,hidraw1: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1d.0-1.3/input0

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 :

$ xinput list

⎡Virtual core pointer id=2 [master pointer (3)]

⎜ ↳Virtual core XTEST pointer id=4 [slave pointer (2)]

⎜ ↳PS/2 Generic Mouse id=12 [slave pointer (2)]

⎜ ↳SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)]

⎜ ↳Wacom Intuos 6x8 Pen stylus id=9 [slave pointer (2)]

⎜ ↳Wacom Intuos 6x8 Pen eraser id=15 [slave pointer (2)]

⎜ ↳Wacom Intuos 6x8 Pen cursor id=16 [slave pointer (2)]

⎜ ↳ Logitech USB Optical Mouse id=17 [slave pointer (2)]

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 :

$ cat /proc/bus/input/devices | grep "Name"

N: Name="Sleep Button"

N: Name="Lid Switch"

N: Name="Power Button"

N: Name="AT Translated Set 2 keyboard"

N: Name="PS/2 Generic Mouse"

N: Name="Video Bus"

N: Name="SynPS/2 Synaptics TouchPad"

N: Name="ST LIS3LV02DL Accelerometer"

N: Name="HP HD Webcam [Fixed]: HP HD Web"

N: Name="HP WMI hotkeys"

N: Name="HDA Intel PCH Mic"

N: Name="HDA Intel PCH Line"

N: Name="HDA Intel PCH Dock Line Out"

N: Name="HDA Intel PCH Headphone"

N: Name="HDA Intel PCH HDMI/DP,pcm=3"

N: Name="HDA Intel PCH HDMI/DP,pcm=7"

N: Name="Wacom Intuos 6x8 Pen"

N: Name="Logitech USB Optical Mouse"

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

$ less /proc/bus/input/devices

...

I: Bus=0003 Vendor=046d Product=c077 Version=0111

N: Name="Logitech USB Optical Mouse"

P: Phys=usb-0000:00:1d.0-1.3/input0

S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/0003:046D:C077.0006/input/input61

U: Uniq=

H: Handlers=mouse3 event17

B: PROP=0

B: EV=17

B: KEY=ff0000 0 0 0 0

B: REL=103

B: MSC=10

...

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 :

[yg@localhost C]$ l /dev/input/

drwxr-xr-x. 4 root root 560 19 nov. 02:57 .

drwxr-xr-x. 21 root root 4160 19 nov. 02:57 ..

drwxr-xr-x. 2 root root 140 19 nov. 02:57 by-id

drwxr-xr-x. 2 root root 160 19 nov. 02:57 by-path

crw-rw----. 1 root input 13, 64 30 oct. 03:35 event0

crw-rw----. 1 root input 13, 65 30 oct. 03:35 event1

crw-rw----. 1 root input 13, 74 30 oct. 03:35 event10

crw-rw----. 1 root input 13, 75 30 oct. 03:35 event11

crw-rw----. 1 root input 13, 76 30 oct. 03:35 event12

crw-rw----. 1 root input 13, 77 30 oct. 03:35 event13

crw-rw----. 1 root input 13, 78 30 oct. 03:35 event14

crw-rw----. 1 root input 13, 79 30 oct. 03:35 event15

crw-rw----. 1 root input 13, 80 30 oct. 03:35 event16

crw-rw----. 1 root input 13, 81 19 nov. 02:57 event17

crw-rw----. 1 root input 13, 66 30 oct. 03:35 event2

crw-rw----. 1 root input 13, 67 30 oct. 03:35 event3

crw-rw----. 1 root input 13, 68 30 oct. 03:35 event4

crw-rw----. 1 root input 13, 69 17 nov. 18:11 event5

crw-rw----. 1 root input 13, 70 30 oct. 03:35 event6

crw-rw----. 1 root input 13, 71 30 oct. 03:35 event7

crw-rw----. 1 root input 13, 72 30 oct. 03:35 event8

crw-rw----. 1 root input 13, 73 30 oct. 03:35 event9

crw-rw-r--. 1 root input 13, 0 30 oct. 03:35 js0

crw-rw----. 1 root input 13, 63 30 oct. 03:35 mice

crw-rw----. 1 root input 13, 32 30 oct. 03:35 mouse0

crw-rw----. 1 root input 13, 33 17 nov. 18:11 mouse1

crw-rw----. 1 root input 13, 34 30 oct. 03:35 mouse2

crw-rw----. 1 root input 13, 35 19 nov. 02:57 mouse3

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).

sudo od -An -v -w1 -t x1 /dev/input/mouse3

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 :

28

0d

fc

28

0d

fc

28

0b

fe

28

02

ff

...

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

09 <--- appui

00

00

08 <--- relâchement

00

00

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

0a <--- appui

00

00

08 <--- relâchement

00

00

C'est similaire pour le bouton du milieu :

0c <--- appui

00

00

08 <--- relâchement

00

00

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.

masque binaire du premier octet :

bouton gauche : bit 0

bouton droite : bit 1

bouton milieu : bit 2

début de paquet : bit 3 toujours à 1

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.

Bloquer un périphérique :

Certains périphériques peuvent être détectés et utilisés par le serveur X alors qu'ils ne le devraient pas. Ces périphériques peuvent être configurés pour être ignorés ainsi :)

Section "InputClass"
 Identifier "no need for accelerometers in X"
 Option "Ignore" "on"

EndSection

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 :

Les options de correspondance spécifient quels périphériques sont concernés par une section.

Pour sélectionner un périphérique, toutes les options de correspondance doivent être validées.

Les critères suivants sont supportés :


MatchIsPointer, MatchIsKeyboard, MatchIsTouchpad, MatchIsTouchscreen, MatchIsJoystick : cela sélectionne un groupe ou un type de périphériques.

MatchProduct "foo|bar" : sélectionne tout périphérique dont le nom de produit contient "foo" ou "bar".

MatchVendor "foo|bar|baz" : sélectionne tout périphérique dont le nom du fabricant contient soit "foo", "bar" ou "baz".

MatchDevicePath "/dev/input/event*" : sélectionne tout périphérique donc le chemin correspond.

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 :

Section "InputClass"

Identifier "Desactive souris Logitech"

MatchIsPointer "on"

Driver "evdev"

MatchProduct "USB Optical Mouse"

MatchVendor "Logitech"

Option "Ignore" "true"

EndSection

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)...

/*

boutons.c

(c) 20181118 Yann Guidon <whygee@f-cpu.org>

Lit l'état des boutons d'une souris, à partir

d'un périphérique tel que /dev/input/mice

gcc -Wall boutons.c -o boutons -DTEST_BOUTONS

*/


#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <stdlib.h>

#include <stdio.h>

#include <errno.h>

#include <unistd.h>


// quelque variables globales :

int mouse_fd, buttons;


void open_mouse(char *path) {

buttons=0;


// pour se faciliter la vie, on peut aussi

// configurer le nom de la souris dans une

// variable d'environnement :

if (!path) {

path=getenv("MOUSE_DEV");

if ((path==NULL) || (*path==0))

path="/dev/input/mice";

}

printf("ouverture de la souris à %s \n", path);

mouse_fd = open(path, O_RDONLY | O_NONBLOCK);

// l'option O_NONBLOCK permet de lire un bloc

// de taille nulle quand aucune donnée n'est

// disponible, au lieu de bloquer tout le programme.

}


// Met à jour la variable globale "buttons",

// retourne un champ de bits correspondant aux

// boutons dont l'état a changé.

int get_buttons() {

char buff[3];

int i, b=buttons, x;


while(1) {

i=read(mouse_fd, buff, 3);


if (i == -1) {

if ((errno == EAGAIN)

|| (errno == EWOULDBLOCK))
// dans ce cas, il n’y a rien à lire,

break;

perror ("erreur de lecture de la souris : ");

return 0;

}


if (i != 3) {

if (i != 0)

printf("Tiens, pas assez d'octets à lire ? %d\n", i);

break;

}


b = buff[0];

if ((b & 8) == 0) {

printf("souris : Marque de synchronisation absente\n");

return 0;

}


} // Continuer de lire jusqu'à


b &= 7; // garde juste les 3 bits des boutons

x = b^buttons; // calcule la différence

buttons = b; // sauve la dernière valeur lue

return x; // renvoie la différence

}

// Un programme de test simple

#ifdef TEST_BOUTONS

int main(int argc, char **argv) {

int i=0;


char *path=NULL;

if (argc > 1)

path=argv[1];

open_mouse(path);

if (mouse_fd == -1) {

perror("échec d'ouverture du périphérique souris");

return 0;

}


while (1) {

usleep(40*1000); // attente de 40ms

if (get_buttons())

printf("gauche=%d milieu=%d droit=%d\n",

buttons&1, (buttons&4)>>2, (buttons&2)>>1);

// spinner en une seule ligne :

printf("%c \r", "-\\|/"[i++ & 3]);

fflush(NULL);

}

}

#endif

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 :

[yg@localhost]$ gcc -Wall boutons.c -o boutons -DTEST_BOUTONS

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

[yg@localhost C]$ ./boutons

ouverture de la souris à /dev/input/mice

échec d'ouverture du périphérique souris: Permission denied

Donc retournons à la racine :-)

[root@localhost]# ./boutons

ouverture de la souris à /dev/input/mice

gauche=0 milieu=0 droit=1

gauche=0 milieu=0 droit=0

gauche=1 milieu=0 droit=0

...

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 :

[root@localhost C]# ./boutons /dev/input/mouse3

ouverture de la souris à /dev/input/mouse3

...

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

[root@localhost C]# export MOUSE_DEV=/dev/input/mouse3

[root@localhost C]# ./boutons

ouverture de la souris à /dev/input/mouse3

gauche=0 milieu=0 droit=1

gauche=0 milieu=0 droit=0

gauche=0 milieu=1 droit=0

gauche=0 milieu=0 droit=0

gauche=1 milieu=0 droit=0

...

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

20181112_054727_1763

Fig. 5 : Le cadavre de souris est bouturé au Frankentesteur de relais russes.

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




Article rédigé par

Par le(s) même(s) auteur(s)

Une (autre) pile matérielle pour le modèle bipilaire

Magazine
Marque
GNU/Linux Magazine
Numéro
271
Mois de parution
septembre 2024
Spécialité(s)
Résumé

Dans les épisodes précédents, le « Single Stack Syndrome » a été décrit et poussé à son paroxysme en essayant (en vain) d’apprendre de nouveaux tours à GCC. Ensuite, après le « quoi », nous avons exploré le « pourquoi » de cette dystopie, tissée tout au long de l’histoire de l’informatique, du côté matériel comme logiciel. Devant une telle débâcle, c’est le moment ou jamais de garder ce qui marche et de faire l’inverse de ce qui ne va pas. Nous allons donc imaginer un « nouveau » type de pile qui pourrait trouver sa place dans de futurs microprocesseurs.

Une histoire des piles et de leur protection

Magazine
Marque
GNU/Linux Magazine
Numéro
270
Mois de parution
juillet 2024
Spécialité(s)
Résumé

Lorsque l’on parle de programmation sécurisée, on pense d’abord à un dépassement d’indice d’un tableau ou à des droits d’accès non respectés, puisque ces aspects sont visibles par le programmeur. Par contre, la pile est sous le contrôle absolu du compilateur et le contrat implicite est que « ça fonctionne » tant que nous le laissons faire son travail, qui est de plus en plus alambiqué. L’article précédent [1] détaillait de façon lovecraftienne les soucis de flexibilité et de sécurité inhérents au modèle de programmation à une seule pile, utilisé par (quasiment) tous les compilateurs actuels. J’ai amalgamé tous ces problèmes dans le terme « Single Stack Syndrome », mais il n’y a pas que le C ou le x86 dans la vie ! Nous pouvons trouver des inspirations dans d’autres langages, d’autres architectures et d’autres ères.

Les « tourments de la monopile », ou le « Single-Stack Syndrome »

Magazine
Marque
GNU/Linux Magazine
Numéro
269
Mois de parution
mai 2024
Spécialité(s)
Résumé

Si vous croyez que le format ASCIIZ (aussi appelé « chaîne de caractères à terminateur nul » à la base du langage C et d’UNIX) est le pire péché originel de l’informatique, accrochez-vous. Il est amplifié par un autre péché bien plus grave, commis au nom du minimalisme, excusé au nom de la compatibilité et perpétué par l’oubli des alternatives. Si vous avez lu l’article de mars 2023 [1] jusqu’au bout, vous avez probablement compris que la plupart des langages de programmation actuels n’utilisent qu’une seule pile. C’est la source de nombreux problèmes (de sûreté, de sécurité, de complexité et bien d’autres) aux origines de failles variées (représentant peut-être un cinquième des CVE) que nous sommes habitués à mitiger, sans les résoudre vraiment. Dans cette première partie lovecraftienne, nous irons jusqu’au fond de l’impasse pour démontrer l’absurdité, les difficultés et les dangers imposés par ce système.

Les derniers articles Premiums

Les derniers articles Premium

Petit guide d’outils open source pour le télétravail

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Ah le Covid ! Si en cette période de nombreux cas resurgissent, ce n’est rien comparé aux vagues que nous avons connues en 2020 et 2021. Ce fléau a contraint une large partie de la population à faire ce que tout le monde connaît sous le nom de télétravail. Nous avons dû changer nos habitudes et avons dû apprendre à utiliser de nombreux outils collaboratifs, de visioconférence, etc., dont tout le monde n’était pas habitué. Dans cet article, nous passons en revue quelques outils open source utiles pour le travail à la maison. En effet, pour les adeptes du costume en haut et du pyjama en bas, la communauté open source s’est démenée pour proposer des alternatives aux outils propriétaires et payants.

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Les listes de lecture

7 article(s) - ajoutée le 01/07/2020
La SDR permet désormais de toucher du doigt un domaine qui était jusqu'alors inaccessible : la réception et l'interprétation de signaux venus de l'espace. Découvrez ici différentes techniques utilisables, de la plus simple à la plus avancée...
8 article(s) - ajoutée le 01/07/2020
Au-delà de l'aspect nostalgique, le rétrocomputing est l'opportunité unique de renouer avec les concepts de base dans leur plus simple expression. Vous trouverez ici quelques-unes des technologies qui ont fait de l'informatique ce qu'elle est aujourd'hui.
9 article(s) - ajoutée le 01/07/2020
S'initier à la SDR est une activité financièrement très accessible, mais devant l'offre matérielle il est parfois difficile de faire ses premiers pas. Découvrez ici les options à votre disposition et les bases pour aborder cette thématique sereinement.
Voir les 33 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous