Forum Programmation.c Gestion STDIN + pilotage Mplayer

• # Sémantique, architecture, toussa ...

  Posté par Obsidian le 06 juin 2007 à 21:07. Évalué à 4.

  

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

  • [^] # Re: Sémantique, architecture, toussa ...

    Posté par phentex le 06 juin 2007 à 22:35. Évalué à 1.

    

    Très intéressante réponse que voici. Tout d'abord, un grand merci pour avoir pris le temps de me répondre et m'expliquer autant de choses.
    
    Pour clarifier ma situation et ce que je souhaite faire:
    Je réalise une sorte de borne ou on file un ticket avec un code barre, et en fonction du code barre, on gagne ou on perd.
    
    La borne est un truc interactif grand public. En permanence à l'écran, il faut qu'il y ait une vidéo d'affichée. Que ce soit la vidéo d'attente tournant en boucle, pendant qu'on attend qu'une personne viennent passer son ticket, ou que ce soit, ponctuellement, un vidéo annonçant un grand gagnant, ou un perdant.
    
    S'il y a un truc que j'apprécie avec unix, c'est l'approche terre à terre, simple, rationnelle, qui consiste à dire: ya des outils qui font très bien un boulot : pas la peine de réinventer la roue, on utilise ce qui éxiste déjà.
    C'est à partir de là que je me suis dit: pour l'affichage, puisqu'il y a en permanence de la vidéo affichée en plein écran, autant utiliser un logiciel qui le fait bien et qui semble offrir pas mal d'options niveau pilotage par un programme tiers: Mplayer (et plutôt tout-terrain niveau formats en entrée qui plus est).
    
    Donc mon utilisation de Mplayer si tu veux, c'est juste pour balancer de la vidéo à l'écran, je n'ai besoin d'absolument aucune des fonctions d'interaction utilisateur qu'offre mplayer pour une utilisation disons "classique".
    
    Mon but est donc d'avoir MON PROGRAMME, qui écoute STDIN pour des codes barres, fait sa petite mayonnaise, et pilote mplayer pour afficher telle ou telle vidéo.
    
    En permanence, l'écran de l'ordinateur doit être occupé par une vidéo plein écran. Pas de bureau visible, pas de terminal visible, c'est pour une exposition en public.
    
    J'ai donc un autre problème: arriver à mettre mplayer en plein écran (pour le moment, lorsque je switch en plein écran, j'ai la vidéo tjs à 100% de sa taille, elle est juste centrée avec du noir pour remplir le reste de l'écran et non pas maximisée....).
    
    Je compte sur toi pour m'éclairer !
    
    Merci beaucoup d'avance.
    
    Cdt.

    • [^] # Taille vidéo mplayer

      Posté par niol (site web personnel) le 07 juin 2007 à 11:00. Évalué à 1.

      

      Pour la taille de la vidéo en plein écran, utilise -vo xv ou vo=xv dans le fichier de conf de mplayer.

    • [^] # Re: Sémantique, architecture, toussa ...

      Posté par popopo333 le 07 juin 2007 à 19:57. Évalué à 1.

      

      je pense que dans ton cas (une borne interactif), le plus simple ca serait vraiment de virer le serveur X et de passer en framebuffer.
      en framebuffer, mplayer devrait se contente de stdin pour le pilotage et donc si tu fermes stdin pour mplayer, il ne captera plus les caracteres envoyes par la douchette. tu pourrais meme piloter mplayer depuis ton application et eviter de le killer/relancer a chaque fois en utilisant un pipe.
      te reste plus qu'a changer de carte graphique!

• # Piloter stdin et stdout d'un fils

  Posté par niol (site web personnel) le 07 juin 2007 à 11:14. Évalué à 1.

  

  Pour piloter le stdin et le stdout d'un fils, il faut, juste après le fork(), fermer stdin et stdout et faire un dup() de deux descripteurs de fichier au préalable défini sur respectivement stdin et stdout. Les deux descripteurs de fichier étant connu du père, en écrivant dessus, on pilote mplayer (avec de préférence -slave mais pas obligé).

  Exemple de code repompé d'un d'un de mes vieux projets (le programme à lancer s'appelait apt, rien à voir avec Debian) par flemme de chercher dans Google:

  #include <stdio.h>
  #include <unistd.h>
  #include <stdlib.h> // exit()
  #include <string.h> // memset(), strcat()...
  
  #include "apt.h"
  #include "msg.h"
  #include "init.h"
  #include "parse.h"
  
  #define STDIN 0
  #define STDOUT 1
  #define STDERR 2
  
  
  /* The size should be around 500, because of the mvts answer */
  #define APT_OUTPUT_LINE_MAX_LENGTH 1000
  
  extern config* current_configuration;
  
  int APTIN_K,APTOUT_K;
  FILE* STREAM_IN;
  FILE* STREAM_OUT;
  
  void APTlaunch(const char *apt_path,int* aptin_k,int* aptout_k){
  
    int childPid;
    int pipefdin[2],pipefdout[2];
  
    /* Pipes init */  
    if( pipe(pipefdin) == -1 || pipe(pipefdout) == -1 ){
      perror("Creating apt communication pipes");
      exit(1);
    }
  
    childPid = fork();
    
    if( !childPid ){
  
      // son, so we launch apt and we connect
      // its standards channels to pipes
  
      // close unused channels
      close(pipefdin[1]);
      close(pipefdout[0]);
  
      // Duplicate stdin to our pipe
      close(STDIN);
      if( dup(pipefdin[0]) == -1 ){
        perror("duplicating apt stdin");
        exit(1);
      }
  
      // Duplicate stdout to our pipe
      close(STDOUT);
      if( dup(pipefdout[1]) == -1 ){
        perror("duplicating apt stdout");
        exit(1);
      }
  
      // Duplicate stderr to the same pipe as stdout
      close(STDERR);
      if( dup(pipefdout[1]) == -1 ){
        perror("duplicating apt stderr");
        exit(1);
      }
  
      // Launch apt
      if( execl(apt_path,apt_path,NULL) == -1 ){
        perror("can't find apt");
        exit(1);
      }
  
    }else{
  
      // father, this process, continues execution
  
      // Close unusable channels
      close(pipefdin[0]);
      close(pipefdout[1]);
  
      // Return the right values to control the apt
      *aptin_k = pipefdin[1];
      *aptout_k = pipefdout[0];
  
    }
  
  }
  
  void APTstart(const char* apt_path){
  
    // Launch the apt upon the connection
    APTlaunch(apt_path,&APTIN_K,&APTOUT_K);
  
    // Use stdio to manipulate the commands
    STREAM_IN = fdopen(APTIN_K,"w");
    STREAM_OUT = fdopen(APTOUT_K,"r");
  
  }
  
  void APTstop(){
    write(APTIN_K,"q\n",2);
  }
  
  int APTloadDataFile(const char* filename){
    int written;
    
    written = fprintf(STREAM_IN,"load %s%s\n",current_configuration->apt_data_path
  ,filename);
    fflush(STREAM_IN);
  
    return written;
  }
  
  int APTsendCommand(const char* cmd){
    int written;
    
    written = fprintf(STREAM_IN,"%s\n",cmd);
    fflush(STREAM_IN);
  
    return written;
  }
  
  char* APTgetNextLine(){
    char* line;
    line = (char*)malloc(APT_OUTPUT_LINE_MAX_LENGTH*sizeof(char));
  
    fgets(line,APT_OUTPUT_LINE_MAX_LENGTH,STREAM_OUT);
  
    // Careful, the \n is still in line
    return line;
  }
  
  char* APTgetOutputTillEmptyLine(){
    char* buffer;
    lineList* acftList = (lineList*)malloc(sizeof(lineList));
    lineList* otherLines;
    int byteCounter = 0;
    
    acftList->line = APTgetNextLine();
    acftList->nextLines = NULL;
    otherLines = acftList;
  
    if( acftList->line[0] != '\n' ){
      buffer = APTgetNextLine();
  
      while( buffer[0] != '\n' ){
        byteCounter += strlen(buffer);
        otherLines = addToLineList(otherLines,buffer);
        buffer = APTgetNextLine();
      }
    }
  
    buffer = lineList2string(acftList,byteCounter);
    freeLineList(acftList);
  
    return buffer;
  }
  
  void APTflushOutput(){
    char* line = APTgetNextLine();
  
    while( strcmp(line,"\n") ){
      free(line);
      line = APTgetNextLine();
    }
    free(line);
  }
  

  • [^] # Re: Piloter stdin et stdout d'un fils

    Posté par phentex le 07 juin 2007 à 17:20. Évalué à 1.

    

    Je ne cherche pas vraiment à "piloter" mplayer, tout ce que je souhaite, c'est lancer une vidéo en plein écran:
    en forkant/execl on dit à mplayer de lire la vidéo en boucle, dans quel cas suffit d'envoyer un signal à mplayer pour le faire taire par la suite. Pendant ce temps je veux pouvoir faire ma petite cuisine avec la douchette code barre sur STDIN. Je veux que MPLAYER ME FOUTE LA PAIX, Qu'il ne soit PAS sensible à aucune pression clavier. Je me sers juste de Mplayer comme "afficheur de vidéo", that's all.
    
    L'autre cas plus simple est la lecture d'une vidéo une seule fois, dans quel cas, mon programme fait juste un waitpid() pour attendre que mplayer quitte à la fin de la lecture.
    
    Dans tous les cas, mon problème est que Mplayer me laisse tranquille et que mon programme garde la main sur STDIN.
    
    SVP, vous là, oui, vous, je suis sûr que vous savez comment résoudre mon problème. Ayez pitié :°)

    • [^] # Re: Piloter stdin et stdout d'un fils

      Posté par niol (site web personnel) le 07 juin 2007 à 17:38. Évalué à 1.

      

      Et pourquoi donc ne fermes-tu pas stdin après avoir forké vers mplayer (comme fait dans l'exemple que je te donne)?

      • [^] # Re: Piloter stdin et stdout d'un fils

        Posté par phentex le 08 juin 2007 à 10:35. Évalué à 1.

        

        Salut,
        
        Je le fais déjà en fait. Mais cela ne résoud pas le problème. Lorsqu'on lance mplayer, utilise non seulement stdin/stdout, mais il ouvre également sa propre fenêtre pour afficher la vidéo. Lorsque cette fenêtre est créée, elle prend le focus dans X qui la branche sur les évènements clavier+souris (!=stdin). Même en atomisant stdin de mplayer, la fenêtre affichant la vidéo reste encore et toujours sensible aux pressions clavier (& donc à la lecture d'un code barre).... :/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.