RAPPORT DE MEMOIRE DE FIN D ETUDES

Transcription

1 Réf : 2009/II/ Soutenu à la session de Septembre 2009 Université de la Manouba Ecole Nationale des Sciences de L Informatique RAPPORT DE MEMOIRE DE FIN D ETUDES Présenté en vue de l obtention du titre d INGENIEUR EN INFORMATIQUE Par Mohamed-Ikbel BOULABIAR Sujet : Configurateur d entrée pour Linux Organisme d accueil : Laboratoire d Informatique Interactive Responsable : Pr. Stéphane CHATTY Encadré par : Pr. Stéphane CHATTY Supervisé par : Pr. Nejib BEN HADJ ALOUANE

2

3 Résumé JUSQU à nos jours, les applications demeurent câblés pour un unique paradigme d interaction limité aux évènements produits par seulement le clavier et la souris. Les études concernant l adaptabilité et la configuration de l entrée restent encore très peu nombreuses et non directement implémentables dans les systèmes d exploitation surtout pour Linux. Dans ce travail, nous proposons un nouveau modèle d entrée faisant intervenir le paradigme de configuration à travers des adaptateurs entre les dispositifs matériels et les applications. Ce modèle qui s intègre entre le noyau Linux et les applications permet un large contrôle en injectant des évènements d entrée virtuels et adaptables ou en invoquant les méthodes internes des applications existantes sans nécessiter aucune modification ou réécriture. Mots clés : Interaction Homme-Machine, Multi-tactile, Périphériques d entrée, Techniques d interaction, Adaptabilité, Accessibilité, Interfaces Post-WIMP. Abstract JUST to our days, applications are still wired to a single interaction paradigm restricted to events produced by keyboard and mouse. Studies concerning the adaptability and configuration of the input still very few and not directly applyable and implementable in OS especially for Linux. In this work, we propose a new model of input involving the paradigm of configuring it via adapters between hardware devices and applications. The model that fits between the Linux kernel and applications allows extensive control by injecting adaptable virtual events input after treatment or by invoking internal methods of applications which doesn t require rewriting. Key words : Human-Computer Interaction, Multitouch, Input Device, Interaction Techniques, Adaptability, Accessibility, Post-WIMP.

4 Signatures des encadrants Prof. Nejib BEN HADJ ALOUANE (ENSI) Prof. Stéphane CHATTY (LII-ENAC)

5 Remerciements C EST parce que j ai beaucoup estimé tous ceux qui m ont écouté, conseillé, critiqué et encadré que je tiens à leur faire part de toute ma gratitude, et plus particulièrement, je tiens à remercier à travers ces courtes lignes : Mon encadrant le Professeur Stéphane Chatty, pour m avoir incité à mener à bien ce travail, pour son aide, son temps passé pour me guider, ses efforts pour m intégrer dans l environnement, son dévouement et ses précieux conseils. Mon superviseur le Professeur Nejib Ben-Hadj-Alouane, parce qu il a accepté de me superviser et suivre les détails de l avancement de mon travail, ainsi que son aide et ses conseils dans plusieurs étapes du projet. Tous les membres de l équipe du laboratoire Stéphane Conversy, Thierry Garcia, Hélène Gaspard-Boulinc, Yannick Jestin, pour leurs aide, leurs remarques, leurs esprit ouvert et leurs respect. Ma famille dont je ne me permettrai pas d oublier de la remercier, pour son soutien à la fois moral et matériel durant toute ma carrière et surtout durant les moments difficiles. Je tiens aussi à remercier ceux qui ont partagé le même espace de travail dans le bureau C106 dont les matheux Keumjin Lee et Nour Dougui, les doctorants Benjamin Tissoire, Christophe Hurter et Gilles Tabart ainsi que les autres stagiaires Pierre Bucher, Fabien André et Sébastien Hamdani Et je tiens aussi à remercier toute autre personne ayant contribué d une façon ou d une autre, au bon déroulement de mon projet de stage et je cite :

6 REMERCIEMENTS vi Kevin Ottens (KDE), Greg Kroh-Hartman (Novell, LDP), Jiri Kosina (opensuse, input), Mathieu Herrb (LAAS, Xorg), Henrik Rydberg (Linux kernel), Dmitry Torokhov (Linux kernel), Bradley T. Hughes (Qt-Nokia), Nathalie Foutel (ENAC), Kay Sievers (udev), Peter Hutterer (RedHat, MPX), Thomas Petazzoni (Toulibre) Sans oublier le personnel de la société Intuilab et les personnes qui aident dans les salons de discussions IRC.

7 Table des matières Remerciements v Introduction générale 1 1 Contexte du projet Présentation de l organisme d accueil L École Nationale de l Aviation Civile Le Laboratoire d Informatique Interactive IntuiLab et son secteur d activité Cadre du travail : Projet ShareIT Présentation du travail demandé Processus de développement adopté La Datalyse Le Maquettage Réalisation et prototypage Étude préalable et état de l art Gestion de l entrée Signification Diversités des dispositifs et des paradigmes d interaction Nécessité d un modèle Modèles et études Scientifiques

8 TABLE DES MATIÈRES viii Modèles de transition Étude des performances et expérimentation Taxinomie des dispositifs L utilisation de plusieurs dispositifs Les systèmes multi-tactiles Émergence de la configurabilité Modèle HID Présentation Principe du modèle Limites du modèle Conclusion Spécification Méthodologie participative Scénarios d utilisation Scénario Scénario Scénario Brainstorming Définition Principe Méthode Extraction des besoins Émergence d un modèle Intégration au système Linux Interface de configuration Conclusion Analyse et conception élémentaire 25

9 TABLE DES MATIÈRES ix 4.1 Analyse des systèmes Système de gestion d entrée de Linux Système HID du noyau Linux Communication DBus Utilité Historique, Dcop, Bonobo, Corba Principe Étude des périphériques Les Phidgets Les Surface-Computers Tablette Wacom Table DiamondTouch Tablette Stantum Conception élémentaire et Solutions Intégration du configurateur au noyau Linux Création d un daemon séparé Intégration à la chaine traditionnelle d entrée Accès DBus aux applications Principe d injection des évènements Validation des choix Conclusion Modélisation et Prototypage Modélisation Unités minimales d entrée Représentation d un périphérique Projection de la configuration Prototypage des modèles

10 TABLE DES MATIÈRES x Communications DBus Injection de l entrée Conclusion Mise en oeuvre et réalisation Environnements Logiciel Systèmes d exploitation Le reste de l environnement Environnements Matériel Machines utilisés Périphériques Réalisation Corps du configurateur Interface graphique de configuration Problèmes rencontrés Chronogramme Conclusion Conclusion et Perspectives 43 Bibliographie 44 Acronymes ii A Diffusion des résultats des travaux iii A.1 Travail avec la communauté de Linux iii A.2 Génération des vidéos de démonstration iv A.3 Les retours reçus iv A.4 Design du site du laboratoire v B Système DBus vi

11 TABLE DES MATIÈRES xi B.1 Présentation de D-Bus vi B.2 Applications D-Bus vii B.3 Concepts viii

12 Liste des figures 1.1 Méthodologie de travail IntuiSign TM Exemple de périphériques, tablette et TrackPen, manette Wiimote et une spaceball Modèle de transition à 3 états de Buxton Application du modèle sur la souris Taxinomie de Buxton L espace de conception de Card [CMR90] L utilisation de deux souris avec deux mains dans la plateforme Whizz Les surfaces computer : Microsoft Surface et IntuiFace d IntuiLab Exemple de configuration de l entrée avec ICon Principe du transfert HID Conception itérative et participative Le résultat d un Brainstorming Abstraction de la constitution du système Linux Quelques phidgets : des boutons, des sliders et des capteurs divers Tablette Wacom Unités d entrée minimales Représentation d un périphérique

13 LISTE DES FIGURES xiii 5.3 Principe d inclusion de la configuration dans le modèle Architecture de la communication DBus utilisée Architecture de l injection de l entrée Le contrôlleur Nanokontrol Architecture du configurateur Interface de génération des paramètres pour le configurateur Chronogramme du projet A.1 La liste de diffusion de Linux iii A.2 Capture de la vidéo diffusée iv A.3 Le nombre élevé de visualisations iv A.4 Le nouveau site du laboratoire v B.1 Schéma présentant les Concepts de DBus viii

14 Introduction générale LA majorité des utilisateurs des ordinateurs savent obligatoirement comment taper sur un clavier et faire bouger le pointeur à l écran en déplaçant la souris. Les applications quotidiennes ainsi que les systèmes d exploitation ont été conçus pour supporter ces deux périphériques et ils sont préparés pour que l interaction se fera toujours de la même façon. Notre façon de contrôler les ordinateurs est devenue alors un standard que les fabricants du matériel et les éditeurs des logiciels y compris-les systèmes se sont mis d accord de la garder. Il existe néanmoins bien d autres manières de contrôler les applications, les manettes de jeu sont utilisées, les contrôlleurs midi pour les applications musicales ainsi que les outils et les surfaces tactiles. Il existe même des périphériques très spécialisés utilisés dans les applications de dessin 3D. Chaque jour de nouveaux dispositifs apparaissent mais la chose commune entre tous ces dispositifs est qu ils sont tous adaptés à un contexte d utilisation donné et figé. On peut pas malheureusement utiliser la manette pour remplacer la souris ni le contrôlleur midi pour remplacer un clavier. On ne peut pas même les utiliser hors de leurs contextes très restreint. Par contre, beaucoup de travaux de recherche montrent des analyses sur la possibilité qu un dispositif remplace un autre. Et rien encore ne peut nier qu on peut trouver parfois des contextes d utilisation beaucoup plus naturels et adaptés que ceux figés par le constructeur ou par le système d exploitation. C est dans ce cadre que notre projet se situe. Nous étudions les techniques d adaptation du contexte de l utilisation des dispositifs d entrée. Nous cherchons à rendre cette utilisation configurable et dans la portée de l utilisateur final. Nous cherchons à enlever les limitations des systèmes et même des fabricants pour l utilisation quotidienne en se référant à des modèles scientifiques et études de scénarios réels des utilisateurs.

15 INTRODUCTION GÉNÉRALE 2 Notre tâche commence par l élaboration d un modèle générale et simple capable de supporter l intégration de la configuration. Les travaux seront applicables sur le système d exploitation Linux et cherchent à améliorer la façon d interagir avec l ordinateur et de faciliter la recherche d autres paradigmes d interaction. Nous avons aussi concentré une grande partie de notre travail sur les nouvelles techniques d interaction multi-tactiles ou multitouch. L organisation du rapport sera comme suit : Le premier chapitre est un chapitre introductif présentant le contexte dans lequel a été émergé le projet : le sujet, l organisme d accueil et la méthodologie adoptée, Le deuxième chapitre est dédié à une étude préalable et un état de l art des travaux de recherche dans ce domaine ainsi que les grands systèmes utilisés, Le troisième chapitre comporte une spécification des besoins du projet suite à une étude de scénarios réels d utilisation, Le quatrième chapitre est consacré pour l analyse des systèmes à modifier et à la conception élémentaire des solutions, Dans le cinquième chapitre, nous exposons notre modélisation des périphériques et les travaux de prototypage réalisés, Le dernier chapitre présentera le travail réalisé, l environnement et les difficultés rencontrés.

16 CHAPITRE 1 Contexte du projet Dans ce chapitre, Nous exposons le contexte général du projet. On présente en premier lieu l organisme d accueil, le travail demandé et on termine par l explication de la méthodologie de travail qu on a suivi. 1.1 Présentation de l organisme d accueil L École Nationale de l Aviation Civile L école nationale de l aviation civile (ENAC) est une grande école aéronautique située à Toulouse (Haute-Garonne). C est un établissement public à caractère administratif placé sous la tutelle du Ministère de l Écologie, de l Énergie, du Développement durable et de la Mer. Cette tutelle est exercée en pratique par la Direction Générale de l Aviation Civile (DGAC). L ENAC est membre associé de l Université de Toulouse et membre du pôle de compétitivité Aerospace Valley. A l exception du domaine de la construction aéronautique, l École assure des formations pour la plupart des métiers de l aviation civile : exploitation aéronautique, exploitation aéroportuaire, gestion du trafic aérien, sécurité et sûreté aéronautiques, systèmes de communication, navigation et surveillance. L ENAC est à la fois une école d ingénieurs et un centre national de formation de la DGAC et au profit d autres institutions françaises ou étrangères ; elle assure notamment une très importante activité de formation continue. Fondée en 1948 à Orly, l École a été délocalisée à Toulouse en Elle est aujourd hui implantée sur le complexe scientifique de Rangueil, à proximité du futur Aerospace Campus.

17 CHAPITRE 1. CONTEXTE DU PROJET Le Laboratoire d Informatique Interactive Le département mathématiques et informatique consacre une importante partie de son activité de recherche et d enseignement à l ingénierie des systèmes informatiques, et en particulier à l IHM. Il est co-habilité à délivrer des diplômes dans un master pro d ingénierie des systèmes interactifs (avec les universités Toulouse 1 et Toulouse 3) et un mastère d ingénierie système (avec l Ecole Nationale Supérieure de l Aéronautique et de l Espace). Le laboratoire d Informatique Interactive a été créé en Il est issu de collaborations croisées entre l ENAC, l ex Centre d Etudes de la Navigation Aérienne (CENA), et la société IntuiLab. Le laboratoire a pour mission de mener des recherches amont et transversales sur l ingénierie des systèmes interactifs, et les théories, modèles et outils informatiques associés. Le laboratoire bénéficie pour cela des expériences concrètes de développement de systèmes de ses partenaires. Il contribue au développement d outils géré par ces derniers. Sa première mission consiste à reprendre à sa charge les travaux de recherche fondamentale sur les problèmes rencontrés par ses partenaires, et collaborer sur leurs thèmes de recherche appliqués. Le laboratoire est dirigé par Stéphane Chatty et il est constitué de Stéphane Conversy, Yannick Jestin, Thierry Garcia, Hélène Gaspard-Boulin et de trois doctorants. Il est impliqué dans des projets sur les thèmes suivants : un thème Visualisation d information, perception, codage d information. Projets Kabuki, Anims un thème Techniques et styles d interaction : graphisme, animation, multimodal, geste. Projet Mammi un thème Modélisation des logiciels interactifs : architecture, exécution, langage Projets IntuiKit, Sauvage, Anims, Mammi, I* et Share-IT un thème Ingénierie des logiciels interactifs : méthodes de conception, génie logiciel multidisciplinaire Projets Erasmus, Callisco

18 CHAPITRE 1. CONTEXTE DU PROJET IntuiLab et son secteur d activité La société Intuilab, partenaire de l ENAC dans plusieurs projets de recherche, prend en charge la gestion administrative et financière de ce stage. Intuilab est une PME innovante créé en 2002 par trois chercheurs en IHM dont Stéphane Chatty. Elle s est depuis développée grâce à son expertise sur le domaine de l interaction Humain-Machine et s est spécialisée dans la réalisation de logiciels pour surface tactile (surface computing). Elle comporte actuellement 25 employés et elle a réalisé un chiffre d affaires de 1,8 millions d euros en Son offre se découpe en une branche matérielle, avec l Intuiface Surface Computer (anciennement Intuiface) et une branche service. Cette branche service se distingue par l emploi de méthodes de conceptions centrées utilisateurs et par une équipe pluridisciplinaire (ergonomes, graphistes, architectes, concepteurs), ainsi que par une expertise technique et l utilisation d ateliers de développement internes : Intuikit et Intuiface IntuiLab est spécialisée dans l idéation, la conception et le développement d applications interactives innovantes. IntuiLab couvre quatre domaines d expertise : la rénovation des interfaces de leurs clients, la numérisation des processus métiers, la transformation d idées en produits ou services intuitifs, l anticipation des modes d interactions innovants Cadre du travail : Projet ShareIT ShareIT est projet de recherche qui est commencé au début de 2008 pour trois ans et sponsorisé par Aerospace Valley. L objectif du projet est de concevoir et de tester les interfaces tactile qui seront partagé par le pilote et le copilote dans le cockpit d un avion. Cela nécessite des technologies multitouch et le projet comprend : la conception matérielle, faite par Stantum Expertise opérationnelle, introduit par l ENAC Analyse des besoins et des tests, effectués par Thales Avionics Interface design et le prototypage, effectué par IntuiLab Support logiciel pour le multitouch, réalisé par notre laboratoire à l ENAC.

19 CHAPITRE 1. CONTEXTE DU PROJET Présentation du travail demandé Le projet se situe dans le cadre des études de la gestion des dispositifs d entrée qui sont menées depuis longtemps et qui n incluent pas seulement les périphériques standards comme le clavier et la souris. Dans ce cadre, une étude doit être réalisée sur les différents dispositifs d entrée existants ainsi que leurs représentations dans les systèmes d exploitations et dans les publications scientifiques. Les modélisations existantes sont dans la plupart des cas dépassés par rapport aux nouveaux périphériques qui sont entrain d apparaître actuellement, que ce soit dans les publications scientifiques ou dans les modèles implémentés dans les systèmes d exploitation pour les gérer. Les modèles utilisés considèrent principalement le clavier et la souris comme périphériques principales d entrée, alors que les nouvelles innovations dans le domaine de l informatique ne font qu émerger de nouvelles modalités et techniques d interaction non habituelles et qui ont commencé à gagner le terrain, ainsi qu une utilisation courante comme les tabletop ou les ordinateurs de table. Il est demandé de faire émerger un modèle de gestion d entrée répondant aux nouvelles contraintes en fournissant des solutions pour les problèmes existants. Le but est aussi de minimiser l effort à faire pour les développeurs des pilotes des nouvelles périphériques s ils veulent échapper des limitations dues à l architecture des systèmes et des applications non adaptés à une gestion avancée de l entrée de l utilisateur. 1.3 Processus de développement adopté Le processus de développement adopté dans l élaboration de ce travail n est pas celui traditionnel et s attache en grande partie au processus IntuiSign développé par la société InuiLab [SVC04]. Ce processus suit 3 phases principales : La Datalyse Cette opération se résume à la collecte d informations et leur analyse (tâches de l utilisateur, systèmes existants, technologies disponibles, etc.) pour fournir le bon matériel pour la conception (cahier des charges, points clef de conception, tendances graphiques,

20 CHAPITRE 1. CONTEXTE DU PROJET 7 profiles utilisateurs, scénarios d usage, etc.). La procédure de la collecte d information contient aussi en grande partie l étude des publications scientifiques existantes comme source d information et d analyses anciennement effectués ainsi que l étude des scénarios réels d utilisation à partir de chaque profil éventuel d utilisateur Le Maquettage Cette étape consiste à créer des petites maquettes ou des bouts de code ou MashUps, appelé aussi code exploratoire. Cette exploration qui peut même aller dans les projets de pure IHM à utiliser des modèles papier. La programmation exploratoire, les illustrations et les évaluations élémentaires permettent de valider des choix et d éliminer d autres dans une étape assez préliminaire. Malgré le temps que coûte cette étape, elle permet de le rattraper en éliminant un temps qui sera consommé suite à l implication dans des mauvais choix à une étape assez avancée Réalisation et prototypage Cette étape consiste à la création de prototypes avancés pouvant être transformés en des produits finaux. Ce prototype sera un noyau pour la solution finale et il sera créé à la base des MashUps de la programmation exploratoire. La production itérative de prototypes aide à raffiner et illustrer les solutions et permettent une transition graduelle vers l implémentation finale. Figure 1.1 Méthodologie de travail IntuiSign TM

21 CHAPITRE 2 Étude préalable et état de l art Dans ce chapitre, on présente l état de l art des études scientifiques réalisées sur la gestion de l entrée. On les classe par sujet et domaine de recherche. On cite aussi les travaux sur l interfaçage multi-tactile. Et on termine par la présentation du protocole HID et ses sources scientifiques. 2.1 Gestion de l entrée Signification La méthode la plus commune pour transférer les ordres vers l ordinateur est de les passer à travers des périphériques spécifiques qui sont les périphériques d entrée. Toute personne qui utilise un micro-ordinateur est habituée à taper sur un clavier, cliquer sur des boutons, ouvrir des menus et déplacer un pointeur sur l écran. Les deux moyens physiques les plus utilisés sont alors sûrement le clavier suivi par la souris. C est une façon de contrôler une machine et elle présente en partie, un paradigme d interaction largement utilisé appelé WIMP Diversités des dispositifs et des paradigmes d interaction Depuis longtemps, les industriels ainsi que les chercheurs n ont pas cessé de proposer plusieurs dispositifs permettant de faire une tâche particulière d une façon plus rapide ou plus parfaite. Plusieurs nouveaux périphériques physiques sont apparus, des manettes de jeu, des contrôleurs midi, sans oublier les TrackPad ou les TrackPoint.

22 CHAPITRE 2. ÉTUDE PRÉALABLE ET ÉTAT DE L ART 9 Figure 2.1 Exemple de périphériques, tablette et TrackPen, manette Wiimote et une spaceball Vu le nombre très grand de ces dispositifs, certains constructeurs ont par exemple créé des objets qui substituent une souris en point de vue système mais qui ont des structures et des critères complètement différents. La substitution d une souris par un TouchPad ou un TrackPad est faite mais dans la majorité des cas on ne tient pas compte des avantages ou des inconvénients d une structure physique différente. Plusieurs études et des taxinomies ont été aussi élaborés comme réponse à cette diversité et pour extraire les spécificités éventuelles d un dispositif par rapport à un autre[bux83]. Mais à chaque fois, l utilisation d un périphérique ne tient pas toujours compte des résultats prouvés ou des taxinomies et elle est directement liée à celle que le développeur initial a choisi. Cette diversité de périphériques a impliqué une diversité d outils combinés à chaque dispositif. Il a alors fallu avoir un modèle qui facilite la gestion de périphériques malgré la diversité et réduit les problèmes Nécessité d un modèle Lorsqu on parle de diversité entre dispositifs, on doit parler aussi de la diversité dans l implémentation des pilotes et des sous-systèmes pour les gérer. Vu cette diversité universelle que ce soit coté pilote pour le noyau du système d exploitation ou même coté liaison directe avec les applications et la production des évènements, un modèle demeure nécessaire pour proposer une méthode commune pour simplifier la reconnaissance du dispositif en premier lieu puis la configuration et l adaptation en se basant sur les composites de ce modèle là. Un modèle unique ou au moins groupant la majorité des cas possibles doit éliminer une complexité de gestion hasardeuse dans les systèmes, faciliter la création des couches

23 CHAPITRE 2. ÉTUDE PRÉALABLE ET ÉTAT DE L ART 10 implémentant une nouvelle utilisation des périphériques mais il doit être aussi simple mais pas plus simple dans le sens où il ne faut pas réduire des caractéristiques primordiales. 2.2 Modèles et études Scientifiques L émergence des dispositifs physiques était le résultat de la coopération entre les scientifiques et les sociétés impliqués. Les études scientifiques ont permis d extraire les résultats des expériences et de les interpréter pour dégager les points forts d un dispositif et la meilleure application pour être utilisé avec Modèles de transition Des modèles de gestion des messages émis à l entrée sont aussi apparus afin de simplifier l interprétation des actions à exécuter pour le contrôle du système. L un des ces modèles est celui de la machine à trois états de William Buxton[Bux90]. Buxton a proposé une façon pour gérer les dispositifs de pointage qui consiste à faire une abstraction résumant l espace des évènements à une machine à 3 états. Figure 2.2 Modèle de transition à 3 états de Buxton Tout périphérique de pointage sera projeté sur la machine à trois états et les évènements gérés sont un sous ensemble de la machine globale, il a donc simplifié énormément la partie de gestion de ce genre de dispositifs dans le système d exploitation. Et la gestion sera géré de façon déterministe.

24 CHAPITRE 2. ÉTUDE PRÉALABLE ET ÉTAT DE L ART 11 Figure 2.3 Application du modèle sur la souris Étude des performances et expérimentation Plusieurs études de performances ont été effectuées sur des tranches de personnes afin d analyser les caractéristiques des dispositifs et de les classer en terme d adaptabilité[jsmj94]. L étude de Jacob a permis de dire que chacun des périphériques est adapté pour faire une tâche d une façon meilleure qu un autre. Il a aussi précisé qu en terme de contrôlabilité, on peut subdiviser les périphériques en sous composants décrits par la notion de la séparabilité et qu il n est pas possible pour d autres décrite par la notion de l intégralité. Des dimensions séparables selon Jacob peuvent être contrôlés séparément sans nuire ni aux performances finales ni à la précision comme le contrôle des couleurs d un objet et ses dimensions. Alors que les critères intégraux ne peuvent pas être séparés en contrôle et préserver les performance. Et on prend comme exemple le contrôle des dimensions selon les axes x et y dans une souris. Cette étude est très importante car elle explique pourquoi la substitution d une souris, où le contrôle des axes se fait simultanément, ne peut pas être remplacée par une manette contenant des boutons ou des flèches séparés pour ce même contrôle. On a donc une étude qui nous guide sur les limites de la configuration et le morphisme entre dispositifs Taxinomie des dispositifs Vu que l espace des périphériques ainsi que les caractéristiques de chacun est entrain de s exploser, les chercheurs ont établi plusieurs taxinomies pour classifier les dispositifs.

25 CHAPITRE 2. ÉTUDE PRÉALABLE ET ÉTAT DE L ART 12 Après avoir fait cette répartition et indexation la gestion sera faite selon les critères décrites. Buxton a classé les périphériques dans son papier[bux83] sur un tableau selon les deux critères des propriétés physiques sentis et le nombre de dimensions reportées. Ce classement donne une première idée sur l impossibilité d un dispositif à être utilisé dans un contexte impliquant plus de dimensions (réf. Figure.2.4). Figure 2.4 Taxinomie de Buxton D autres études ont suivi pour étendre les taxinomies existants, dans les deux papiers de Card[CMR90, CMR91] il a parlé du classement en tenant compte des propriétés structurelles d un périphérique. Il a donc présenté les notions de la précision, de la vitesse, des erreurs, du temps nécessaire à apprendre à utiliser et même la quantité nécessaire de données à transférer entre le périphérique et l ordinateur pour rapporter l évènement. Cette étude de Card semble la plus complète puisqu elle fait intervenir un grand nombre de critères pour le classement et en ajoutant une étude d hiérarchie entre les petits composants dans un seul dispositif. Dans la figure précédente (réf. Figure.2.5) on remarque un classement des anciens dispositifs, mais aussi une démontration des zones vides qui peuvent influencer la construction de nouveaux périphériques supportant ces dimensions non encore exploitées.

26 CHAPITRE 2. ÉTUDE PRÉALABLE ET ÉTAT DE L ART 13 Figure 2.5 L espace de conception de Card [CMR90] L utilisation de plusieurs dispositifs Des anciens études ont imaginés des interactions avec plusieurs dispositifs en même temps et avec les deux mains. L une de ces publications[cha94] a montré l importance de la configuration sur un processus similaire pour spécifier les objectifs de chacun des matériels utilisés. Dans la figure précédente qui représente un ancien système de configuration de l entrée appelé Whizz(réf. Figure.2.6), l utilisateur contrôle un trait à l aide de deux pointeurs de deux souris. D autres études plus récentes ont repris ce même point en présentant un modèle de configuration qui commence par le filtrage des sources de l entrée jusqu à l encapsulation de ces sources et l ajout d adaptateurs[clv07]. L hiérarchie a été aussi étudié et un dispositif est représenté en tant qu un arbre de plusieurs sous composants.

27 CHAPITRE 2. ÉTUDE PRÉALABLE ET ÉTAT DE L ART 14 Figure 2.6 L utilisation de deux souris avec deux mains dans la plateforme Whizz Les systèmes multi-tactiles Les systèmes multi-tactiles sont les systèmes qui ont le plus de succès ces dernières années, vu que des grandes sociétés investissent dans l amélioration de ce genre de périphériques. Figure 2.7 Les surfaces computer : Microsoft Surface et IntuiFace d IntuiLab Les surfaces multi-tactiles sont les derniers périphériques appliquant la notion de la manipulation directe inventé par Shneiderman[Shn97]. La manipulation directe décrit les systèmes où ont a une visibilité des objets d intérêt et des actions possibles, ces actions sont rapides, réversibles et incrémentales. Dans ce genre de manipulation on a un remplacement d une syntaxe complexe par des actions simples semblables aux manipulations dans la vie réelle.

28 CHAPITRE 2. ÉTUDE PRÉALABLE ET ÉTAT DE L ART Émergence de la configurabilité Après l émergence des dispositifs en nombre et en fonctionnalités, des études sont apparus pour gérer la configuration des périphériques. Les travaux autour de ICon (Input Configurator) sont ceux les plus évolués. ICon est un prototype logiciel qui permet d utiliser les entrées des dispositifs physiques et de les lier de façon graphique à des adaptateurs pour modifier dynamiquement leur fonctionnement sur une application de dessin. L utilisateur place les blocs désignant les entrées de manière à avoir une sortie pour chaque variable, puis les lient à des adaptateurs comme les sommateurs ou des multiplicateurs pour modifier le flux. Le modèle était l un des premiers à avoir mis en cause la façon classique et statique d utiliser les périphériques et proposer des définitions pour la configurabilité et l accessibilité. Figure 2.8 Exemple de configuration de l entrée avec ICon Dans la figure (réf. Figure.2.8) on voit comment les entrées provenant de la tablette Wacom sont connectées aux options de l application. L unité d entrée indiquant la pression est utilisée pour modifier la grandeur du trait pendant le dessin. Les autres entrées sont utilisés pour le déplacement de façon équivalente à une souris. Le problème du modèle de Dragicevic[DF04] est qu il ne propose pas une représentation des unités d entrées dans un seul dispositif de façon dynamique. On doit créer les modèles des dispositifs en avance et ceux virtuelles provenant d une combinaison entre plusieurs dispositifs ne sont pas applicables. Il n y a pas aussi une liaison directe entre le configurateur et les applications du bureau, et il faudra passer par des liens pour exporter cette configuration. L autre étude de configuration[wm03] ne traite que deux périphériques qui sont le clavier et la souris malgré que le papier présente un traitement des unités d entrée avec des petites opérations algébriques.

29 CHAPITRE 2. ÉTUDE PRÉALABLE ET ÉTAT DE L ART Modèle HID Présentation Le modèle HID, ou Human Interface Device est un standard faisant partie du protocole USB et élaboré par la majorité des grandes sociétés de production de périphériques ou de systèmes tel que Microsoft, Intel, Logitech et plein d autres. Ce consortium d entreprises s est groupé pour trouver une solution permettant de faciliter la gestion des nouveaux périphériques. Une gestion de façon à simplifier la création de pilotes pour les systèmes d exploitation. Avant ce modèle là, les constructeurs doivent choisir entre deux solutions : Soit se contenter aux standards existants qui sont très limités mais ayant un support dans tous les systèmes. Soit utiliser un autre standard mais fournir les pilotes sur tout les configurations pour être fonctionnel. Les industriels choisissaient la première solution, mais suite à l évolution qui est apparue et de l émergence des technologies, ils ont vu la nécessité d un modèle dynamique pour la découverte des composants d un dispositif quelconque Principe du modèle Le modèle consiste à créer un pilote HID unique dans les systèmes d exploitation et une partie présentatrice embarquée dans les périphériques. Le dispositif, une fois branché à l ordinateur, entre dans une procédure d identification en envoyant un rapport(réf. Figure.2.9) décrivant les petits composants qui le constituent avec l hiérarchie, les domaines des valeurs ainsi que l unité et en allant à proposer la meilleure utilisation. Figure 2.9 Principe du transfert HID Le pilote reçoit les informations du descripteur report descriptor, et analyse les éléments de ce rapport puis constitue en mémoire le modèle permettant de faire fonc-

30 CHAPITRE 2. ÉTUDE PRÉALABLE ET ÉTAT DE L ART 17 tionner le périphérique. Le consortium des USB Implementors a aussi publié des tables d usages fournissant les différents possibilités qu un report descriptor peut fournir pour chaque gamme de périphériques. Le modèle HID est aussi développé d une façon à fournir même un descripteur physique pour spécifier pour chaque item quel est le meilleur membre du corps humain à utiliser Limites du modèle Le modèle HID constitue un grand saut permettant de faciliter aux constructeurs de périphériques ainsi qu aux producteurs des systèmes d exploitation la reconnaissance des nouveaux matériels. Mais malgré ça, il ne permet pas de modifier et dynamiser une configuration des options fournies selon les besoins de l utilisateur. 2.4 Conclusion Dans ce chapitre, on a présenté les principales études scientifiques qui ont traité la gestion de l entrée en relation avec nos travaux. On a aussi exposé le modèle HID en tant que modèle très utilisé et qui a été inventé pour faciliter cette gestion dans les systèmes d exploitation. Il nous faut maintenant spécifier les scénarios possibles d utilisation depuis lesquelles on extrait les besoins.

31 3 Spécification CHAPITRE 3.1 Méthodologie participative Comme décrit dans le papier [SVC04], la méthodologie utilisée fût celle itérative et participative. Cette manière de résoudre et gérer les projets permet d impliquer un groupe de personnes de façon opposé à l ancienne méthodologie, où seulement chacun doit présenter un résultat à la fin sans parfois que les autres membres et chercheurs soient conscients de chaque étape qu il a atteint, et s il a participé ou non aux choix et la modification des solutions. Cette méthode(réf. Figure.3.1) permet d incorporer les idées des personnes du groupe et de répartir la responsabilité sur tout les membres mais aussi de partager la réussite. L extraction des besoins ont comme source les scénarios d utilisation réelle suite à des questionnaires posés sur des personnes et interprétés ensuite selon les détails de chaque personne. Figure 3.1 Conception itérative et participative Le fait de baser toute l étude, ou une grande partie, sur des personnes permet d élargir le domaine de connaissance et d imagination au delà de celui du développeur.

32 CHAPITRE 3. SPÉCIFICATION 19 Les prototypes ainsi créés, trouveront donc une utilisation et ne seront jamais jetés comme est le cas avec de nombreuses applications développées sans utiliser cette méthodologie puis refusées par les utilisateurs. Les prototypes créés vont ensuite être améliorés, pour faciliter aux utilisateurs l expression de leurs besoins et les modifications sur une application fonctionnelle. Le fait d ignorer ou de sous-estimer les scénarios est grande erreur que malheureusement beaucoup de développeurs commettent, alors qu il n existe aucun moyen meilleur d extraire les informations et les détails depuis un scénario. Dans les autres cas, le développeur peut tomber dans l erreur de faire trop d abstractions ou oublier des détails parfois primordiales. 3.2 Scénarios d utilisation Scénario 1 Utilisation de la wiimote comme une télécommande ou une souris : Anne est une étudiante à l ENAC, elle a un abonnement ADSL avec des chaines de télévision gratuites qu elle peut regarder sur son PC. Elle possède aussi une console de jeu Wii. La console de jeu est livrée avec une manette Wiimote, qui entre autre utilise un protocole de communication Bluetooth. Le PC d Anne supporte la communication Bluetooth mais elle ne connait pas beaucoup de détails sur la communication. Elle veut utiliser la manette Wiimote pour remplacer ou émuler une souris sans fil. Elle veut aussi mapper les boutons sur la wiimote pour spécifier des opérations de changement de chaine ou de commande du volume. Elle veut faire ça sans se plonger dans les détails techniques et en utilisant une interface graphique simple Scénario 2 Régler la vitesse d affichage des messages d un sniffeur USB : Sébastien Hamdani est un étudiant en première année à l ENAC, il fait son stage au laboratoire d informatique interactive. Son stage consiste à produire un pilote Linux pour la table multi-utilisateur DiamondTouch et la surface multi-tactile Stantum. Les deux périphériques utilisent le port USB, et pour qu il réussisse à produire un

33 CHAPITRE 3. SPÉCIFICATION 20 pilote fonctionnel, il doit utiliser un sniffeur USB qui enregistre toute les entrés-sorties depuis un port USB choisis au début de la phase. Il doit toucher à chaque fois les tables pour générer une communication USB vers son PC et avec une méthode d ingénierie inverse il regarde les changements sur son écran pour savoir quel sont les champs qui changent de valeurs et quels sont les domaines des valeurs émis. Il modifie ensuite son pilote et le recharge dans le noyau et teste s il réussit à interpréter les données correctement. Le problème est que dans la majoritée des cas, le flux de données échangées est très rapide et il ne réussit pas à le suivre. Il aime pouvoir régler la vitesse de défilement, les champs à afficher et le domaine de tolérance pour la mise à jour des champs. Il aime régler ces valeurs en utilisant un autre périphérique d entrée comme une contrôleur midi et que les changements de ces options se font de façon dynamique. Ceci lui permet de gagner plus de temps pour découvrir le protocole. Exemple des informations brutes les plus lisibles provenant d une entrée usb : f65852c C Ii:4:004:1 0:8 4 = 0000ff00 f65852c S Ii:4:004:1-115:8 4 < f65852c C Ii:4:004:1 0:8 4 = 0000fe00 f65852c S Ii:4:004:1-115:8 4 < f65852c C Ii:4:004:1 0:8 4 = 00fffe00 f65852c S Ii:4:004:1-115:8 4 < f65852c C Ii:4:004:1 0:8 4 = 0000fe00 f65852c S Ii:4:004:1-115:8 4 < f65852c C Ii:4:004:1 0:8 4 = 0000fe00 f65852c S Ii:4:004:1-115:8 4 < f65852c C Ii:4:004:1 0:8 4 = 0000fe00 f65852c S Ii:4:004:1-115:8 4 < Scénario 3 Émulation de la souris pour les mouvement complexes : Olivier Saraja est le responsable du groupe d utilisateurs du logiciel Blender à Toulouse, un designer intéressé par les logiciels graphiques sous Linux, et il est membre de l association Tou-

34 CHAPITRE 3. SPÉCIFICATION 21 lousaine Toulibre. Il utilise Blender pour la création d animations vidéos. Il utilise aussi dans beaucoup de cas les logiciels de dessin Inkscape et Gimp. Dans des nombreuses fois, il voulait créer des figures artistiques avec l outil de plume dans Gimp et les exporter à Blender mais il n obtient pas des bonnes figures. S il essaye d utiliser les outils qui sont fournis par défaut il perd beaucoup de temps. Gimp contient possède un langage de script pour l automatisation des dessins, mais il n a pas le temps d apprendre un nouveau langage et veut qu il aura des outils graphiques pour spécifier ses besoins. Il veut utiliser l outil de dessin dans Gimp et pense que théoriquement, les figures qu il veut dessiner sont faisables s il aura la possibilité de déplacer la souris parfaitement sur des mouvements continus de va et vient sur chaque axe. 3.3 Brainstorming Définition Le Brainstorming 1 est une technique de résolution créative de problèmes sous la direction d un animateur, un remue-méninges étant plus spécifiquement une réunion informelle de collecte d idées. Cette technique a été conçue en 1935 par Alex Osborn, vice-président d une agence de publicité américaine. C était à l origine une méthode de réunion de groupe soigneusement préparée puis tout aussi soigneusement exploitée pour trouver un nombre important d idées publicitaires et promotionnelles pour les clients et les clients potentiels de l agence Principe La principale promesse de la méthode est la récolte d idées nombreuses et originales. Deux principes sous-tendent le brainstorming : la suspension du jugement et la recherche la plus étendue possible. Ces deux principes se traduisent par quatre règles : ne pas critiquer, se laisser aller freewheeling, rebondir hitchhike sur les idées exprimées et chercher à obtenir le plus grand nombre d idées possibles. 1 source : http ://fr.wikipedia.org/wiki/brainstorming

35 CHAPITRE 3. SPÉCIFICATION 22 Ainsi, les suggestions absurdes et fantaisistes sont admises durant la phase de production et de stimulation mutuelles. En effet, les participants ayant une certaine réserve peuvent alors être incités à s exprimer, par la dynamique de la formule et les interventions de l animateur Méthode Pour réussir une séance de Brainstorming, l animateur doit préparer des catalyseurs pour inciter les intervenants à s exprimer. Ces scénarios peuvent parvenir des questionnaires déjà posés sur les utilisateurs. D autres courts documents jugés intéressants peuvent aussi être apportés pour étendre le domaine de suggestions. L animateur doit veiller pour que les présents ne brisent pas les règles surtout celle de la critique des idées posées dans la phase de la collecte. L animateur ou l un des intervenants doit aussi exprimer des idées trop imaginaire pour débrider la créativité en exprimant toutes ses idées sans réserve et sans autocensure. Les intervenants peuvent rebondir sur celles des autres et les améliorer car la quantité d idées est importante. Et ne jamais critiquer les idées des autres qui résultera en un découragement des gens à parler. Figure 3.2 Le résultat d un Brainstorming À la fin de la séance on commence à exploiter les idées recueillies en les reformulant, classant, hiérarchisant sous une forme synthétique(réf. Figure ) comme, par 2 source : http ://lateralaction.com/articles/brainstorming/

36 CHAPITRE 3. SPÉCIFICATION 23 exemple, sous la présentation d une grille de décision. Les présents peuvent ensuite valoriser les meilleures idées en les affectant des pondérations. 3.4 Extraction des besoins Après avoir questionné les quelques personnes et ayant effectué des séances de brainstorming, qui étaient malheureusement limités en nombre de personnes et en temps, on peut maintenant extraire les besoins, sans quant même oublier les études bibliographiques déjà cités auparavant Émergence d un modèle D après les études bibliographiques, le présent travail doit faire émerger un modèle de représentation de périphériques qui s ajoute aux modèles précédents et avec qui présente une abstraction se généralisant à un grand nombre de périphériques. Cette abstraction permettra de faciliter la suite du travail Intégration au système Linux Tout le travail doit être fonctionnel sur le système Linux. Il doit utiliser les primitives du système existantes et permettre d ajouter ses nouvelles méthodes et fonctionnalités sans causer des problèmes aux autres composants ou les désactiver. Le prototype ne doit pas désactiver des parties du système. Il doit s additionner comme une méthode supplémentaire facile à ajouter et à supprimer pour inciter les utilisateurs de ce système à l intégrer chez eux tout en permettant toujours les autres méthodes des fonctionnements ordinaires Interface de configuration Le prototype à faire doit permettre une configuration de la gestion de l entrée. C est à dire il doit router les entrées vers des systèmes de modification du flux puis générer d autres entrées ou des commandes directes aux applications du système. L utilisateur pourra donc choisir comment gérer ses entrées sans lui imposer une seule configuration

37 CHAPITRE 3. SPÉCIFICATION 24 particulière. 3.5 Conclusion Dans ce chapitre, nous avons procédé grâce à une méthodologie participative et itérative à définir les besoins du projet. Nous avons cherché au début des scénarios réels d utilisation puis nous avons enrichi les scénarios par des séances de Brainstorming. Et enfin nous avons extrait les besoins principaux du travail.

38 CHAPITRE 4 Analyse et conception élémentaire Dans ce chapitre, nous analysons de façon élémentaire les systèmes d entrée impliqués dans notre travail et nous procédons à une conception pour chacun des cas aux solutions possibles à intégrer. 4.1 Analyse des systèmes Pour réussir la réalisation des composants demandés, et pour appliquer le modèle de travail déjà expliqué. On doit analyser chaque partie du système général de la gestion d entrée de Linux pour dégager toutes les solutions possibles d intégration Système de gestion d entrée de Linux Le système de gestion d entrée d un système Gnu-Linux se décompose en deux grandes parties. La première des deux se situe dans le noyau du système lui même, les développeurs noyau ainsi que quelques concepteurs de dispositifs créent un pilote de leur périphérique et l envoient à la mailing-list respective du noyau pour qu il soit intégré aux prochaines versions. Les pilotes soumis, contiennent les primitives bas niveaux d accès au matériel et permettent de présenter un interface des messages émis. Ensuite, pour gérer les entrées depuis le noyau vers l interface graphique, c est maintenant le rôle de Xorg et plus précisément le module d entrée pour faire la gestion principalement du clavier et la souris et des périphériques semblables pour les applications graphiques lancés. L environnement Xorg est câblé pour être utilisé avec seulement une

39 CHAPITRE 4. ANALYSE ET CONCEPTION ÉLÉMENTAIRE 26 souris ayant au maximum 5 boutons, et un clavier ordinaire. Pour faire fonctionner une souris spéciale ou d autres dispositifs, il faut passer par des hack ou la soumission de pilotes à l intérieur du module d entrée de Xorg. Figure 4.1 Abstraction de la constitution du système Linux Système HID du noyau Linux Le port USB et les périphériques USB sont devenus ceux les plus utilisés suite à l utilisation de ce standard pour une large gamme de périphériques et les larges possibilités fournies. Le système HID qui est une sous partie du protocole USB, est majoritairement utilisé pour gérer les périphériques d entrée grâce à sa simplicité et sa capacité à s adapter aux options des nouveaux périphériques qui apparaissent. En ce qui concerne le noyau de Linux, la grande partie de la gestion de son entrée est codé pour supporter le modèle HID. Ce support là est en lui même un sous-système complet, il est composé d un parseur qui analyse les paquets du rapport HID et instancie le modèle du périphérique. il est aussi constitué de sous modules/pilote pour lier les entités des périphériques au messages qu il doit émettre. Et sans oublier un système de gestion des exceptions dans le cas où certains constructeurs ne respectent pas la spécification du modèle.

40 CHAPITRE 4. ANALYSE ET CONCEPTION ÉLÉMENTAIRE Communication DBus Utilité Les utilisateurs de la console Linux, ont parfois besoin de passer des données d une application vers une autre et pour répondre à ceci ils n ont qu à utiliser les tubes ou les fichiers et créer des fichiers de script. Mais dans les systèmes graphiques, faire passer les données et les commandes doit se faire d une autre façon. Le support de communication inter-application existe même dans Xorg, mais il est très limité à des opérations de copier-coller sans aller plus loin. Les créateurs des environnements graphiques au dessus de Xorg tel que KDE ou Gnome ont choisi de se baser sur leurs propres systèmes de communications pour commander une application depuis une autre ou pour transférer quelques données Historique, Dcop, Bonobo, Corba Au début, chaque environnement a créé son propre système, sous les premières versions de KDE le système était appelé Dcop, et sous Gnome il était appelé Bonobo. Chacun des systèmes utilisait des notions de communications différentes et des modèles différents s inspirant parfois de Corba. Ensuite les développeurs de chacun des environnements ont voulu standardiser la façon de communiquer entre les applications des deux environnements qui étaient séparés et corriger les failles conceptuels des anciens modèles. Et c est pour celà qu ils ont lancé DBus Principe DBus consiste en un serveur satellite dans Linux, dans le langage UNIX il est appelée Daemon. Le serveur permet de router les communications d une application vers une autre. Et chaque application qui le supporte doit s enregistrer dès son ouverture et se connecter à ce serveur. Elle exporte la liste de ses méthodes internes qu elle veut exporter, dans la majorité des cas effectué automatiquement, et les autres applications auront donc un accès interne aux méthodes exportées.

41 CHAPITRE 4. ANALYSE ET CONCEPTION ÉLÉMENTAIRE Étude des périphériques Dans cette partie, on résume les travaux effectués pour étudier le fonctionnement interne de certains périphériques durant le stage. L étude de ces périphériques, qui sont en majorité des périphériques multi-tactiles, a pour but de comprendre le fonctionnement et pouvoir ensuite proposer un modèle qui les supporte Les Phidgets Les phidgets(réf. Figure.4.2) sont des capteurs génériques de vitesse, d accélération, des gyroscopes, des capteurs RFID. Ils partagent tous une connexion USB pour chacun des capteurs. Ces périphériques, en tant que vrai exemple d unités d entrée soulignent que dans le modèle à proposer, qu il devra traiter ces unités de façon minimale et que les autres périphériques les plus complexes peuvent se constituer de ces parties. Figure 4.2 Quelques phidgets : des boutons, des sliders et des capteurs divers Les Surface-Computers Ce sont les premiers appareils à apporter la notion des surfaces multi-tactiles. On peut interagir sur la surface avec un ou plusieurs doigts au lieu d un seul uniquement. Plusieurs utilisateurs peuvent aussi interagir et communiquer. L étude de ce genre

42 CHAPITRE 4. ANALYSE ET CONCEPTION ÉLÉMENTAIRE 29 d appareils permet de comprendre ce que signifie ce nouveau genre d interaction et comment est déjà géré. Le support des messages de l entrée provenant de ce genre de périphériques ne peut pas être intégré dans les noyaux des systèmes. Donc la gestion restera dans l espace utilisateur, et le contrôle sera fait directement ou dans les cas nécessaire envoyé vers le noyau du système Tablette Wacom La tablette Wacom, qui permet d émuler une souris mais tout en ajoutant d autres caractéristiques de simplicité et des critères de pression et de rotation ouvre la vue vers la notion de l extension des modèles habituels avec des composants s alliant avec elle. Ces extensions sont à cacher sous un modèle qui peut grouper les unités d entrée cités en addition avec celles-ci. Figure 4.3 Tablette Wacom La figure précédente(réf. Figure.4.3) montre comment cette tablette intègre un slider et des boutons dans chaque partie de l écran tactile. Qui peuvent être vue comme les composants d une même souris mais répétés avec un identifiant pour chacun et suivant une hiérarchie d attachement.

43 CHAPITRE 4. ANALYSE ET CONCEPTION ÉLÉMENTAIRE Table DiamondTouch La table MERL DiamondTouch est une table permettant de différencier jusqu à quatre utilisateurs interagissant en parallèle. La notion de multi-utilisateur est presque inconnue dans les autres périphériques. La table utilise un mécanisme transformant chacun des utilisateurs en une antenne en les liants à un type de signal émis. Le modèle, pourra donc accepter d instancier plusieurs fois un même type de dispositifs Tablette Stantum La tablette Stantum est un écran TFT combiné à une technologie qui permet de reporter les évènements multi-tactiles qui figurent à la surface. La tablette n est pas encore un produit finalisé et l un des objectifs de notre travail au laboratoire est de créer un pilote pour la rendre fonctionnel sous Linux. Étant un périphérique USB HID, le pilote créé suivra le modèle défini. La notion des périphériques multi-tactiles n existait pas avant sous Linux. Et c est pour ceci que beaucoup de temps a été consacré aux discussions sur les types de messages à intégrer dans le noyau et la façon avec laquelle le noyau doit gérer le multitouch. 4.3 Conception élémentaire et Solutions Intégration du configurateur au noyau Linux L une des solutions pour la création d un configurateur d entrée pour Linux est de l intégrer directement dans le noyau. Ainsi, la notion des périphériques virtuelles et des unités d entrée devra aussi être proposée pour l intégration. Le résultat d une telle solution est un fichier de patch de très grande taille, et une modification intense à l intérieur du noyau. Si on sache que les développeurs du noyau doivent être convaincus pour les plus petits changements, alors on peut directement savoir qu une telle solution est impossible à être acceptée. La gestion interne dans le noyau ne supporte que les options d accès bas niveau et de génération de messages systèmes. Tout autre système dit révolutionnaire doit être une option à part et sera automatiquement refusé d après la Documentation officielle du noyau.

44 CHAPITRE 4. ANALYSE ET CONCEPTION ÉLÉMENTAIRE Création d un daemon séparé Un daemon est un processus séparé du noyau, qui s exécute en arrière plan. Il peut communiquer entre les deux mondes du système d exploitation qui sont le user-space et le kernel-space. Réaliser le configurateur d entrée en tant que daemon permet une intégration beaucoup plus facile puisque on ne modifie pas le code du noyau et le serveur reste accessible depuis l espace utilisateur pour les applications. L utilisation du daemon est donc la solution à garder pour réaliser le configurateur d entrée Intégration à la chaine traditionnelle d entrée On signifie par la chaine traditionnelle d entrée la chaine commençant par le noyau lui même en passant par le serveur Xorg et allant vers les applications. Si on applique les principes du configurateur à proposer des unités d entrée à composer pour créer des périphériques virtuels, on sera amené à générer à chaque fois des pilotes noyau, puis de créer des pilotes Xorg. Puisque ce dernier est déjà composé de module dont celui du la gestion d entrée XInput, et qui est lui aussi composé de pilotes pour chaque périphérique. En résumé, on sera amené à générer une quantité très grande de code, sans aucune garantie de stabilité de fonctionnement et d efficacité Accès DBus aux applications Les applications Linux sont compilées en donnant la possibilité aux autres à appeler leurs méthodes internes. Cet avantage n est possible qu avec DBus, qui est un protocole de communication inter-applications. Le support de DBus intégré dans les nouvelles bibliothèques tel que Qt et GTK, permet d automatiser la procédure d exportation des méthodes à l aide des macros. C est un très grand avantage puisque le configurateur aura la possibilité de communiquer directement aux applications sans entrer dans les limitations et la complexité du serveur Xorg.

45 CHAPITRE 4. ANALYSE ET CONCEPTION ÉLÉMENTAIRE Principe d injection des évènements L injection des évènements consiste à émuler la génération physique des messages d input depuis les périphériques. Le système qui génère les évènements est situé dans l espace utilisateur, il communique avec le noyau Linux à travers un module spécifique appelé uinput et lui envoi la structure de donnée contenant les détails du message. Le message qui n est autre qu une structure en C contient le type du message, le code du message et la valeur. Et une fois les évènements injectés, il suivent la chaine traditionnelle d entrée comme s ils parviennent d un périphérique physique. L injection des évènements dans le noyau permet d éviter l écriture de pilotes noyau et d autres Xorg pour chaque périphérique virtuel créé. On aura aussi la liberté de générer n importe quel évènements supportés de l ensemble des autres périphériques Validation des choix D après les études précédentes, on remarque qu on est obligé de créer un daemon séparé pour la gestion avancée de l entrée et de la configuration. Pour encourager les créateurs de distributions Linux d intégrer notre code. On élimine aussi le choix de passer par les chemins que prend l entrée en réalité en passant par le noyau puis par Xorg, puisque on sera obligé de créer un pilote pour chaque configuration imaginée. On opte donc dans ce cas à l injection des évènements en tant que périphériques standards. Et en dernier lieu, l invocation de messages DBus fournit un très large contrôle sur le domaine des applications et on surpasse le serveur Xorg ce qui signifie qu on élimine ses limites. 4.4 Conclusion Dans ce chapitre, nous avons analysé les domaines d applications de notre travail. Nous avons examiné d abord les systèmes sur lesquelles ont va interagir puis les périphériques que nous devons supporter. Nous avons ensuite procédé à faire des propositions de conceptions et validé ceux qui sont applicables.

46 CHAPITRE 5 Modélisation et Prototypage Dans ce chapitre, nous exposons les premiers fruits de notre étude qui commencent par la modélisation de l entrée puis nous présentant les prototypes d implémentation réalisés. 5.1 Modélisation D après l état de l art des papiers scientifiques, les scénarios et les besoins extraits, l analyse et conception élémentaire et toutes les études précédentes, nous proposons ici notre modèle de représentation, de gestion et de configuration de dispositifs d entrée Unités minimales d entrée La chose commune entre les dispositifs d entrée si on raisonne du coté des transferts bas niveau, est l existance de petites entités transférées. Ces éléments ou unités minimales d entrée ont des structures très simples, et sont associés, surtout dans un modèle comme celui du HID, à des propriétés et des caractéristiques additionnelles définissant l ordre de grandeur, l unité et l utilisation. Figure 5.1 Unités d entrée minimales

47 CHAPITRE 5. MODÉLISATION ET PROTOTYPAGE 34 Nous adhérons à ce modèle là, et on propose une amélioration dans les propriétés des items. On propose d augmenter l espace des propriétés et inclure ces dernières directement dans l élément représentatif lui même. Les transferts utilisaient le modèle standard conçu, mais la représentation dans la mémoire d un périphérique sera alors une hiérarchie entre ces unités d entrée, ayant les caractéristiques dans les unités eux mêmes, et non dans les racines de l arbre. Ceci éliminera une gestion de flux et un traitement face à des ajouts mémoire. Mais le plus important est que le modèle restera simple à gérer et unique pour une grande partie des dispositifs Représentation d un périphérique Un périphérique est donc d après ceci une hiérarchie entre plusieurs unités d entrée gérées de la même façon et qu on peut après ajouter des traitements qui seront applicables sur un dispositif A comme un autre B, même s ils sont physiquement différents. Figure 5.2 Représentation d un périphérique Le modèle HID ainsi que d autres papiers scientifiques ont traité en partie une représentation similaire, mais aucun d eux n a facilité l exportation des unités d entrée vers l espace utilisateur de façon simplifiée et combinée à la notion de configuration Projection de la configuration L un des limites du modèle HID est la non possibilité de modifier les propriétés des items dynamiquement et avec le contrôle de l utilisateur final. Ils sont embarquées dans

48 CHAPITRE 5. MODÉLISATION ET PROTOTYPAGE 35 le dispositif lui même et traitées par le parseur du système d exploitation pendant la phase de reconnaissance. Faire approcher la configuration à l utilisateur finale lui permet une plus grande liberté d utiliser son périphérique dans d autres contextes et même de le voir autrement. Figure 5.3 Principe d inclusion de la configuration dans le modèle Dans l exemple qui précède(réf. Figure.5.3), une propriété de configuration consiste à changer l intervalle initial et de l exporter vers un autre domaine. On montre dans ce cas comment il est simple d inclure l intervalle de sortie dans les propriétés de l unité de l entrée elle même et de faire l exportation suite à une opération mathématique simple. 5.2 Prototypage des modèles Communications DBus DBus est un outil permettant de faciliter la communication entre les applications dans les systèmes Linux. Mais il n a pas été imaginé ou utilisé en tant qu un outil de commande après traitement de l entrée utilisateur. En effet, le fait que les applications sous Linux sont conçues de façon à exporter leurs méthodes internes et de les exposer aux autres applications à travers DBus, nous inspire une vue particulière envers l espace des applications. On peut voir cette espace comme étant unifié sans les bords habituels puisqu on a garanti un accès horizontal. Ce qui reste est de proposer un système situé entre le noyau Linux et ces applications pour faire la gestion ce qui se résume à notre configurateur. Comme montre la figure(réf. Figure.5.4), on instancie une nouvelle gestion de l entrée avec laquelle on élimine l ancien contrôle des systèmes comme Xorg. Cette élimi-

49 CHAPITRE 5. MODÉLISATION ET PROTOTYPAGE 36 Figure 5.4 Architecture de la communication DBus utilisée nation est très avantagieuse puisque on sera libre et on sort des limites du protocole X11 de Xorg créé dans les années 80, et nécéssitant maintenant des astuces de programmation pour supporter les nouvelles options de ces dernières années. La communication DBus a été utilisé dans la production du premier prototype montrant la possibilité pour un système Linux de gérer une entrée multi-tactile. Le système Xorg est totalement ignoré puisque les communications passerait à travers DBus. L exemple a montré la grande liberté acquise et des options non possible même dans les autres systèmes. Dans les autres systèmes, pour qu ils supportent la gestion multi-tactile, ils ont eu seulement deux possibilités, soit réécrire les applications, soit utiliser cette gestion dans un environnement fermé (comme dans le cas de la Microsoft-Surface ). Alors qu ici, nous avons le contrôle des applications habituels pour supporter le multi-tactiles et d autres futures technologies sans être obligé à les réécrire. On utilise seulement la configuration à travers un daemon de gestion de l entrée Injection de l entrée La communication DBus, peut dans certains cas être limitée. Cette limitation provient du fait que les concepteurs des applications n ont pas exporté toutes les méthodes, ou l accès aux possibilités reste limité. Le principe de l injection de l entrée consiste à lire les messages émis par un autre

50 CHAPITRE 5. MODÉLISATION ET PROTOTYPAGE 37 périphérique puis de communiquer avec le noyau et de lui demander de générer des messages, comme s ils étaient émis par des dispositifs réels. Les messages d entrée qui ne proviennent plus de sources physiques, suit le parcours de la gestion d entrée standard sans que l application où on veut l utiliser se rend compte. L injection nécessite émuler la structures des messages originaux de l entrée. C est à dire envoyer des structures de données contenant la valeur de l entrée, le type et le code. Figure 5.5 Architecture de l injection de l entrée Dans l exemple de prototype que nous fait, le configurateur cherche à modifier l entrée d une souris avec l injection de messages. Ces messages sont créés selon les paramètres d un autre dispositif utilisé pour gérer dynamiquement les options d injection comme la vitesse et la valeur. 5.3 Conclusion Dans ce chapitre, nous avons exposé notre modélisation de la gestion et la configuration de l entrée. Nous avons aussi expliqué deux prototypes appliquant notre notion.

51 CHAPITRE 6 Mise en oeuvre et réalisation Dans ce chapitre, on présente l environnement avec lequel on a travaillé, les résultats obtenus et les difficultées rencontrés. 6.1 Environnements Logiciel Systèmes d exploitation Durant les six mois de travail, on a utilisé principalement des systèmes d exploitation Linux opensuse 11.1 et ubuntu On a travaillé sur les noyaux allant de la version à la version Et c est cette dernière qui contient les modifications effectuées pour supporter la reconnaissance et la génération des évènements multi-contacts. Ce même noyau puis celui qui suit le contiennent des pilotes pour des périphériques multi-tactiles de la Stantum, la DiamondTouch ainsi que le HP NTrig, tous développés en totalité ou en partie dans notre laboratoire Le reste de l environnement On a aussi utilisé le gestionnaire de fenêtres de KDE 4, appelé KWin ainsi que le gestionnaire Compiz pour aboutir aux vidéos de démonstrations lancées sur le site Youtube. Et pour la création des vidéos on a utilisé Kdenlive. L interface graphique a été codé en C++ et la bibliothèque Qt a été choisi pour

52 CHAPITRE 6. MISE EN OEUVRE ET RÉALISATION 39 les primitives de dessin. D autres outils graphiques ont été aussi utilisés comme l outil Inkscape et Gimp pour la génération des objets graphiques dans l interface de configuration. 6.2 Environnements Matériel Machines utilisés Les machines utilisées pour aboutir à ce travail sont : PC de Bureau C est un ordinateur sous le système ubuntu 9.04, appartenant au laboratoire d informatique interactive, il a été utilisé pour le raccodrement des nombreux périphériques d entrée testés. Il a été aussi utilisé pour le test et le codage de quelques démonstrations. Laptop LG C est un ordinateur portable avec le système opensuse 11.1 (KDE 4.2.4) surlequel la majorité du travail fût réalisée surtout pendant la dernière phase du travail. Les démonstrations qui ont résulté en des séquences vidéos ont été codé sur cet ordinateur. Mac Mini Avec le système MacOS X Tiger 10.4 installé, cet ordinateur a permis de tester quelques applications du monde Mac, conçus pour la programmation visuelle en utilisant des boites avec des entrées/sorties connectables Périphériques Nous avons utilisé beaucoup de périphériques surtout dans la phase du prototypage. Parmi ces périphériques nous citons : MERL Diamond Touch utilisé pour vérifier sa gestion minimale des multiutilisateur avec des essais de supporter la suivie des contacts multi-tactiles. Stantum la principale tablette sur laquelle les tests multi-tactiles se font. Phidgets dispositifs d entrée générique. Utilisés pour faire des tests sur leurs protocoles. Contrôlleur Korg périphérique(réf. Figure.6.1) utilisé habituellement pour les logiciels de musique. Nous l avons utilisé pour configurer et contrôler l injection de l entrée d un autre dispositif comme la souris.

53 CHAPITRE 6. MISE EN OEUVRE ET RÉALISATION Réalisation Figure 6.1 Le contrôlleur Nanokontrol Corps du configurateur Le corps du configurateur n est que l association du code des prototypes déjà créés puis traités de façon à les faire fonctionner de façon dynamique et sous forme d un serveur Linux ou daemon. Figure 6.2 Architecture du configurateur Le configurateur principale ne nécessite pas une interface graphique pour fonctionner, il utilise seulement un minimum pour rester rapide et réactif. Mais le développement d un interface a été lancé pour faciliter son utilisation depuis les utilisateurs simples Interface graphique de configuration L interface graphique de configuration est la liaison avec laquelle un utilisateur non expérimenté accède à la configuration. Dans cet interface l utilisateur manipule des objects graphiques qui sont ensuite traduits vers des commandes textuelles de configuration.

54 CHAPITRE 6. MISE EN OEUVRE ET RÉALISATION 41 Figure 6.3 Interface de génération des paramètres pour le configurateur L interface n est pas totalement complet, et exige encore plus de travail pour arriver à l état d être validé par les autres développeurs des composants Linux. 6.4 Problèmes rencontrés Comme dans tout projet, il a eu des moments difficiles durant plusieurs phases d avancement. Je tiens ici à signaler les majeurs problèmes rencontrés : Rattraper les connaissances acquises face à la vitesse avec laquelle évolue le système Linux, Le manque cruel de la documentation dans plusieurs parties du système Linux ainsi que pour beaucoup de bibliothèques utilisées, La suivie d un processus de développement non habituel et l intégration dans la communauté des développeurs existantes, Les pics dans la charge de travail à réaliser pendant une période très réduite de temps, La suivie des retours du travail après son lancement et maintenir le rythme de développement. 6.5 Chronogramme Voici le chronogramme représentatif de la totalité du travail réalisé :

55 CHAPITRE 6. MISE EN OEUVRE ET RÉALISATION Conclusion Figure 6.4 Chronogramme du projet Dans ce chapitre, nous avons montré l environnement de travail que nous avons vécu que ce soit coté matériel ou logiciels. Nous avons aussi présenté l état des travaux réalisés et les problèmes rencontrés tout au long des six mois de travail.

56 Conclusion et Perspectives AU cours de mon stage de fin d études, et en plus de la découverte d un nouveau pays et une nouvelle culture, j avais aussi la mission de comprendre le processus de recherche et une méthodologie de travail dont je n étais pas habitué. J avais beaucoup de choses à s habituer avec. Et j avais une mission à réussir pour laisser une bonne image et une bonne impression. La mission la plus difficile était de s intégrer avec les méthodologies de recherche et analyser les significations et les buts des papiers scientifiques et les points pas encore explorés ou dépassés pour les ajouter ou les améliorer. C est pour ceci qu une très grande partie de mon travail consistait à analyser les modèles et proposer un nouveau plus général et plus applicable. Le processus s est basé sur les directives de mon encadreur et sa patiente pour m enseigner les bonnes manières de se lancer dans des grands projets et d extraction des besoins. Le fait de se baser sur des scénarios réels et de les collecter depuis une gamme large de personnes de différents niveaux permet d élargir l espace des connaissances et d imagination. Les séances de Brainstorming étaient aussi un grand facteur de réussite pour la collecte des idées. Les apports du stage sont alors assez nombreux, on cite alors la proposition du modèle de gestion des périphériques et l imagination de nouveaux systèmes qui remplacent ceux qui existent déjà. Les apports personnels du stage en ce qui concerne les connaissances du système d exploitation Linux et la procédure de son développement sont aussi abondants puisque on s est impliqué dans les basses couches du système. Et en ce qui concerne les résultats de nos travaux, ils seront considérés commes des prototypes fonctionnant comme des preuves de concept de la possibilité de la réimagination des systèmes pour les améliorer et découvrir les facettes cachés que personnes autres n a essayé ou a eu le courage de les dévoiler.

57 Bibliographie [AGA06] Pau Arumí, David García, and Xavier Amatriain. A dataflow pattern catalog for sound and music computing. In PLoP 06 : Proceedings of the 2006 conference on Pattern languages of programs, pages 1 23, New York, NY, USA, ACM. [Bux] [Bux83] William Buxton. More to interaction than meets the eye : Some issues in manual input. http :// William Buxton. Lexical and pragmatic considerations of input structures. SIGGRAPH Comput. Graph., 17(1) :31 37, [Bux90] William Buxton. A three-state model of graphical input. In INTER- ACT 90 : Proceedings of the IFIP TC13 Third Interational Conference on Human-Computer Interaction, pages , Amsterdam, The Netherlands, The Netherlands, North-Holland Publishing Co. [Cha94] [CLV07] Stéphane Chatty. Extending a graphical toolkit for two-handed interaction. In UIST 94 : Proceedings of the 7th annual ACM symposium on User interface software and technology, pages , New York, NY, USA, ACM. Stéphane Chatty, Alexandre Lemort, and Stéphane Valès. Multiple input support in a model-based interaction framework. In 2nd Annual IEEE International Workshop on Horizontal Interactive Human-Computer Systems, pages , Newport, Rhode Island, USA, October TableTop 2007, IEEE Computer Society. [CMR90] Stuart K. Card, Jock D. Mackinlay, and George G. Robertson. The design space of input devices. In CHI 90 : Proceedings of the SIGCHI conference

58 BIBLIOGRAPHIE 45 on Human factors in computing systems, pages , New York, NY, USA, ACM. [CMR91] Stuart K. Card, Jock D. Mackinlay, and George G. Robertson. A morphological analysis of the design space of input devices. Trans. Inf. Syst., 9(2) :99 122, April [DF04] [Dra04] [FSB05] Pierre Dragicevic and Jean-Daniel Fekete. Support for input adaptability in the icon toolkit. In ICMI 04 : Proceedings of the 6th international conference on Multimodal interfaces, pages , New York, NY, USA, ACM. Pierre Dragicevic. Un modèle d interaction en entrée pour des systèmes interactifs multi-dispositifs hautement configurables. PhD thesis, École Nationale Supérieure des Techniques Industrielles et des Mines de Nantes, March Clifton Forlines, Chia Shen, and Bill Buxton. Glimpse : a novel input model for multi-level devices. In CHI 05 : CHI 05 extended abstracts on Human factors in computing systems, pages , New York, NY, USA, ACM Press. [Hin06] Ken Hinckley. Input technologies and techniques. In Andrew Sears and Julie A. Jacko, editors, Handbook of Human-Computer Interaction. Lawrence Erlbaum & Associates, [JSMJ94] Robert J. K. Jacob, Linda E. Sibert, Daniel C. Mcfarlane, and Jr. Integrality and separability of input devices. ACM Trans. Comput.-Hum. Interact., 1(1) :3 26, [Shn97] [SVC04] [USB01] Ben Shneiderman. Direct manipulation for comprehensible, predictable and controllable user interfaces. In IUI 97 : Proceedings of the 2nd international conference on Intelligent user interfaces, pages 33 39, New York, NY, USA, ACM. Céline Schlienger, Stéphane Valès, and Stéphane Chatty. Une expérience de conception et de prototypage d interfaces évoluées en milieu industriel. In IHM 2004 : Proceedings of the 16th conference on Association Francophone d Interaction Homme-Machine, pages , New York, NY, USA, ACM. USB Implementers Forum. Device Class Definition for Human Interface Device 1.11, June 2001.

59 BIBLIOGRAPHIE i [USB04] USB Implementers Forum. HID Usage Tables, October [WM03] Jingtao Wang and Jennifer Mankoff. Theoretical and architectural support for input device adaptation. In CUU 03 : Proceedings of the 2003 conference on Universal usability, pages 85 92, New York, NY, USA, ACM Press.

60 Acronymes et définitions Accéléromètre capteur d accélération Contrôlleur midi Périphérique contenant une multitude de régulateurs pour la gestion de la musique DAEMON Disk And Execution MONitor, processus serveur dans Linux s exécutant en arrière-plan DBus Data Bus Gyroscope capteur d angle d inclinaison HID Humain Interface Device IHM Interaction Humain-Machine RFID Radio-Frequency identifier, périphérique permettant d identifier les objets à distance TouchPad surface pour émuler une souris dans les PC portables Trackpad point pour émuler une souris dans les PC portables USB Universal Serial Bus Wii Console de jeu possédant des manettes riches en capteurs WIMP Windows, Icons, Menus, Pointer Xorg Le serveur d affichage des UNIX

61 ANNEXE A Diffusion des résultats des travaux Puisque notre projet se repose sur des technologies libres, et s intègre au système Linux, nous avons eu un parcours un peu spécifique lors de nos travaux. Nous avons contacté beaucoup de gens chacun travaillant sur une partie du système totale. Et à la fin nous avons été cité dans plusieurs sites d actualités. A.1 Travail avec la communauté de Linux Pour pouvoir proposer des modifications dans le noyau Linux, la procédure consiste à bien étudier le système puis d envoyer les changements sous forme d un patch. Un patch est tout simplement la différence entre le système initiale et le système après les modifications développées. La liste de diffusion principale de Linux est très active(ref. Figure.A.1), de l ordre de 500 mails par jour. Et c est pour ceci que d autres listes existent, chacune d elles se spécifie à une partie du système Figure A.1 La liste de diffusion de Linux

62 ANNEXE A. DIFFUSION DES RÉSULTATS DES TRAVAUX iv A.2 Génération des vidéos de démonstration Pour garantir une bonne information de nos travaux. Nous avons fait des vidéos de démonstration des possibilités du nouveau support de la gestion multi-tactile du noyau. Nous avons créé un compte dans le site Youtube.com et nous avons diffusé exclusivement vidéos montrant pour la première fois la possibilité de commander un bureau ordinaire avec des commandes multi-tactiles. La vidéo dont vous voyez les captures(ref. Figure.A.2) est l une entre plusieurs diffusées, mais elle est celle qui a pris le plus de succès. Figure A.2 Capture de la vidéo diffusée A.3 Les retours reçus La vidéo a eu du succès et elle était vue par plus de personnes jusqu à maintenant(ref. Figure.A.3). Mais nous avons eu aussi des retours depuis des personnes voulant tester ces nouvelles possibilités sur leurs systèmes. Les retours les plus importants proviennent de quelques sociétés qui fabriquent des écrans multi-tactiles et qui voulaient coopérer et garantir le support de leurs plateformes sous Linux. Figure A.3 Le nombre élevé de visualisations

63 ANNEXE A. DIFFUSION DES RÉSULTATS DES TRAVAUX v A.4 Design du site du laboratoire Avant d avoir diffusé les résultats des travaux, il faut d abord préparer les cibles des visiteurs éventuels qui vont se diriger vers la page originelle qui parle du travail. Le site du laboratoire contenait, avant sa mise à jour, des simples pages textuelles sans aucun style défini. Donc nous avons édité les pages et fait les mises à jour pour arriver à un résultat acceptable et qui attire le visiteur et le motive à revenir encore une fois. Figure A.4 Le nouveau site du laboratoire

64 ANNEXE B Système DBus B.1 Présentation de D-Bus D-Bus est un système de communication interprocessus (IPC). Architecturalement, il dispose de plusieurs niveaux : Une bibliothèque, libdbus, qui permet à deux applications de se connecter les uns aux autres et échanger des messages. Un daemon bus de messages exécutable, construit sur libdbus, vers lequel plusieurs applications peuvent se connecter. Le démon peut router les messages d une application à une ou plusieurs autres applications. Des bibliothèques de liaison qui s appuyent sur des frameworks applicatives particulières. Par exemple, libdbus-glib et libdbus-qt. Il existe également des liaisons à des langages tels que Python. Ces bibliothèques de liaison sont les API que les personnes devraient utiliser car ils simplifient les détails de la programmation D-Bus. La libdbus est destiné à être une bibliothèque bas niveau pour les liaisons de niveau supérieur. Une grande partie de l API libdbus n est utile que pour cette liaison. libdbus ne supporte que des connections un-à-un, tout comme une prise réseau brute. Toutefois, plutôt que d envoyer les flux d octets sur la connexion, vous envoyez des messages. Les messages ont un en-tête indiquant le type de message, et un corps contenant une charge utile de données. Le démon bus de messages est le noyau d une roue. Chaque rayon de la roue est une connexion un-à-un à une application utilisant libdbus. Une application envoie un message au démon de bus sur sa parole, et le démon de bus transfère le message vers d autres applications liées au besoin. Pensez à le démon comme un routeur.

65 ANNEXE B. SYSTÈME DBUS vii Le démon du bus a plusieurs instances sur un ordinateur ordinaire. Une instance a des restrictions de sécurité lourde sur les messages qu elle accepte, et est utilisé pour la communication l ensemble du système. Les autres instances sont créées par session utilisateur une connexion. Ces exemples permettent aux applications en session de l utilisateur de communiquer avec l un l autre. Les démons utilisateur et systèmes sont séparées. Les messages émis seulement dans l instance session ou système n impliquent pas l autre instance. B.2 Applications D-Bus Il y a beaucoup de technologies dans le monde pour gérer la communication inter-processus ou en réseau comme : CORBA, DCE, DCOM, DCOP, XML-RPC, SOAP, MBUS, Internet Communications Engine (ICE), et probablement des centaines d autres. Chacune d elles est adaptée à des types particuliers d application. D-Bus est conçu pour deux cas particuliers : 1. Communication entre les applications de bureau dans la même session bureau, pour permettre l intégration de la session du bureau dans son ensemble, et adresse les problèmes du cycle de vie des processus (quand démarrer et d arrêter les composants de bureau). 2. La communication entre la session du bureau et le système d exploitation, où le système d exploitation inclue en général les démons du noyau et tout système ou processus. Pour l utilisation dans le bureau, GNOME et KDE ont l expérience antérieure significative avec des solutions différentes IPC tels que CORBA et DCOP. D-Bus est construit sur cette expérience et soigneusement conçue pour répondre aux besoins de ces projets de bureau en particulier. D-Bus peut être utiles à d autres fins que celle qu elle a été conçue. Ses propriétés générales qui le distinguent des autres formes de IPC sont les suivantes : Protocole binaire conçu pour être utilisé de façon asynchrone (même esprit que le protocole X Window System). Les connexions sont fiables et maintenues ouvertes au cours du temps. Le bus de messages est un démon, et non pas une architecture distribuée.

66 ANNEXE B. SYSTÈME DBUS viii Beaucoup de mise en oeuvre et de déploiement sont précisées plutôt que laissé ambigu / configurable. Sémantique est similaire au système existant DCOP, permettant à KDE de l adopter plus facilement. B.3 Concepts Quelques concepts de base s appliquent peu importe dans quel cadre d application que vous utilisez pour écrire une application D-Bus. Le code exact que vous écrivez sera différent pour les applications Qt, Glib ou Python. Figure B.1 Schéma présentant les Concepts de DBus Les Objets et les chemins Le protocole bas-niveau de DBus ne permet pas de créer des objets mais il présente la notion du chemin d objet. Le chemin d objet ressemble à un chemin sur le système,