Ah!
Clicbait!
Non, plus sérieusement: j'ai un lecteur RFID M301 connecté en USB:

pi@pickcart1:~ $ lsusb
Bus 001 Device 004: ID 13ba:0018 PCPlay Barcode PCP-BCG4209

Quand je passe une puce RFID, je reçois les chiffres et ils s'affichent dans la console ou un éditeur de texte, selon le focus.
Maintenant, j'ai un programme qui est lancé au démarrage dans /etc/rc.local:

sudo /home/pi/iLab/PickCartRaspberry &

Comment je récupère mon flux clavier la-dedans?

A priori, je vois les touches passer dans /dev/input/by-id/usb-13ba_Barcode_Reader-event-kbd

Un truc de marrant: ça envoie vraiment les codes de touches clavier, avec mon clavier français connecté où les chiffres ont besoin de majuscule, ça affiche : &é"'(-è_çà, alors qu'avec un clavier US ou DE où les chiffres n'ont pas besoin de majuscule ça affiche comme il faut 1234567890.

Je ne suis pas sûr d'avoir bien compris ce que tu souhaites faire, mais si les touches passent dans ton `/dev/qqchose`, il te suffit de faire une lecture de ce fichier pour obtenir tes touches.

Il y a plus d'infos sur la structure de ce fichier quelque part?
Parce qu'il est sans fin ce fichier vu que chaque touche arrive dedans.
C'est juste le numéro des touche en binaire?

Sous linux/unix, tout est fichier. Les /dev/ sont des fichiers certes, mais ils représentent des interfaces, ton port USB1, ton lecteur cd, ta mémoire, ton cpu, ...

Ce sont des fichiers, lisibles ou utilisables comme des fichiers textes : même s'il ne s'agit pas vraiment de fichiers au sens traditionnel, tu peux les manipuler comme tels.

PetitCalgonIl y a plus d'infos sur la structure de ce fichier quelque part?

J'imagine que ça doit dépendre du matériel qui écrit dedans, donc plutôt s'orienter vers la documentation de ton lecteur rfid ?

PetitCalgonParce qu'il est sans fin ce fichier vu que chaque touche arrive dedans.

Oui, c'est un fichier sans "fin" (un flux, en gros).

Bon, ben il y a une librairie python qui fait ça
python-evdev.readthedocs…

Et ça donne ça environ:

import evdev
device = evdev.InputDevice('/dev/input/by-id/usb-13ba_Barcode_Reader-event-kbd')
for event in device.read_loop():
    if event.type == 1 and event.value == 1:
        print(evdev.ecodes.KEY[event.code])

pour un résultat impeccable

pi@pickcart1:~/Rfid $ sudo python reader.py 
KEY_4
KEY_0
KEY_7
KEY_0
KEY_8
KEY_6
KEY_4
KEY_8
KEY_7
KEY_1
KEY_ENTER

Y'a plus qu'à faire communiquer les deux ensembles ... On va voir

Tu as conscience que ça fait peur de te voir préfixer toutes tes commandes par sudo ?

Je m'en fou c'est un raspberry pi !
Mais sinon, oui j'ai conscience.
En l’occurrence, je n'en ai effectivement pas besoin.
J'en ai besoin pour jouer avec les GPIO, mais donc pas le clavier, yes.

TchouTu as conscience que ça fait peur de te voir préfixer toutes tes commandes par sudo ?

J'avais déjà envie de faire la remarque lors du premier post
Cela dit, sur un Pi, c'est pas trop grave. Mais un setuid bit serait plus élégant dans le cas présent (sauf si un chown passe sur un /dev/qqchose ?).

Je ne connaissais pas python-evdev. Par contre, je sais qu'y a un pyusb qui parait-il marche pas trop mal.
Par contre, je vois que python-evdev supporte les nouveaux protocoles __fspath__ (suggérant qu'ils sont assez "à jour" avec les changements dans la librairie standard), mais je suis surpris que InputDevice ne soit pas un context manager (pour pouvoir libérer automatiquement la ressource).

En suivant les liens, je suis tombé sur libusb.info/ qui est plus à jour que PyUSB.
Pour l'instant, j'ai réussi à écrire un fichier avec le tag RFID qui viens d'être lu.
Maintenant, je dois commander des nouveaux lecteurs, et sur amazon, on me propose d'un coup ça:
www.amazon.fr/AZDelivery…

Et je ne sais plus quoi faire
Je bascule sur cet autre carte à souder soi-même, ou je prends le lecteur RFID que j'avais trouvé avant mais qui est en livraison depuis la Chine en 3 semaines ?