Si tu te perds, c'est parce que tu essaies de résorber les symptômes plutôt que de résoudre le problème de fond.
D'abord, comme tous les programmes, ton application et le mplayer que tu lances derrière héritent tout deux de la console de ton terminal X.
Ensuite, mplayer, en plus d'être doté d'un jeu de handlers fichier stdout,stdin, stderr comme tout le monde, ouvre une connexion vers le serveur X, qui est complètement indépendante de sa console, et qui peut très bien atteindre une machine distincte. Et c'est depuis les événements X que mplayer traite les commandes de navigation de l'utilisateur, pas depuis stdin.
Avec cela, en environnement graphique, l'application qui reçoit les événements de la console, c'est le serveur X lui-même (et en fait ce n'est même plus tout-à-fait vrai car Xorg ou Xfree86 gèrent eux-même le clavier et les périphs d'entrées). C'est aussi eux qui les traduisent en événements dans l'envrionnement graphique et qui les distribuent aux applications concernées (en fonction du focus et avec la complicité du WM).
D'autre part, à priori, ta douchette est vue comme un clavier, et est gérée comme tel par le système lui-même. C'est ce qui fait que tu n'a rien à configurer lorsque tu branches un clavier USB supplémentaire. Donc, au départ, tes applications ne savent pas du tout que tu es en train d'utiliser une douchette.
Ton problème, donc, c'est qu'il te faudrait deux focus. L'un provenant du clavier et ciblant la fenêtre vidéo de mplayer et l'autre, provenant de la douchette, sur la fenêtre du x-term qui fait tourner ton programme.
En conséquence, ton premier souci consiste à être parfaitement sûr de ce que tu veux faire :
- Soit tu souhaites conserver le fonctionnement normal de tes applications. Dans ce cas, c'est à toi de cliquer manuellement sur la fenêtre du X-term lorsque tu veux utiliser la douchette et sur celle de mplayer quand tu veux naviguer. C'est très fastidieux, mais c'est ce que tu ferais naturellement quand même si tu rentrais tes codes barre à la main ... Ca te permet également d'aller balancer la sortie de ta douchette dans un notepad au besoin, sans qu'elle soit interceptée par ton application ...
Tu peux aussi rentrer en mode slave pour ne pas avoir à faire du ping/pong mais cela t'oblige à réimplémenter TOUTES les commandes clavier de mplayer et à jouer avec termios pour récupérer l'état des touches avant d'appuyer sur return, quand c'est possible.
- Soit tu cherches à faire en sorte que la douchette ne serve qu'à zapper les vidéos lorsqu'elles tournent et dans ce cas, cela signifie implicitement qu'aucun autre programme ne doit recevoir ses caractères pendant que ton application tourne. Et dans ce cas, il y a donc une formalité à accomplir au préalable. Demander au système l'exclusivité sur la douchette.
Ca se gère donc au niveau de la gestion des HID par le noyau Linux. C'est normal que cela se trouve à ce niveau, d'ailleurs : il existe d'autres douchettes qui se branchent "en série" sur le cordon PS/2 en s'insérant entre le clavier et l'unité centrale. Dans un tel cas de figure, il t'est impossible de distinguer la douchette du clavier.
Dès lors, la meilleure solution consiste à écrire un daemon qui surveille silencieusement l'activité du clavier et reconnaît les trames susceptibles d'être envoyées par la douchette et qui, le cas échéant, prévient les programmes concernés via un canal de communication propre (un signal, un segment de RAM partagée ou , de préférence, un socket UNIX).
# Sémantique, architecture, toussa ...
Posté par Obsidian . En réponse au message Gestion STDIN + pilotage Mplayer. Évalué à 4.
D'abord, comme tous les programmes, ton application et le mplayer que tu lances derrière héritent tout deux de la console de ton terminal X.
Ensuite, mplayer, en plus d'être doté d'un jeu de handlers fichier stdout,stdin, stderr comme tout le monde, ouvre une connexion vers le serveur X, qui est complètement indépendante de sa console, et qui peut très bien atteindre une machine distincte. Et c'est depuis les événements X que mplayer traite les commandes de navigation de l'utilisateur, pas depuis stdin.
Avec cela, en environnement graphique, l'application qui reçoit les événements de la console, c'est le serveur X lui-même (et en fait ce n'est même plus tout-à-fait vrai car Xorg ou Xfree86 gèrent eux-même le clavier et les périphs d'entrées). C'est aussi eux qui les traduisent en événements dans l'envrionnement graphique et qui les distribuent aux applications concernées (en fonction du focus et avec la complicité du WM).
D'autre part, à priori, ta douchette est vue comme un clavier, et est gérée comme tel par le système lui-même. C'est ce qui fait que tu n'a rien à configurer lorsque tu branches un clavier USB supplémentaire. Donc, au départ, tes applications ne savent pas du tout que tu es en train d'utiliser une douchette.
Ton problème, donc, c'est qu'il te faudrait deux focus. L'un provenant du clavier et ciblant la fenêtre vidéo de mplayer et l'autre, provenant de la douchette, sur la fenêtre du x-term qui fait tourner ton programme.
En conséquence, ton premier souci consiste à être parfaitement sûr de ce que tu veux faire :
- Soit tu souhaites conserver le fonctionnement normal de tes applications. Dans ce cas, c'est à toi de cliquer manuellement sur la fenêtre du X-term lorsque tu veux utiliser la douchette et sur celle de mplayer quand tu veux naviguer. C'est très fastidieux, mais c'est ce que tu ferais naturellement quand même si tu rentrais tes codes barre à la main ... Ca te permet également d'aller balancer la sortie de ta douchette dans un notepad au besoin, sans qu'elle soit interceptée par ton application ...
Tu peux aussi rentrer en mode slave pour ne pas avoir à faire du ping/pong mais cela t'oblige à réimplémenter TOUTES les commandes clavier de mplayer et à jouer avec termios pour récupérer l'état des touches avant d'appuyer sur return, quand c'est possible.
- Soit tu cherches à faire en sorte que la douchette ne serve qu'à zapper les vidéos lorsqu'elles tournent et dans ce cas, cela signifie implicitement qu'aucun autre programme ne doit recevoir ses caractères pendant que ton application tourne. Et dans ce cas, il y a donc une formalité à accomplir au préalable. Demander au système l'exclusivité sur la douchette.
Ca se gère donc au niveau de la gestion des HID par le noyau Linux. C'est normal que cela se trouve à ce niveau, d'ailleurs : il existe d'autres douchettes qui se branchent "en série" sur le cordon PS/2 en s'insérant entre le clavier et l'unité centrale. Dans un tel cas de figure, il t'est impossible de distinguer la douchette du clavier.
Dès lors, la meilleure solution consiste à écrire un daemon qui surveille silencieusement l'activité du clavier et reconnaît les trames susceptibles d'être envoyées par la douchette et qui, le cas échéant, prévient les programmes concernés via un canal de communication propre (un signal, un segment de RAM partagée ou , de préférence, un socket UNIX).