Bonjour,
Je cherche à savoir quel est le signal qu'il faut intercepter si l'on veut capter des pressions sur le clavier / des mouvements de souris. Est-ce juste d'utiliser la fonction sigaction définie dans <signal.h>?
Je suis bien triste d'avoir découvert que le signal SIGINT ne sert qu'à la combinaison ctrl-c
Merci d'avance.
Salut,
pour moi intercepter le clavier, c'est lire /dev/input/xxx sous Linux. Je n'ai aucune idée si cela répond à ta question (d'autant plus que je pense que les keyboard layouts sont appliquées bien après).
Bon courage, tiens nous au courant
Salut,
Merci pour ton intervention. Je ne suis pas spécialiste Linux, mais je crois que si je code en C, je devrais faire du "polling" pour analyser l'état des touches d'après ta solution (à vérifier). Ce que je voudrais c'est quelque chose comme la fonction sigaction qui permet "d'enregistrer une fonction auprès de l'OS" pour que ce dernier l'appelle lorsqu'une touche est pressée. De cette manière, mon programme peut continuer à se dérouler sans avoir à bloquer en attendant l'événement.
Mais dès que je retourne sur mon pc, je lance linux et je vais voir ce que /dev/input/x contient pour savoir si je peux faire quelque chose avec ça. Je vous tiens au courant.
Salutations
Voilà, j'ai lu quelques documents en vitesse...
Stp, corrige-moi si je me trompe : Les fichiers qui se trouvent sous /dev/input/... sont en fait des interfaces entre le driver et mon programme. Je peux y écrire en utilisant chronologiquement les fonctions "open()" pour obtenir le file descriptor puis, à l'aide de ce dernier, communiquer avec le device au-travers de la fonction "ioctl()"?
A priori, dans mon cas, il est possible de demander de générer le signal SIGIO lors de la pression d'une touche, en utilisant open(fd , O_RDONLY | O_ASYNC). Ainsi, je pourrai attraper ce signal à l'aide d'une fonction que j'ai passée en paramètre à "sigaction()" puis déterminer l'origine de la touche ayant généré ce signal. D'une manière que je ne connais pas encore...
Si jusque là je ne me suis pas trop trompé... ...Je pense devoir ouvrir (open()) /dev/input/by-path/platform-i8042-serio-0-event-kbd. Est-ce juste? C'est le seul fichier dans ce répertoire à contenir un nom de fichier composé de kbd
Est-ce que ma réflexion n'est pas trop éloignée de la vérité?
Merci d'avance
Non, tout à fait. sous linux tout est accessible à partir d'un fichier. Tu dois donc pouvoir récupérer le code de la touche pressée en lisant simple /dev/input/kbd. D'ailleurs, dans un terminal root si tu fais un cat /dev/input/by-path/ton_periph_kbd et que tu tapes depuis un autre terminal quelque chose tu le vois apparaitre dans le buffer clavier.
La structure des eventX:
pour au dessus, tu peux faire cat /dev/input/by-path/xxxx_kbd | hexdump -c pour avoir des traces en hexaCode:struct input_event { struct timeval time; unsigned short type; unsigned short code; unsigned int value; };
D'ailleurs: https://stackoverflow.com/questions/...eyboard-format
Dernière modification par bisou10 ; 11/05/2014 à 21h50. Motif: précisions
Attention, en 64 bit, la structure fait 24 octets, alors qu'en 32 bit, elle en fait 16 (donc un prog compilé en 32 ne tournera pas sur une 64...
sinon, la commande utile: od (faire un man od pour comprendre les options suivantes) (adapter le nom du périph, ici ma souris usb...)
en 32bits: od -td2 -w16 -v -An /dev/input/by-path/pci-0000:00:1d.0-usb-0:1.3:1.0-event-mouse
en 64bits: od -td2 -w24 -v -An /dev/input/by-path/pci-0000:00:1d.0-usb-0:1.3:1.0-event-mouse
ce sont principalement les dernières colonnes qui sont importantes pour nous (le début étant un timestamp).
Jusqu'ici tout va bien...
Il y a une grosse confusion, les signaux auquels tu fais référence sont des signaux inter-processus: un moyen de communiquer entre des programmes différents (le terme consacré est "IPC" pour inter-process communication). Le fait que certain de ces signaux (une minorité) puisse être envoyé par le clavier n'est qu'un effet de bord...Je cherche à savoir quel est le signal qu'il faut intercepter si l'on veut capter des pressions sur le clavier / des mouvements de souris. Est-ce juste d'utiliser la fonction sigaction définie dans <signal.h>
Si tu cherches un moyen de communication entre ton application et l'utilisateur, nous ne sommes plus dans le même concept, et il ne faut plus utiliser les mêmes outils. Effectivement, il doit sans doute se passer quelques choses dans les "/dev/input", en revanche je ne pense pas que ce soit la manière la plus simple, la plus efficace ni la plus "propre" de faire. La question est donc quel type de programme veux tu faire, si c'est un programme en mode terminal, je te conseille d'utiliser une bibliothèque comme "ncurses", si c'est un programme graphique il faut taper au niveau du serveur graphique (xorg ou wayland), ou au-dessus au-niveau de la bibliothèque graphique (Qt ou gtk+), ou au niveau encore au-dessus en discutant avec le gestionnaire de fenêtres (GNOMe, KDE, XFCE...). En résumé, pour un programme en mode terminal, "ncurses", pour un programme graphique je conseilllerai "Qt".
Mon discours est à prendre avec des pincettes suivant le besoin réel, en effet les évènements utilisateurs doivent être "dispatchés" au bon programme (celui qui a le focus, autre...), or je suppose qu'une lecture directe des fichiers "/dev/input" reflettera l'activité "globale" du périphérique concerné, ou à l'inverse un "thread" avec une lecture continue du clavier est certainement suffiseante si on ne s'intéresse qu'aux touches tapées dans la console du programme en cours.
Salut à tous,
D'abord merci pour vos interventions, elles m'ont permis d'en apprendre un peu plus sur linux et sur certains mécanismes et librairies à disposition.
J'ai trouvé ce que je cherchais. Ces derniers jours, j'ai fait la connaissance du Kernel et nous nous sommes très bien entendus, nous avons prévu de nous rencontrer à nouveau
L'adresse du lien que j'ai trouvé est la suivante : http://www.gadgetweb.de/programming/...keylogger.html .
J'y suis parvenu en lisant les différents .h qui traitaient avec le clavier, tels que keyboard.h (.c aussi) input.h, c'est là que je suis tombé sur la fonction register_keyboard_notifier() qui permet d'enregistrer une fonction callback... C'est exactement ce que je voulais, implémenter le pattern observer ; je m'inscris auprès d'un émetteur pour recevoir ses notifications.
Le sens de cette recherche est que je souhaite apprendre à communiquer avec le matériel (clavier ou autre) car j'ai fait l'acquisition d'un raspberry pi et je voudrais comprendre le fonctionnement du développement de bas niveau (drivers, kernel,...) pour écrire moi-même ma librairie C I2C. Il en existe déjà, je sais bien, mais je le fais dans un but pédagogique.
Vos intervention n'ont pas été vaines puisque j'ai fait la connaissance de /dev/input/eventxentre autres.
Encore merci pour le temps que vous avez passé à m'aider.
Salutations
OK ton besoin est plus clair maintenant. Et les solutions que je te proposais ne sont du coup absolument pas pertinentes...Le sens de cette recherche est que je souhaite apprendre à communiquer avec le matériel (clavier ou autre) car j'ai fait l'acquisition d'un raspberry pi et je voudrais comprendre le fonctionnement du développement de bas niveau (drivers, kernel,...) pour écrire moi-même ma librairie C I2C. Il en existe déjà, je sais bien, mais je le fais dans un but pédagogique.
Une petite remarque de terminologie en prenant l'exemple de l'I2C: tu vas faire un pilote de périphérique pour accéder au contrôleur I2C, puis tu feras une ou plusieurs bibliothèques pour les différents protocoles / matériels relier sur ton bus I2C, il est fondamental de séparer la boîte à outils qu'est le pilote, de ses politiques d'utilisation embarquées dans tes bibliothèques programmes. De plus, le pilote ne pourra se faire qu'en espace noyau, alors que ta bibliothèque pourra être en espace utilisateur, et c'est fondamentalement différent (en terme de développement _ET_ d'utilisation).
Quelques liens que je trouve intéressant pour le développement noyau linux:
la bible, attention certaines interfaces noyau ont changées, il faut donc consulter cette page mais elle n'a plus l'air d'être mise à jour depuis un petit moment...
http://kernelnewbies.org/
On y pense pas forcément, mais les doc du dossier "Documentation" dans les sources du noyau sont souvent intéressantes.
La lecture des sources est souvent nécessaire, attention il faut avoir un bon niveau en C car il peut y avoir des techniques déroutantes pour un nouveau venu (je pense par exemple à de limplémentation objet en C que tu trouveras à plusieurs endroit).
Le noyau c'est une chose, mais ce n'est pas tout le "bas-niveau", je pense qu'il est indispensable (ou en tout cas bénéfique) de se faire une culture "UNIX", les principes KISS, bricoler un peu de shell pour se rendre compte de la puissance du concept, se rendre compte que les interfaces systèmes ont toutes deux faces: la face C et la face outils / commande shell, et que du coup pour lire/écrire sur une liaison série il ne faut pas écrire une ligne de C... Et qu'avec find/grep/ctags/vim tu n'as plus besoin de bouffer 2Go de RAM à cause d'eclipse...
Attention également, je pars du postulat que tu veux du bas-niveau "UNIX", mais tu as encore plus "bas-niveau": travailler sans OS pour faire de l'embarqué, aux frontières de l'électronique et de l'informatique (mais c'est quand même bien plus de l'info), les problématiques sont différentes, et le raspberry pi pas forcément le plus adapté pour commencer... Si ce domaine t'intéresse également fait signe je peux t'en dire plus, et de nos jours il y a de quoi bien s'amuser pour moins de 100 euros de matos.
Merci pour toutes ces références, je ne vais pas tarder à aller y jeter un coup d’œil,... voir à m'y jeter tout entier!
L'implémentation objet en C ne me fait pas peur, je l'ai déjà abordée durant des TP,... ...il y a quelques années. Il ne s'agit plus que de m'y replonger.
Quant au très bas niveau, c'est ce que j'ai fait lors de la conception de cartes intégrant des uP. Malheureusement, je n'ai jamais eu l'occasion de porter un OS sur une de ces cartes et j'ai toujours travaillé en très bas niveau, en C ou asm. Je veux découvrir le dessous des OS pour comprendre comment ils sont interfacés avec le matériel. ...Et plus encore...
Tu m'as donné des pistes très intéressantes.
Cordialement
C'est clair que le dev kernel et le dev user space est vraiment différent.
Tu peux concevoir ton système comme un module que tu chargeras ensuite, c'est une bonne manière de lier KS et US.
C'est un peu ce à quoi je pensais, et ces dernières années je trouve que c'est de plus en plus simple de faire des projets sympas avec des outils de qualité à moindre frais... Quelques exemples:Quant au très bas niveau, c'est ce que j'ai fait lors de la conception de cartes intégrant des uP. Malheureusement, je n'ai jamais eu l'occasion de porter un OS sur une de ces cartes et j'ai toujours travaillé en très bas niveau, en C ou asm. Je veux découvrir le dessous des OS pour comprendre comment ils sont interfacés avec le matériel. ...Et plus encore...
L'ARDUINO, qui est une solution matérielle + logicielle, mais de ce que j'en sais, ce serait trop un "jouet" si tu as déjà de l'expérience sur ce genre de trucs.
En matériel, bien supportés par GCC, et où tu trouveras foultitude de carte de dev pas trop cher (et sonde JTAG), j'aime bien les MSP430x (les 20bits), puis pour grimper d'un cran de complexité ARM7 ou cortex-M3/cortex-M4, après je pense que les bestioles sont nettement plus compliquées. Les AVR sont très bien supportés par gcc, et il y a des cartes de dev pour pas cher, mais je ne sais pas où ça se situe en terme de compléxité. Je déconseille le PIC car je trouve le compilateur MPLAB (?) de très mauvaise qualité, et je n'avais jamais trouvé d'alternatives fonctionnelles et bon marché, peut-être les choses ont évolué depuis. Pour des cartes de dev et sonde JTAG pas cher, il y a OLIMEX par exemple.
Pour l'aspect logiciel, sans parler d'OS (car il n'y pas de séparation kernel/user, pas de protection mémoire...), il y a FreeRTOS qui est de super qualité, c'est un ordonnanceur de tâche avec les 4 trucs qui vont bien autour, et porter FreeRTOS sur ta plateforme te fera toucher certain aspect profond de l'informatique (sections mémoires, "c run time", vecteurs d'interruptions etc...). Il en existe pas mal d'autre, mais en dehors de FreeRTOS, je n'ai utilisé qu'eCos que je déconseillerai car il a l'inconvénient de son avantage: il y a beaucoup trop de fonctionnalités, du coup tu es perdu dans l'arborescence du code, tu passes un temps fou à l'apprendre...
Mais nous sommes bien d'accord, ce n'est pas la même chose que l'apprentissage "bas-niveau" dans un environnement UNIX.
J'ai du nouveau,
je l'écris ici au cas où ça pourrait aider des personnes qui se posent les mêmes questions que moi :
Communication entre Kernel space et user space en faisant usage de callbacks (entre autres) : http://people.ee.ethz.ch/~arkeller/l...owto.html#toc6
Développement de drivers linux : http://lwn.net/images/pdf/LDD3/
Evidemment, il faut se mettre à l'anglais pour y comprendre quelque chose, mais ça en vaut la peine.
Salutations
