rapport - pfe.boulabiar.netpfe.boulabiar.net/rapport.pdf · réf : 2009/ii/ soutenu à la session...

Réf : 2009/II/ Soutenu à la session de Septembre 2009

Université de la Manouba

Ecole Nationale des Sciences de L’Informatique

RAPPORTDE 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

Résumé

JUSQU ’à nos jours, les applications demeurent câblés pour un unique paradigmed’interaction limité aux évènements produits par seulement le clavier et la sou-

ris. Les études concernant l’adaptabilité et la configuration de l’entrée restent encoretrès peu nombreuses et non directement implémentables dans les systèmes d’exploita-tion surtout pour Linux. Dans ce travail, nous proposons un nouveau modèle d’entréefaisant intervenir le paradigme de configuration à travers des adaptateurs entre les dis-positifs matériels et les applications. Ce modèle qui s’intègre entre le noyau Linux etles applications permet un large contrôle en injectant des évènements d’entrée virtuelset adaptables ou en invoquant les méthodes internes des applications existantes sansnécessiter aucune modification ou réécriture.

Mots clés : Interaction Homme-Machine, Multi-tactile, Périphériques d’entrée, Tech-niques d’interaction, Adaptabilité, Accessibilité, Interfaces Post-WIMP.

Abstract

JUST to our days, applications are still wired to a single interaction paradigm res-tricted to events produced by keyboard and mouse. Studies concerning the adap-

tability and configuration of the input still very few and not directly applyable andimplementable in OS especially for Linux. In this work, we propose a new model ofinput involving the paradigm of configuring it via adapters between hardware devicesand applications. The model that fits between the Linux kernel and applications al-lows extensive control by injecting adaptable virtual events input after treatment orby invoking internal methods of applications which doesn’t require rewriting .

Key words : Human-Computer Interaction, Multitouch, Input Device, InteractionTechniques, Adaptability, Accessibility, Post-WIMP.

Signatures des encadrants

Prof. Nejib BEN HADJ ALOUANE

(ENSI)

Prof. Stéphane CHATTY

(LII-ENAC)

Remerciements

C’EST parce que j’ai beaucoup estimé tous ceux qui m’ont écouté, conseillé, cri-tiqué 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 à bience travail, pour son aide, son temps passé pour me guider, ses efforts pour m’intégrerdans l’environnement, son dévouement et ses précieux conseils.

Mon superviseur le Professeur Nejib Ben-Hadj-Alouane, parce qu’il a accepté de mesuperviser et suivre les détails de l’avancement de mon travail, ainsi que son aide et sesconseils 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 espritouvert 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 momentsdifficiles.

Je tiens aussi à remercier ceux qui ont partagé le même espace de travail dans lebureau C106 dont les matheux Keumjin Lee et Nour Dougui, les doctorants Benja-min Tissoire, Christophe Hurter et Gilles Tabart ainsi que les autres stagiaires PierreBucher, Fabien André et Sébastien Hamdani

Et je tiens aussi à remercier toute autre personne ayant contribué d’une façon oud’une autre, au bon déroulement de mon projet de stage et je cite :

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 lessalons de discussions IRC.

Table des matières

Remerciements v

Introduction générale 1

1 Contexte du projet 3

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . 3

1.1.1 L’École Nationale de l’Aviation Civile . . . . . . . . . . . . . . . 3

1.1.2 Le Laboratoire d’Informatique Interactive . . . . . . . . . . . . 4

1.1.3 IntuiLab et son secteur d’activité . . . . . . . . . . . . . . . . . 5

1.1.4 Cadre du travail : Projet ShareIT . . . . . . . . . . . . . . . . . 5

1.2 Présentation du travail demandé . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Processus de développement adopté . . . . . . . . . . . . . . . . . . . . 6

1.3.1 La Datalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.2 Le Maquettage . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.3 Réalisation et prototypage . . . . . . . . . . . . . . . . . . . . . 7

2 Étude préalable et état de l’art 8

2.1 Gestion de l’entrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Signification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 Diversités des dispositifs et des paradigmes d’interaction . . . . 8

2.1.3 Nécessité d’un modèle . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Modèles et études Scientifiques . . . . . . . . . . . . . . . . . . . . . . 10

TABLE DES MATIÈRES viii

2.2.1 Modèles de transition . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.2 Étude des performances et expérimentation . . . . . . . . . . . 11

2.2.3 Taxinomie des dispositifs . . . . . . . . . . . . . . . . . . . . . . 11

2.2.4 L’utilisation de plusieurs dispositifs . . . . . . . . . . . . . . . . 13

2.2.5 Les systèmes multi-tactiles . . . . . . . . . . . . . . . . . . . . . 14

2.2.6 Émergence de la configurabilité . . . . . . . . . . . . . . . . . . 15

2.3 Modèle HID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2 Principe du modèle . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.3 Limites du modèle . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Spécification 18

3.1 Méthodologie participative . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Scénarios d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1 Scénario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.2 Scénario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.3 Scénario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.2 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.3 Méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Extraction des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.1 Émergence d’un modèle . . . . . . . . . . . . . . . . . . . . . . 23

3.4.2 Intégration au système Linux . . . . . . . . . . . . . . . . . . . 23

3.4.3 Interface de configuration . . . . . . . . . . . . . . . . . . . . . 23

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Analyse et conception élémentaire 25

TABLE DES MATIÈRES ix

4.1 Analyse des systèmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1 Système de gestion d’entrée de Linux . . . . . . . . . . . . . . . 25

4.1.2 Système HID du noyau Linux . . . . . . . . . . . . . . . . . . . 26

4.1.3 Communication DBus . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.3.1 Utilité . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.3.2 Historique, Dcop, Bonobo, Corba . . . . . . . . . . . . 27

4.1.3.3 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Étude des périphériques . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.1 Les Phidgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.2 Les Surface-Computers . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.3 Tablette Wacom . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2.4 Table DiamondTouch . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.5 Tablette Stantum . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 Conception élémentaire et Solutions . . . . . . . . . . . . . . . . . . . . 30

4.3.1 Intégration du configurateur au noyau Linux . . . . . . . . . . . 30

4.3.2 Création d’un daemon séparé . . . . . . . . . . . . . . . . . . . 31

4.3.3 Intégration à la chaine traditionnelle d’entrée . . . . . . . . . . 31

4.3.4 Accès DBus aux applications . . . . . . . . . . . . . . . . . . . . 31

4.3.5 Principe d’injection des évènements . . . . . . . . . . . . . . . . 32

4.3.6 Validation des choix . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Modélisation et Prototypage 33

5.1 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.1 Unités minimales d’entrée . . . . . . . . . . . . . . . . . . . . . 33

5.1.2 Représentation d’un périphérique . . . . . . . . . . . . . . . . . 34

5.1.3 Projection de la configuration . . . . . . . . . . . . . . . . . . . 34

5.2 Prototypage des modèles . . . . . . . . . . . . . . . . . . . . . . . . . . 35

TABLE DES MATIÈRES x

5.2.1 Communications DBus . . . . . . . . . . . . . . . . . . . . . . . 35

5.2.2 Injection de l’entrée . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6 Mise en oeuvre et réalisation 38

6.1 Environnements Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.1.1 Systèmes d’exploitation . . . . . . . . . . . . . . . . . . . . . . . 38

6.1.2 Le reste de l’environnement . . . . . . . . . . . . . . . . . . . . 38

6.2 Environnements Matériel . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2.1 Machines utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2.2 Périphériques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.3.1 Corps du configurateur . . . . . . . . . . . . . . . . . . . . . . . 40

6.3.2 Interface graphique de configuration . . . . . . . . . . . . . . . . 40

6.4 Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.5 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

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

TABLE DES MATIÈRES xi

B.1 Présentation de D-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

B.2 Applications D-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

B.3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Liste des figures

1.1 Méthodologie de travail IntuiSignTM . . . . . . . . . . . . . . . . . . . . 7

2.1 Exemple de périphériques, tablette et TrackPen, manette Wiimote etune spaceball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Modèle de transition à 3 états de Buxton . . . . . . . . . . . . . . . . . 10

2.3 Application du modèle sur la souris . . . . . . . . . . . . . . . . . . . . 11

2.4 Taxinomie de Buxton . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 L’espace de conception de Card [CMR90] . . . . . . . . . . . . . . . . . 13

2.6 L’utilisation de deux souris avec deux mains dans la plateforme Whizz 14

2.7 Les surfaces computer : Microsoft Surface et IntuiFace d’IntuiLab . . . 14

2.8 Exemple de configuration de l’entrée avec ICon . . . . . . . . . . . . . 15

2.9 Principe du transfert HID . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Conception itérative et participative . . . . . . . . . . . . . . . . . . . . 18

3.2 Le résultat d’un Brainstorming . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Abstraction de la constitution du système Linux . . . . . . . . . . . . . 26

4.2 Quelques phidgets : des boutons, des sliders et des capteurs divers . . . 28

4.3 Tablette Wacom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Unités d’entrée minimales . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2 Représentation d’un périphérique . . . . . . . . . . . . . . . . . . . . . 34

LISTE DES FIGURES xiii

5.3 Principe d’inclusion de la configuration dans le modèle . . . . . . . . . 35

5.4 Architecture de la communication DBus utilisée . . . . . . . . . . . . . 36

5.5 Architecture de l’injection de l’entrée . . . . . . . . . . . . . . . . . . . 37

6.1 Le contrôlleur Nanokontrol . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2 Architecture du configurateur . . . . . . . . . . . . . . . . . . . . . . . 40

6.3 Interface de génération des paramètres pour le configurateur . . . . . . 41

6.4 Chronogramme du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 42

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

Introduction générale

LA majorité des utilisateurs des ordinateurs savent obligatoirement comment tapersur 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 poursupporter ces deux périphériques et ils sont préparés pour que l’interaction se feratoujours de la même façon. Notre façon de contrôler les ordinateurs est devenue alorsun standard que les fabricants du matériel et les éditeurs des logiciels y compris-lessystèmes se sont mis d’accord de la garder.

Il existe néanmoins bien d’autres manières de contrôler les applications, les manettesde jeu sont utilisées, les contrôlleurs midi pour les applications musicales ainsi que lesoutils et les surfaces tactiles. Il existe même des périphériques très spécialisés utilisésdans les applications de dessin 3D.

Chaque jour de nouveaux dispositifs apparaissent mais la chose commune entretous ces dispositifs est qu’ils sont tous adaptés à un contexte d’utilisation donné etfigé. On peut pas malheureusement utiliser la manette pour remplacer la souris ni lecontrôlleur midi pour remplacer un clavier. On ne peut pas même les utiliser hors deleurs contextes très restreint.

Par contre, beaucoup de travaux de recherche montrent des analyses sur la possibi-lité qu’un dispositif remplace un autre. Et rien encore ne peut nier qu’on peut trouverparfois des contextes d’utilisation beaucoup plus naturels et adaptés que ceux figés parle constructeur ou par le système d’exploitation.

C’est dans ce cadre que notre projet se situe. Nous étudions les techniques d’adapta-tion du contexte de l’utilisation des dispositifs d’entrée. Nous cherchons à rendre cetteutilisation configurable et dans la portée de l’utilisateur final. Nous cherchons à enleverles limitations des systèmes et même des fabricants pour l’utilisation quotidienne en seréférant à des modèles scientifiques et études de scénarios réels des utilisateurs.

INTRODUCTION GÉNÉRALE 2

Notre tâche commence par l’élaboration d’un modèle générale et simple capable desupporter l’intégration de la configuration. Les travaux seront applicables sur le systèmed’exploitation Linux et cherchent à améliorer la façon d’interagir avec l’ordinateur et defaciliter la recherche d’autres paradigmes d’interaction. Nous avons aussi concentré unegrande partie de notre travail sur les nouvelles techniques d’interaction multi-tactilesou “multitouch”.

L’organisation du rapport sera comme suit :

– Le premier chapitre est un chapitre introductif présentant le contexte dans lequela é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 destravaux 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 à laconception élémentaire des solutions,

– Dans le cinquième chapitre, nous exposons notre modélisation des périphériqueset les travaux de prototypage réalisés,

– Le dernier chapitre présentera le travail réalisé, l’environnement et les difficultésrencontrés.

CHAPITRE1 Contexte du projet

Dans ce chapitre, Nous exposons le contexte général du projet. On présente enpremier lieu l’organisme d’accueil, le travail demandé et on termine par l’explicationde la méthodologie de travail qu’on a suivi.

1.1 Présentation de l’organisme d’accueil

1.1.1 L’École Nationale de l’Aviation Civile

L’école nationale de l’aviation civile (ENAC) est une grande école aéronautiquesituée à Toulouse (Haute-Garonne). C’est un établissement public à caractère adminis-tratif placé sous la tutelle du Ministère de l’Écologie, de l’Énergie, du Développementdurable et de la Mer. Cette tutelle est exercée en pratique par la Direction Généralede l’Aviation Civile (DGAC). L’ENAC est membre associé de l’Université de Toulouseet membre du pôle de compétitivité Aerospace Valley.

A l’exception du domaine de la construction aéronautique, l’École assure des for-mations 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 écoled’ingénieurs et un centre national de formation de la DGAC et au profit d’autres ins-titutions 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 1968. Elle est au-jourd’hui implantée sur le complexe scientifique de Rangueil, à proximité du futurAerospace Campus.

CHAPITRE 1. CONTEXTE DU PROJET 4

1.1.2 Le Laboratoire d’Informatique Interactive

Le département “mathématiques et informatique” consacre une importante partiede 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 prod’ingénierie des systèmes interactifs (avec les universités Toulouse 1 et Toulouse 3) etun mastère d’ingénierie système (avec l’Ecole Nationale Supérieure de l’Aéronautiqueet de l’Espace).

Le laboratoire d’“Informatique Interactive” a été créé en 2006. Il est issu de collabo-rations 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 surl’ingénierie des systèmes interactifs, et les théories, modèles et outils informatiquesassociés. Le laboratoire bénéficie pour cela des expériences concrètes de développementde systèmes de ses partenaires.

Il contribue au développement d’outils géré par ces derniers. Sa première missionconsiste à reprendre à sa charge les travaux de recherche fondamentale sur les problèmesrencontré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éphaneConversy, Yannick Jestin, Thierry Garcia, Hélène Gaspard-Boulin et de trois docto-rants. Il est impliqué dans des projets sur les thèmes suivants :

– un thème “Visualisation d’information”, perception, codage d’information. ProjetsKabuki, 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, langageProjets IntuiKit, Sauvage, Anims, Mammi, I* et Share-IT

– un thème “Ingénierie des logiciels interactifs” : méthodes de conception, génielogiciel multidisciplinaire Projets Erasmus, Callisco


1.1.3 IntuiLab et son secteur d’activité

La société Intuilab, partenaire de l’ENAC dans plusieurs projets de recherche, prenden charge la gestion administrative et financière de ce stage. Intuilab est une PME inno-vante créé en 2002 par trois chercheurs en IHM dont Stéphane Chatty. Elle s’est depuisdéveloppée grâce à son expertise sur le domaine de l’interaction Humain-Machine ets’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,8millions d’euros en 2008. Son offre se découpe en une branche matérielle, avec l’IntuifaceSurface Computer (anciennement Intuiface) et une branche service. Cette branche ser-vice se distingue par l’emploi de méthodes de conceptions centrées utilisateurs et parune équipe pluridisciplinaire (ergonomes, graphistes, architectes, concepteurs), ainsique 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’ap-plications interactives innovantes. IntuiLab couvre quatre domaines d’expertise : larénovation des interfaces de leurs clients, la numérisation des processus métiers, latransformation d’idées en produits ou services intuitifs, l’anticipation des modes d’in-teractions innovants.

1.1.4 Cadre du travail : Projet ShareIT

ShareIT est projet de recherche qui est commencé au début de 2008 pour trois anset sponsorisé par Aerospace Valley. L’objectif du projet est de concevoir et de testerles interfaces tactile qui seront partagé par le pilote et le copilote dans le cockpit d’unavion. 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.


1.2 Présentation du travail demandé

Le projet se situe dans le cadre des études de la gestion des dispositifs d’entréequi sont menées depuis longtemps et qui n’incluent pas seulement les périphériquesstandards comme le clavier et la souris. Dans ce cadre, une étude doit être réaliséesur les différents dispositifs d’entrée existants ainsi que leurs représentations dans lessystèmes d’exploitations et dans les publications scientifiques.

Les modélisations existantes sont dans la plupart des cas dépassés par rapportaux nouveaux périphériques qui sont entrain d’apparaître actuellement, que ce soitdans les publications scientifiques ou dans les modèles implémentés dans les systèmesd’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 domainede l’informatique ne font qu’émerger de nouvelles modalités et techniques d’interac-tion non habituelles et qui ont commencé à gagner le terrain, ainsi qu’une utilisationcourante 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 nou-velles contraintes en fournissant des solutions pour les problèmes existants. Le but estaussi 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 etdes 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 pascelui traditionnel et s’attache en grande partie au processus IntuiSign développé par lasociété InuiLab [SVC04]. Ce processus suit 3 phases principales :

1.3.1 La Datalyse

Cette opération se résume à la collecte d’informations et leur analyse (tâches de l’uti-lisateur, systèmes existants, technologies disponibles, etc.) pour fournir le bon matérielpour la conception (cahier des charges, points clef de conception, tendances graphiques,


profiles utilisateurs, scénarios d’usage, etc.). La procédure de la collecte d’informationcontient aussi en grande partie l’étude des publications scientifiques existantes commesource d’information et d’analyses anciennement effectués ainsi que l’étude des scéna-rios réels d’utilisation à partir de chaque profil éventuel d’utilisateur.

1.3.2 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 projetsde pure IHM à utiliser des modèles papier.

La programmation exploratoire, les illustrations et les évaluations élémentaires per-mettent 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 untemps qui sera consommé suite à l’implication dans des mauvais choix à une étapeassez avancée.

1.3.3 Réalisation et prototypage

Cette étape consiste à la création de prototypes avancés pouvant être transformésen 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 deprototypes aide à raffiner et illustrer les solutions et permettent une transition graduellevers l’implémentation finale.

Figure 1.1 — Méthodologie de travail IntuiSignTM

CHAPITRE2 É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 lagestion de l’entrée. On les classe par sujet et domaine de recherche. On cite aussi lestravaux sur l’interfaçage multi-tactile. Et on termine par la présentation du protocoleHID et ses sources scientifiques.

2.1 Gestion de l’entrée

2.1.1 Signification

La méthode la plus commune pour transférer les ordres vers l’ordinateur est de lespasser à travers des périphériques spécifiques qui sont les périphériques d’entrée. Toutepersonne qui utilise un micro-ordinateur est habituée à taper sur un clavier, cliquer surdes boutons, ouvrir des menus et déplacer un pointeur sur l’écran. Les deux moyensphysiques les plus utilisés sont alors sûrement le clavier suivi par la souris. C’est unefaçon de contrôler une machine et elle présente en partie, un paradigme d’interactionlargement utilisé appelé WIMP.

2.1.2 Diversités des dispositifs et des paradigmes d’interaction

Depuis longtemps, les industriels ainsi que les chercheurs n’ont pas cessé de pro-poser plusieurs dispositifs permettant de faire une tâche particulière d’une façon plusrapide ou plus parfaite. Plusieurs nouveaux périphériques physiques sont apparus, desmanettes de jeu, des contrôleurs midi, sans oublier les TrackPad ou les TrackPoint.

CHAPITRE 2. ÉTUDE PRÉALABLE ET ÉTAT DE L’ART 9

Figure 2.1 — Exemple de périphériques, tablette et TrackPen, manette Wiimote etune spaceball

Vu le nombre très grand de ces dispositifs, certains constructeurs ont par exemplecréé des objets qui substituent une souris en point de vue système mais qui ont desstructures et des critères complètement différents. La substitution d’une souris par unTouchPad ou un TrackPad est faite mais dans la majorité des cas on ne tient pascompte 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 à cettediversité et pour extraire les spécificités éventuelles d’un dispositif par rapport à unautre[Bux83]. Mais à chaque fois, l’utilisation d’un périphérique ne tient pas toujourscompte des résultats prouvés ou des taxinomies et elle est directement liée à celle quele 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 lagestion de périphériques malgré la diversité et réduit les problèmes.

2.1.3 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 demeurenécessaire pour proposer une méthode commune pour simplifier la reconnaissance dudispositif en premier lieu puis la configuration et l’adaptation en se basant sur lescomposites de ce modèle là.

Un modèle unique ou au moins groupant la majorité des cas possibles doit éliminerune complexité de gestion hasardeuse dans les systèmes, faciliter la création des couches


implémentant une nouvelle utilisation des périphériques mais il doit être aussi “sim-ple” mais pas “plus simple” dans le sens où il ne faut pas réduire des caractéristiquesprimordiales.

2.2 Modèles et études Scientifiques

L’émergence des dispositifs physiques était le résultat de la coopération entre lesscientifiques et les sociétés impliqués. Les études scientifiques ont permis d’extraireles résultats des expériences et de les interpréter pour dégager les points forts d’undispositif et la meilleure application pour être utilisé avec.

2.2.1 Modèles de transition

Des modèles de gestion des messages émis à l’entrée sont aussi apparus afin desimplifier l’interprétation des actions à exécuter pour le contrôle du système. L’un desces modèles est celui de la machine à trois états de William Buxton[Bux90]. Buxtona proposé une façon pour gérer les dispositifs de pointage qui consiste à faire uneabstraction 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. Etla gestion sera géré de façon déterministe.


Figure 2.3 — Application du modèle sur la souris

2.2.2 Étude des performances et expérimentation

Plusieurs études de performances ont été effectuées sur des tranches de per-sonnes afin d’analyser les caractéristiques des dispositifs et de les classer en termed’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 aussiprécisé qu’en terme de contrôlabilité, on peut subdiviser les périphériques en sous com-posants décrits par la notion de la “séparabilité” et qu’il n’est pas possible pour d’autresdécrite par la notion de l’“intégralité”.

Des dimensions séparables selon Jacob peuvent être contrôlés séparément sans nuireni aux performances finales ni à la précision comme le contrôle des couleurs d’un objet etses dimensions. Alors que les critères intégraux ne peuvent pas être séparés en contrôleet préserver les performance. Et on prend comme exemple le contrôle des dimensionsselon les axes x et y dans une souris.

Cette étude est très importante car elle explique pourquoi la substitution d’unesouris, où le contrôle des axes se fait simultanément, ne peut pas être remplacée parune manette contenant des boutons ou des flèches séparés pour ce même contrôle. Ona donc une étude qui nous guide sur les limites de la configuration et le morphismeentre dispositifs.

2.2.3 Taxinomie des dispositifs

Vu que l’espace des périphériques ainsi que les caractéristiques de chacun est entrainde s’exploser, les chercheurs ont établi plusieurs taxinomies pour classifier les dispositifs.


Après avoir fait cette répartition et indexation la gestion sera faite selon les critèresdécrites.

Buxton a classé les périphériques dans son papier[Bux83] sur un tableau selon lesdeux critères des propriétés physiques sentis et le nombre de dimensions reportées. Ceclassement donne une première idée sur l’impossibilité d’un dispositif à être utilisé dansun 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 pa-piers 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, dela 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 rapporterl’évènement.

Cette étude de Card semble la plus complète puisqu’elle fait intervenir un grandnombre de critères pour le classement et en ajoutant une étude d’hiérarchie entre lespetits composants dans un seul dispositif.

Dans la figure précédente (réf. Figure.2.5) on remarque un classement des anciensdispositifs, mais aussi une démontration des zones vides qui peuvent influencer laconstruction de nouveaux périphériques supportant ces dimensions non encore exploi-tées.


Figure 2.5 — L’espace de conception de Card [CMR90]

2.2.4 L’utilisation de plusieurs dispositifs

Des anciens études ont imaginés des interactions avec plusieurs dispositifs en mêmetemps et avec les deux mains. L’une de ces publications[Cha94] a montré l’importancede la configuration sur un processus similaire pour spécifier les objectifs de chacun desmatériels utilisés.

Dans la figure précédente qui représente un ancien système de configuration del’entrée appelé Whizz(réf. Figure.2.6), l’utilisateur contrôle un trait à l’aide de deuxpointeurs de deux souris.

D’autres études plus récentes ont repris ce même point en présentant un modèle deconfiguration qui commence par le filtrage des sources de l’entrée jusqu’à l’encapsula-tion de ces sources et l’ajout d’adaptateurs[CLV07]. L’hiérarchie a été aussi étudié etun dispositif est représenté en tant qu’un arbre de plusieurs sous composants.


Figure 2.6 — L’utilisation de deux souris avec deux mains dans la plateforme Whizz

2.2.5 Les systèmes multi-tactiles

Les systèmes multi-tactiles sont les systèmes qui ont le plus de succès ces dernièresannées, vu que des grandes sociétés investissent dans l’amélioration de ce genre depé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 lamanipulation directe inventé par Shneiderman[Shn97]. La manipulation directe décritles systèmes où ont a une visibilité des objets d’intérêt et des actions possibles, cesactions sont rapides, réversibles et incrémentales. Dans ce genre de manipulation ona un remplacement d’une syntaxe complexe par des actions simples semblables auxmanipulations dans la vie réelle.


2.2.6 Émergence de la configurabilité

Après l’émergence des dispositifs en nombre et en fonctionnalités, des études sontapparus 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 phy-siques et de les lier de façon graphique à des adaptateurs pour modifier dynamiquementleur fonctionnement sur une application de dessin. L’utilisateur place les blocs désignantles entrées de manière à avoir une sortie pour chaque variable, puis les lient à des adap-tateurs 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 lespé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 tabletteWacom sont connectées aux options de l’application. L’unité d’entrée indiquant lapression est utilisée pour modifier la grandeur du trait pendant le dessin. Les autresentré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ésen-tation des unités d’entrées dans un seul dispositif de façon dynamique. On doit créerles modèles des dispositifs en avance et ceux virtuelles provenant d’une combinaisonentre plusieurs dispositifs ne sont pas applicables. Il n’y a pas aussi une liaison directeentre le configurateur et les applications du bureau, et il faudra passer par des lienspour exporter cette configuration.

L’autre étude de configuration[WM03] ne traite que deux périphériques qui sont leclavier et la souris malgré que le papier présente un traitement des unités d’entrée avecdes petites opérations algébriques.


2.3 Modèle HID

2.3.1 Présentation

Le modèle HID, ou “Human Interface Device” est un standard faisant partie duprotocole 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. Ceconsortium d’entreprises s’est groupé pour trouver une solution permettant de faciliterla gestion des nouveaux périphériques. Une gestion de façon à simplifier la création depilotes pour les systèmes d’exploitation.

Avant ce modèle là, les constructeurs doivent choisir entre deux solutions : Soit secontenter aux standards existants qui sont très limités mais ayant un support danstous les systèmes. Soit utiliser un autre standard mais fournir les pilotes sur tout lesconfigurations pour être fonctionnel.

Les industriels choisissaient la première solution, mais suite à l’évolution qui est ap-parue et de l’émergence des technologies, ils ont vu la nécessité d’un modèle dynamiquepour la découverte des composants d’un dispositif quelconque.

2.3.2 Principe du modèle

Le modèle consiste à créer un pilote HID unique dans les systèmes d’exploitationet une partie présentatrice embarquée dans les périphériques. Le dispositif, une foisbranché à l’ordinateur, entre dans une procédure d’identification en envoyant un rap-port(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-


tionner le périphérique. Le consortium des “USB Implementors” a aussi publié des tablesd’usages fournissant les différents possibilités qu’un report descriptor peut fournir pourchaque gamme de périphériques.

Le modèle HID est aussi développé d’une façon à fournir même un descripteurphysique pour spécifier pour chaque “item” quel est le meilleur membre du corps humainà utiliser.

2.3.3 Limites du modèle

Le modèle HID constitue un grand saut permettant de faciliter aux constructeurs depériphériques ainsi qu’aux producteurs des systèmes d’exploitation la reconnaissancedes nouveaux matériels. Mais malgré ça, il ne permet pas de modifier et dynamiser uneconfiguration 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 HIDen tant que modèle très utilisé et qui a été inventé pour faciliter cette gestion dansles systèmes d’exploitation. Il nous faut maintenant spécifier les scénarios possiblesd’utilisation depuis lesquelles on extrait les besoins.

CHAPITRE3 Spécification

3.1 Méthodologie participative

Comme décrit dans le papier [SVC04], la méthodologie utilisée fût celle itérativeet participative. Cette manière de résoudre et gérer les projets permet d’impliquer ungroupe de personnes de façon opposé à l’ancienne méthodologie, où seulement chacundoit présenter un résultat à la fin sans parfois que les autres membres et chercheurssoient conscients de chaque étape qu’il a atteint, et s’il a participé ou non aux choix etla modification des solutions.

Cette méthode(réf. Figure.3.1) permet d’incorporer les idées des personnes dugroupe et de répartir la responsabilité sur tout les membres mais aussi de partagerla réussite. L’extraction des besoins ont comme source les scénarios d’utilisation réellesuite à des questionnaires posés sur des personnes et interprétés ensuite selon les détailsde chaque personne.

Figure 3.1 — Conception itérative et participative

Le fait de baser toute l’étude, ou une grande partie, sur des personnes permetd’élargir le domaine de connaissance et d’imagination au delà de celui du développeur.

CHAPITRE 3. SPÉCIFICATION 19

Les prototypes ainsi créés, trouveront donc une utilisation et ne seront jamais je-tés comme est le cas avec de nombreuses applications développées sans utiliser cetteméthodologie puis refusées par les utilisateurs.

Les prototypes créés vont ensuite être améliorés, pour faciliter aux utilisateurs l’ex-pression de leurs besoins et les modifications sur une application fonctionnelle. Le faitd’ignorer ou de sous-estimer les scénarios est grande erreur que malheureusement beau-coup de développeurs commettent, alors qu’il n’existe aucun moyen meilleur d’extraireles informations et les détails depuis un scénario. Dans les autres cas, le développeurpeut tomber dans l’erreur de faire trop d’abstractions ou oublier des détails parfoisprimordiales.

3.2 Scénarios d’utilisation

3.2.1 Scénario 1

Utilisation de la wiimote comme une télécommande ou une souris : Anneest une étudiante à l’ENAC, elle a un abonnement ADSL avec des chaines de télévisiongratuites 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 unprotocole de communication Bluetooth. Le PC d’Anne supporte la communicationBluetooth mais elle ne connait pas beaucoup de détails sur la communication. Elleveut utiliser la manette Wiimote pour remplacer ou émuler une souris sans fil. Elle veutaussi mapper les boutons sur la wiimote pour spécifier des opérations de changementde chaine ou de commande du volume. Elle veut faire ça sans se plonger dans les détailstechniques et en utilisant une interface graphique simple.

3.2.2 Scénario 2

Régler la vitesse d’affichage des messages d’un sniffeur USB : SébastienHamdani est un étudiant en première année à l’ENAC, il fait son stage au laboratoired’informatique interactive. Son stage consiste à produire un pilote Linux pour la tablemulti-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


pilote fonctionnel, il doit utiliser un sniffeur USB qui enregistre toute les entrés-sortiesdepuis un port USB choisis au début de la phase. Il doit toucher à chaque fois les tablespour générer une communication USB vers son PC et avec une méthode d’ingénierieinverse il regarde les changements sur son écran pour savoir quel sont les champs quichangent de valeurs et quels sont les domaines des valeurs émis. Il modifie ensuiteson pilote et le recharge dans le noyau et teste s’il réussit à interpréter les donnéescorrectement.

Le problème est que dans la majoritée des cas, le flux de données échangées est trèsrapide et il ne réussit pas à le suivre. Il aime pouvoir régler la vitesse de défilement, leschamps à afficher et le domaine de tolérance pour la mise à jour des champs. Il aimerégler ces valeurs en utilisant un autre périphérique d’entrée comme une contrôleur midiet que les changements de ces options se font de façon dynamique. Ceci lui permet degagner plus de temps pour découvrir le protocole.

Exemple des informations brutes les plus lisibles provenant d’une entrée usb :

f65852c0 2451394143 C Ii:4:004:1 0:8 4 = 0000ff00

f65852c0 2451394195 S Ii:4:004:1 -115:8 4 <

f65852c0 2451402141 C Ii:4:004:1 0:8 4 = 0000fe00

f65852c0 2451402177 S Ii:4:004:1 -115:8 4 <

f65852c0 2451410143 C Ii:4:004:1 0:8 4 = 00fffe00

f65852c0 2451410182 S Ii:4:004:1 -115:8 4 <

f65852c0 2451418142 C Ii:4:004:1 0:8 4 = 0000fe00

f65852c0 2451418178 S Ii:4:004:1 -115:8 4 <

f65852c0 2451426142 C Ii:4:004:1 0:8 4 = 0000fe00

f65852c0 2451426178 S Ii:4:004:1 -115:8 4 <

f65852c0 2451434141 C Ii:4:004:1 0:8 4 = 0000fe00

f65852c0 2451434174 S Ii:4:004:1 -115:8 4 <

3.2.3 Scénario 3

Émulation de la souris pour les mouvement complexes : Olivier Sarajaest le responsable du groupe d’utilisateurs du logiciel Blender à Toulouse, un designerintéressé par les logiciels graphiques sous Linux, et il est membre de l’association Tou-


lousaine “Toulibre”. Il utilise Blender pour la création d’animations vidéos. Il utiliseaussi 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 plumedans Gimp et les exporter à Blender mais il n’obtient pas des bonnes figures. S’il essayed’utiliser les outils qui sont fournis par défaut il perd beaucoup de temps. Gimp contientpossède un langage de script pour l’automatisation des dessins, mais il n’a pas le tempsd’apprendre un nouveau langage et veut qu’il aura des outils graphiques pour spécifierses besoins.

Il veut utiliser l’outil de dessin dans Gimp et pense que théoriquement, les figuresqu’il veut dessiner sont faisables s’il aura la possibilité de déplacer la souris parfaitementsur des mouvements continus de va et vient sur chaque axe.

3.3 Brainstorming

3.3.1 Définition

Le Brainstorming1 est une technique de résolution créative de problèmes sous ladirection d’un animateur, un remue-méninges étant plus spécifiquement une réunioninformelle 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éthodede réunion de groupe soigneusement préparée puis tout aussi soigneusement exploitéepour trouver un nombre important d’idées publicitaires et promotionnelles pour lesclients et les clients potentiels de l’agence.

3.3.2 Principe

La principale promesse de la méthode est la récolte d’idées nombreuses et origi-nales. Deux principes sous-tendent le brainstorming : la suspension du jugement et larecherche 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 expri-mées et chercher à obtenir le plus grand nombre d’idées possibles.

1source : http ://fr.wikipedia.org/wiki/Brainstorming


Ainsi, les suggestions absurdes et fantaisistes sont admises durant la phase de pro-duction et de stimulation mutuelles. En effet, les participants ayant une certaine réservepeuvent alors être incités à s’exprimer, par la dynamique de la formule et les interven-tions de l’animateur.

3.3.3 Méthode

Pour réussir une séance de Brainstorming, l’animateur doit préparer des cataly-seurs pour inciter les intervenants à s’exprimer. Ces scénarios peuvent parvenir desquestionnaires déjà posés sur les utilisateurs. D’autres courts documents jugés intéres-sants 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 cellede la critique des idées posées dans la phase de la collecte. L’animateur ou l’un desintervenants doit aussi exprimer des idées trop imaginaire pour débrider la créativité enexprimant toutes ses idées sans réserve et sans autocensure. Les intervenants peuventrebondir 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 reformu-lant, classant, hiérarchisant sous une forme synthétique(réf. Figure.3.22) comme, par

2source : http ://lateralaction.com/articles/brainstorming/


exemple, sous la présentation d’une grille de décision. Les présents peuvent ensuitevaloriser 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 debrainstorming, qui étaient malheureusement limités en nombre de personnes et entemps, on peut maintenant extraire les besoins, sans quant même oublier les étudesbibliographiques déjà cités auparavant.

3.4.1 Émergence d’un modèle

D’après les études bibliographiques, le présent travail doit faire émerger un modèlede représentation de périphériques qui s’ajoute aux modèles précédents et avec quiprésente une abstraction se généralisant à un grand nombre de périphériques. Cetteabstraction permettra de faciliter la suite du travail.

3.4.2 Intégration au système Linux

Tout le travail doit être fonctionnel sur le système Linux. Il doit utiliser les primitivesdu système existantes et permettre d’ajouter ses nouvelles méthodes et fonctionnalitéssans 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’additionnercomme une méthode supplémentaire facile à ajouter et à supprimer pour inciter lesutilisateurs de ce système à l’intégrer chez eux tout en permettant toujours les autresméthodes des fonctionnements ordinaires.

3.4.3 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érerd’autres entrées ou des commandes directes aux applications du système. L’utilisateurpourra donc choisir comment gérer ses entrées sans lui imposer une seule configuration


particulière.

3.5 Conclusion

Dans ce chapitre, nous avons procédé grâce à une méthodologie participative etitérative à définir les besoins du projet. Nous avons cherché au début des scénarios réelsd’utilisation puis nous avons enrichi les scénarios par des séances de Brainstorming. Etenfin nous avons extrait les besoins principaux du travail.

CHAPITRE4 Analyse et conception

élémentaire

Dans ce chapitre, nous analysons de façon élémentaire les systèmes d’entrée impli-qués dans notre travail et nous procédons à une conception pour chacun des cas auxsolutions 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 detravail déjà expliqué. On doit analyser chaque partie du système général de la gestiond’entrée de Linux pour dégager toutes les solutions possibles d’intégration.

4.1.1 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 deuxgrandes parties. La première des deux se situe dans le noyau du système lui même, lesdéveloppeurs noyau ainsi que quelques concepteurs de dispositifs créent un pilote de leurpé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 niveauxd’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 main-tenant le rôle de Xorg et plus précisément le module d’entrée pour faire la gestion prin-cipalement du clavier et la souris et des périphériques semblables pour les applicationsgraphiques lancés. L’environnement Xorg est câblé pour être utilisé avec seulement une

CHAPITRE 4. ANALYSE ET CONCEPTION ÉLÉMENTAIRE 26

souris ayant au maximum 5 boutons, et un clavier ordinaire. Pour faire fonctionner unesouris spéciale ou d’autres dispositifs, il faut passer par des hack ou la soumission depilotes à l’intérieur du module d’entrée de Xorg.

Figure 4.1 — Abstraction de la constitution du système Linux

4.1.2 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 largespossibilités fournies. Le système HID qui est une sous partie du protocole USB, estmajoritairement utilisé pour gérer les périphériques d’entrée grâce à sa simplicité et sacapacité à 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éeest codé pour supporter le modèle HID. Ce support là est en lui même un sous-systèmecomplet, il est composé d’un parseur qui analyse les paquets du rapport HID et instanciele modèle du périphérique. il est aussi constitué de sous modules/pilote pour lier lesentités des périphériques au messages qu’il doit émettre. Et sans oublier un systèmede gestion des exceptions dans le cas où certains constructeurs ne respectent pas laspécification du modèle.


4.1.3 Communication DBus

4.1.3.1 Utilité

Les utilisateurs de la console Linux, ont parfois besoin de passer des données d’uneapplication vers une autre et pour répondre à ceci ils n’ont qu’à utiliser les tubes ou lesfichiers et créer des fichiers de script. Mais dans les systèmes graphiques, faire passerles 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 ilest très limité à des opérations de copier-coller sans aller plus loin. Les créateurs desenvironnements graphiques au dessus de Xorg tel que KDE ou Gnome ont choisi de sebaser sur leurs propres systèmes de communications pour commander une applicationdepuis une autre ou pour transférer quelques données.

4.1.3.2 Historique, Dcop, Bonobo, Corba

Au début, chaque environnement a créé son propre système, sous les premièresversions 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èlesdifférents s’inspirant parfois de Corba. Ensuite les développeurs de chacun des envi-ronnements ont voulu standardiser la façon de communiquer entre les applications desdeux environnements qui étaient séparés et corriger les failles conceptuels des anciensmodèles. Et c’est pour celà qu’ils ont lancé DBus.

4.1.3.3 Principe

DBus consiste en un serveur satellite dans Linux, dans le langage UNIX il est appeléeDaemon. Le serveur permet de router les communications d’une application vers uneautre. Et chaque application qui le supporte doit s’enregistrer dès son ouverture etse connecter à ce serveur. Elle exporte la liste de ses méthodes internes qu’elle veutexporter, dans la majorité des cas effectué automatiquement, et les autres applicationsauront donc un accès interne aux méthodes exportées.


4.2 Étude des périphériques

Dans cette partie, on résume les travaux effectués pour étudier le fonctionnementinterne de certains périphériques durant le stage. L’étude de ces périphériques, qui sonten majorité des périphériques multi-tactiles, a pour but de comprendre le fonctionne-ment et pouvoir ensuite proposer un modèle qui les supporte.

4.2.1 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 chacundes capteurs. Ces périphériques, en tant que vrai exemple d’“unités d’entrée” soulignentque dans le modèle à proposer, qu’il devra traiter ces unités de façon minimale et queles 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

4.2.2 Les Surface-Computers

Ce sont les premiers appareils à apporter la notion des surfaces multi-tactiles. Onpeut 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


d’appareils permet de comprendre ce que signifie ce nouveau genre d’interaction etcomment est déjà géré.

Le support des messages de l’entrée provenant de ce genre de périphériques ne peutpas être intégré dans les noyaux des systèmes. Donc la gestion restera dans l’espaceutilisateur, et le contrôle sera fait directement ou dans les cas nécessaire envoyé vers lenoyau du système.

4.2.3 Tablette Wacom

La tablette Wacom, qui permet d’émuler une souris mais tout en ajoutant d’autrescaractéristiques de simplicité et des critères de pression et de rotation ouvre la vue versla 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ésen 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 slideret des boutons dans chaque partie de l’écran tactile. Qui peuvent être vue comme lescomposants d’une même souris mais répétés avec un identifiant pour chacun et suivantune hiérarchie d’attachement.


4.2.4 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 presqueinconnue dans les autres périphériques. La table utilise un mécanisme transformantchacun des utilisateurs en une antenne en les liants à un type de signal émis. Lemodèle, pourra donc accepter d’instancier plusieurs fois un même type de dispositifs.

4.2.5 Tablette Stantum

La tablette Stantum est un écran TFT combiné à une technologie qui permet dereporter les évènements multi-tactiles qui figurent à la surface. La tablette n’est pasencore un produit finalisé et l’un des objectifs de notre travail au laboratoire est de créerun pilote pour la rendre fonctionnel sous Linux. Étant un périphérique USB HID, lepilote créé suivra le modèle défini. La notion des périphériques multi-tactiles n’existaitpas avant sous Linux. Et c’est pour ceci que beaucoup de temps a été consacré auxdiscussions sur les types de messages à intégrer dans le noyau et la façon avec laquellele noyau doit gérer le “multitouch”.

4.3 Conception élémentaire et Solutions

4.3.1 Intégration du configurateur au noyau Linux

L’une des solutions pour la création d’un configurateur d’entrée pour Linux est del’intégrer directement dans le noyau. Ainsi, la notion des périphériques virtuelles etdes “unités d’entrée” devra aussi être proposée pour l’intégration. Le résultat d’unetelle 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 pluspetits 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 basniveau 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 Documentationofficielle du noyau.


4.3.2 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 peutcommuniquer 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 uneintégration beaucoup plus facile puisque on ne modifie pas le code du noyau et leserveur reste accessible depuis l’espace utilisateur pour les applications. L’utilisationdu daemon est donc la solution à garder pour réaliser le configurateur d’entrée.

4.3.3 Intégration à la chaine traditionnelle d’entrée

On signifie par la chaine traditionnelle d’entrée la chaine commençant par le noyaului même en passant par le serveur Xorg et allant vers les applications. Si on appliqueles principes du configurateur à proposer des “unités d’entrée” à composer pour créerdes 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 dontcelui du la gestion d’entrée XInput, et qui est lui aussi composé de pilotes pour chaquepériphérique.

En résumé, on sera amené à générer une quantité très grande de code, sans aucunegarantie de stabilité de fonctionnement et d’efficacité.

4.3.4 Accès DBus aux applications

Les applications Linux sont compilées en donnant la possibilité aux autres à appelerleurs méthodes internes. Cet avantage n’est possible qu’avec DBus, qui est un protocolede communication inter-applications. Le support de DBus intégré dans les nouvellesbibliothèques tel que Qt et GTK, permet d’automatiser la procédure d’exportation desméthodes à l’aide des macros. C’est un très grand avantage puisque le configurateuraura la possibilité de communiquer directement aux applications sans entrer dans leslimitations et la complexité du serveur Xorg.


4.3.5 Principe d’injection des évènements

L’injection des évènements consiste à émuler la génération physique des messagesd’input depuis les périphériques. Le système qui génère les évènements est situé dansl’espace utilisateur, il communique avec le noyau Linux à travers un module spécifiqueappelé “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, lecode du message et la valeur. Et une fois les évènements injectés, il suivent la chainetraditionnelle d’entrée comme s’ils parviennent d’un périphérique physique. L’injectiondes évènements dans le noyau permet d’éviter l’écriture de pilotes noyau et d’autresXorg pour chaque périphérique virtuel créé. On aura aussi la liberté de générer n’im-porte quel évènements supportés de l’ensemble des autres périphériques.

4.3.6 Validation des choix

D’après les études précédentes, on remarque qu’on est obligé de créer un daemonséparé pour la gestion avancée de l’entrée et de la configuration. Pour encourager lescréateurs de distributions Linux d’intégrer notre code. On élimine aussi le choix depasser par les chemins que prend l’entrée en réalité en passant par le noyau puis parXorg, 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ériquesstandards. Et en dernier lieu, l’invocation de messages DBus fournit un très largecontrôle sur le domaine des applications et on surpasse le serveur Xorg ce qui signifiequ’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 propositionsde conceptions et validé ceux qui sont applicables.

CHAPITRE5 Modélisation et

Prototypage

Dans ce chapitre, nous exposons les premiers fruits de notre étude qui commencentpar la modélisation de l’entrée puis nous présentant les prototypes d’implémentationré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 icinotre modèle de représentation, de gestion et de configuration de dispositifs d’entrée.

5.1.1 Unités minimales d’entrée

La chose commune entre les dispositifs d’entrée si on raisonne du coté des transfertsbas niveau, est l’existance de petites entités transférées. Ces éléments ou unités mini-males d’entrée ont des structures très simples, et sont associés, surtout dans un modèlecomme celui du HID, à des propriétés et des caractéristiques additionnelles définissantl’ordre de grandeur, l’unité et l’utilisation.

Figure 5.1 — Unités d’entrée minimales

CHAPITRE 5. MODÉLISATION ET PROTOTYPAGE 34

Nous adhérons à ce modèle là, et on propose une amélioration dans les propriétésdes items. On propose d’augmenter l’espace des propriétés et inclure ces dernièresdirectement dans l’élément représentatif lui même. Les transferts utilisaient le modèlestandard conçu, mais la représentation dans la mémoire d’un périphérique sera alorsune hiérarchie entre ces unités d’entrée, ayant les caractéristiques dans les unités euxmêmes, et non dans les racines de l’arbre.

Ceci éliminera une gestion de flux et un traitement face à des ajouts mémoire. Maisle plus important est que le modèle restera simple à gérer et unique pour une grandepartie des dispositifs.

5.1.2 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éegérées de la même façon et qu’on peut après ajouter des traitements qui seront appli-cables 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 unereprésentation similaire, mais aucun d’eux n’a facilité l’exportation des unités d’entréevers l’espace utilisateur de façon simplifiée et combinée à la notion de configuration.

5.1.3 Projection de la configuration

L’un des limites du modèle HID est la non possibilité de modifier les propriétés desitems dynamiquement et avec le contrôle de l’utilisateur final. Ils sont embarquées dans


le dispositif lui même et traitées par le parseur du système d’exploitation pendant laphase de reconnaissance.

Faire approcher la configuration à l’utilisateur finale lui permet une plus grandeliberté 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 cecas comment il est simple d’inclure l’intervalle de sortie dans les propriétés de l’unité del’entrée elle même et de faire l’exportation suite à une opération mathématique simple.

5.2 Prototypage des modèles

5.2.1 Communications DBus

DBus est un outil permettant de faciliter la communication entre les applicationsdans les systèmes Linux. Mais il n’a pas été imaginé ou utilisé en tant qu’un outil decommande après traitement de l’entrée utilisateur.

En effet, le fait que les applications sous Linux sont conçues de façon à exporterleurs méthodes internes et de les exposer aux autres applications à travers DBus, nousinspire une vue particulière envers l’espace des applications. On peut voir cette espacecomme é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 applicationspour 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’en-trée avec laquelle on élimine l’ancien contrôle des systèmes comme Xorg. Cette élimi-


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 protocoleX11 de Xorg créé dans les années 80, et nécéssitant maintenant des astuces de pro-grammation pour supporter les nouvelles options de ces dernières années.

La communication DBus a été utilisé dans la production du premier prototypemontrant la possibilité pour un système Linux de gérer une entrée multi-tactile. Lesystème Xorg est totalement ignoré puisque les communications passerait à traversDBus. L’exemple a montré la grande liberté acquise et des options non possible mêmedans les autres systèmes.

Dans les autres systèmes, pour qu’ils supportent la gestion multi-tactile, ils ont euseulement deux possibilités, soit réécrire les applications, soit utiliser cette gestion dansun 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 etd’autres futures technologies sans être obligé à les réécrire. On utilise seulement laconfiguration à travers un daemon de gestion de l’entrée.

5.2.2 Injection de l’entrée

La communication DBus, peut dans certains cas être limitée. Cette limitation pro-vient 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


périphérique puis de communiquer avec le noyau et de lui demander de générer desmessages, comme s’ils étaient émis par des dispositifs réels. Les messages d’entrée qui neproviennent plus de sources physiques, suit le parcours de la gestion d’entrée standardsans que l’application où on veut l’utiliser se rend compte. L’injection nécessite émulerla structures des messages originaux de l’entrée. C’est à dire envoyer des structures dedonné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 à modifierl’entrée d’une souris avec l’injection de messages. Ces messages sont créés selon les pa-ramètres d’un autre dispositif utilisé pour gérer dynamiquement les options d’injectioncomme la vitesse et la valeur.

5.3 Conclusion

Dans ce chapitre, nous avons exposé notre modélisation de la gestion et la configu-ration de l’entrée. Nous avons aussi expliqué deux prototypes appliquant notre notion.

CHAPITRE6 Mise en oeuvre et

réalisation

Dans ce chapitre, on présente l’environnement avec lequel on a travaillé, les résultatsobtenus et les difficultées rencontrés.

6.1 Environnements Logiciel

6.1.1 Systèmes d’exploitation

Durant les six mois de travail, on a utilisé principalement des systèmes d’exploitationLinux openSUSE 11.1 et ubuntu 9.04.

On a travaillé sur les noyaux allant de la version 2.6.27 à la version 2.6.30. Et c’estcette dernière qui contient les modifications effectuées pour supporter la reconnaissanceet la génération des évènements multi-contacts. Ce même noyau puis celui qui suit le2.6.31 contiennent des pilotes pour des périphériques multi-tactiles de la Stantum, laDiamondTouch ainsi que le HP NTrig, tous développés en totalité ou en partie dansnotre laboratoire.

6.1.2 Le reste de l’environnement

On a aussi utilisé le gestionnaire de fenêtres de KDE 4, appelé KWin ainsi quele gestionnaire Compiz pour aboutir aux vidéos de démonstrations lancées sur le siteYoutube. 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

CHAPITRE 6. MISE EN OEUVRE ET RÉALISATION 39

les primitives de dessin. D’autres outils graphiques ont été aussi utilisés comme l’outilInkscape et Gimp pour la génération des objets graphiques dans l’interface de configu-ration.

6.2 Environnements Matériel

6.2.1 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 aulaboratoire d’informatique interactive, il a été utilisé pour le raccodrement desnombreux périphériques d’entrée testés. Il a été aussi utilisé pour le test et lecodage 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 dutravail. 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 detester quelques applications du monde Mac, conçus pour la programmation visuelleen utilisant des boites avec des entrées/sorties connectables.

6.2.2 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 multi-utilisateur 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 proto-coles.

Contrôlleur Korg périphérique(réf. Figure.6.1) utilisé habituellement pour les logi-ciels de musique. Nous l’avons utilisé pour configurer et contrôler l’injection del’entrée d’un autre dispositif comme la souris.


Figure 6.1 — Le contrôlleur Nanokontrol

6.3 Réalisation

6.3.1 Corps du configurateur

Le corps du configurateur n’est que l’association du code des prototypes déjà crééspuis traités de façon à les faire fonctionner de façon dynamique et sous forme d’unserveur Linux ou daemon.

Figure 6.2 — Architecture du configurateur

Le configurateur principale ne nécessite pas une interface graphique pour fonction-ner, il utilise seulement un minimum pour rester rapide et réactif. Mais le dévelop-pement d’un interface a été lancé pour faciliter son utilisation depuis les utilisateurssimples.

6.3.2 Interface graphique de configuration

L’interface graphique de configuration est la liaison avec laquelle un utilisateurnon expérimenté accède à la configuration. Dans cet interface l’utilisateur manipuledes objects graphiques qui sont ensuite traduits vers des commandes textuelles deconfiguration.


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 phasesd’avancement. Je tiens ici à signaler les majeurs problèmes rencontrés :

– Rattraper les connaissances acquises face à la vitesse avec laquelle évolue le sys-tème Linux,

– Le manque cruel de la documentation dans plusieurs parties du système Linuxainsi que pour beaucoup de bibliothèques utilisées,

– La suivie d’un processus de développement non habituel et l’intégration dans lacommunauté des développeurs existantes,

– Les pics dans la charge de travail à réaliser pendant une période très réduite detemps,

– La suivie des retours du travail après son lancement et maintenir le rythme dedéveloppement.

6.5 Chronogramme

Voici le chronogramme représentatif de la totalité du travail réalisé :


Figure 6.4 — Chronogramme du projet

6.6 Conclusion

Dans ce chapitre, nous avons montré l’environnement de travail que nous avonsvécu que ce soit coté matériel ou logiciels. Nous avons aussi présenté l’état des travauxréalisés et les problèmes rencontrés tout au long des six mois de travail.

Conclusion et

Perspectives

AU cours de mon stage de fin d’études, et en plus de la découverte d’un nouveaupays 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 beaucoupde choses à s’habituer avec. Et j’avais une mission à réussir pour laisser une bonne imageet une bonne impression.

La mission la plus difficile était de s’intégrer avec les méthodologies de recherche etanalyser les significations et les buts des papiers scientifiques et les points pas encoreexplorés ou dépassés pour les ajouter ou les améliorer. C’est pour ceci qu’une trèsgrande partie de mon travail consistait à analyser les modèles et proposer un nouveauplus général et plus applicable.

Le processus s’est basé sur les directives de mon encadreur et sa patiente pourm’enseigner les bonnes manières de se lancer dans des grands projets et d’extraction desbesoins. Le fait de se baser sur des scénarios réels et de les collecter depuis une gammelarge de personnes de différents niveaux permet d’élargir l’espace des connaissances etd’imagination. Les séances de Brainstorming étaient aussi un grand facteur de réussitepour la collecte des idées.

Les apports du stage sont alors assez nombreux, on cite alors la proposition dumodèle de gestion des périphériques et l’imagination de nouveaux systèmes qui rem-placent ceux qui existent déjà. Les apports personnels du stage en ce qui concerne lesconnaissances du système d’exploitation Linux et la procédure de son développementsont 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 desprototypes fonctionnant comme des preuves de concept de la possibilité de la réimagi-nation des systèmes pour les améliorer et découvrir les facettes cachés que personnesautres n’a essayé ou a eu le courage de les dévoiler.

Bibliographie

[AGA06] Pau Arumí, David García, and Xavier Amatriain. A dataflow pattern catalogfor sound and music computing. In PLoP ’06 : Proceedings of the 2006conference on Pattern languages of programs, pages 1–23, New York, NY,USA, 2006. ACM.

[Bux] William Buxton. More to interaction than meets the eye : Some issues inmanual input. http ://www.billbuxton.com/eye.html.

[Bux83] William Buxton. Lexical and pragmatic considerations of input structures.SIGGRAPH Comput. Graph., 17(1) :31–37, 1983.

[Bux90] William Buxton. A three-state model of graphical input. In INTER-ACT ’90 : Proceedings of the IFIP TC13 Third Interational Conferenceon Human-Computer Interaction, pages 449–456, Amsterdam, The Nether-lands, The Netherlands, 1990. North-Holland Publishing Co.

[Cha94] Stéphane Chatty. Extending a graphical toolkit for two-handed interaction.In UIST ’94 : Proceedings of the 7th annual ACM symposium on User in-terface software and technology, pages 195–204, New York, NY, USA, 1994.ACM.

[CLV07] Stéphane Chatty, Alexandre Lemort, and Stéphane Valès. Multiple inputsupport in a model-based interaction framework. In 2nd Annual IEEE In-ternational Workshop on Horizontal Interactive Human-Computer Systems,pages 179–186, Newport, Rhode Island, USA, October 2007. TableTop 2007,IEEE Computer Society.

[CMR90] Stuart K. Card, Jock D. Mackinlay, and George G. Robertson. The designspace of input devices. In CHI ’90 : Proceedings of the SIGCHI conference

BIBLIOGRAPHIE 45

on Human factors in computing systems, pages 117–124, New York, NY,USA, 1990. ACM.

[CMR91] Stuart K. Card, Jock D. Mackinlay, and George G. Robertson. A mor-phological analysis of the design space of input devices. Trans. Inf. Syst.,9(2) :99–122, April 1991.

[DF04] Pierre Dragicevic and Jean-Daniel Fekete. Support for input adaptability inthe icon toolkit. In ICMI ’04 : Proceedings of the 6th international conferenceon Multimodal interfaces, pages 212–219, New York, NY, USA, 2004. ACM.

[Dra04] Pierre Dragicevic. Un modèle d’interaction en entrée pour des systèmes inter-actifs multi-dispositifs hautement configurables. PhD thesis, École NationaleSupérieure des Techniques Industrielles et des Mines de Nantes, March 2004.

[FSB05] Clifton Forlines, Chia Shen, and Bill Buxton. Glimpse : a novel input modelfor multi-level devices. In CHI ’05 : CHI ’05 extended abstracts on Humanfactors in computing systems, pages 1375–1378, New York, NY, USA, 2005.ACM Press.

[Hin06] Ken Hinckley. Input technologies and techniques. In Andrew Sears andJulie A. Jacko, editors, Handbook of Human-Computer Interaction. LawrenceErlbaum & Associates, 2006.

[JSMJ94] Robert J. K. Jacob, Linda E. Sibert, Daniel C. Mcfarlane, and Jr. Integralityand separability of input devices. ACM Trans. Comput.-Hum. Interact.,1(1) :3–26, 1994.

[Shn97] Ben Shneiderman. Direct manipulation for comprehensible, predictable andcontrollable user interfaces. In IUI ’97 : Proceedings of the 2nd internationalconference on Intelligent user interfaces, pages 33–39, New York, NY, USA,1997. ACM.

[SVC04] Céline Schlienger, Stéphane Valès, and Stéphane Chatty. Une expérience deconception et de prototypage d’interfaces évoluées en milieu industriel. InIHM 2004 : Proceedings of the 16th conference on Association Francophoned’Interaction Homme-Machine, pages 165–172, New York, NY, USA, 2004.ACM.

[USB01] USB Implementers’ Forum. Device Class Definition for Human InterfaceDevice 1.11, June 2001.

BIBLIOGRAPHIE i

[USB04] USB Implementers’ Forum. HID Usage Tables, October 2004.

[WM03] Jingtao Wang and Jennifer Mankoff. Theoretical and architectural supportfor input device adaptation. In CUU ’03 : Proceedings of the 2003 conferenceon Universal usability, pages 85–92, New York, NY, USA, 2003. ACM Press.

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 ges-tion de la musique

DAEMON Disk And Execution MONitor, processus serveur dans Linux s’exécutanten 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

ANNEXEA Diffusion des résultats

des travaux

Puisque notre projet se repose sur des technologies libres, et s’intègre au systèmeLinux, nous avons eu un parcours un peu spécifique lors de nos travaux. Nous avonscontacté beaucoup de gens chacun travaillant sur une partie du système totale. Et à lafin 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. Unpatch est tout simplement la différence entre le système initiale et le système après lesmodifications développées.

La liste de diffusion principale de Linux est très active(ref. Figure.A.1), de l’ordrede 500 mails par jour. Et c’est pour ceci que d’autres listes existent, chacune d’elles sespécifie à une partie du système

Figure A.1 — La liste de diffusion de Linux

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éosde démonstration des possibilités du nouveau support de la gestion multi-tactile dunoyau. 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 unbureau ordinaire avec des commandes multi-tactiles. La vidéo dont vous voyez lescaptures(ref. Figure.A.2) est l’une entre plusieurs diffusées, mais elle est celle qui a prisle 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 78000 personnes jusqu’à main-tenant(ref. Figure.A.3). Mais nous avons eu aussi des retours depuis des personnesvoulant tester ces nouvelles possibilités sur leurs systèmes. Les retours les plus impor-tants proviennent de quelques sociétés qui fabriquent des écrans multi-tactiles et quivoulaient coopérer et garantir le support de leurs plateformes sous Linux.

Figure A.3 — Le nombre élevé de visualisations

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 desvisiteurs éventuels qui vont se diriger vers la page originelle qui parle du travail. Le sitedu laboratoire contenait, avant sa mise à jour, des simples pages textuelles sans aucunstyle défini. Donc nous avons édité les pages et fait les mises à jour pour arriver à unrésultat acceptable et qui attire le visiteur et le motive à revenir encore une fois.

Figure A.4 — Le nouveau site du laboratoire

ANNEXEB 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 unsaux autres et échanger des messages.

– Un daemon bus de messages exécutable, construit sur libdbus, vers lequel plu-sieurs applications peuvent se connecter. Le démon peut router les messages d’uneapplication à une ou plusieurs autres applications.

– Des bibliothèques de liaison qui s’appuyent sur des frameworks applicatives par-ticuliè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 queles personnes devraient utiliser car ils simplifient les détails de la programmationD-Bus. La libdbus est destiné à être une bibliothèque bas niveau pour les liaisonsde niveau supérieur. Une grande partie de l’API libdbus n’est utile que pour cetteliaison.

libdbus ne supporte que des connections un-à-un, tout comme une prise réseaubrute. Toutefois, plutôt que d’envoyer les flux d’octets sur la connexion, vous envoyezdes messages. Les messages ont un en-tête indiquant le type de message, et un corpscontenant une charge utile de données.

Le démon bus de messages est le noyau d’une roue. Chaque rayon de la roue estune connexion un-à-un à une application utilisant libdbus. Une application envoie unmessage au démon de bus sur sa parole, et le démon de bus transfère le message versd’autres applications liées au besoin. Pensez à le démon comme un routeur.

ANNEXE B. SYSTÈME DBUS vii

Le démon du bus a plusieurs instances sur un ordinateur ordinaire. Une instance ades restrictions de sécurité lourde sur les messages qu’elle accepte, et est utilisé pourla communication l’ensemble du système. Les autres instances sont créées par sessionutilisateur une connexion. Ces exemples permettent aux applications en session del’utilisateur de communiquer avec l’un l’autre.

Les démons utilisateur et systèmes sont séparées. Les messages émis seulement dansl’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 communicationinter-processus ou en réseau comme : CORBA, DCE, DCOM, DCOP, XML-RPC,SOAP, MBUS, Internet Communications Engine (ICE), et probablement des centainesd’autres. Chacune d’elles est adaptée à des types particuliers d’application. D-Bus estconç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 adresseles problèmes du cycle de vie des processus (quand démarrer et d’arrêter les com-posants de bureau).

2. La communication entre la session du bureau et le système d’exploitation, où lesystème d’exploitation inclue en général les démons du noyau et tout système ouprocessus.

Pour l’utilisation dans le bureau, GNOME et KDE ont l’expérience antérieure si-gnificative avec des solutions différentes IPC tels que CORBA et DCOP. D-Bus estconstruit sur cette expérience et soigneusement conçue pour répondre aux besoins deces projets de bureau en particulier.

D-Bus peut être utiles à d’autres fins que celle qu’elle a été conçue. Ses propriétésgé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 quele 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.

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’adop-ter plus facilement.

B.3 Concepts

Quelques concepts de base s’appliquent peu importe dans quel cadre d’applicationque vous utilisez pour écrire une application D-Bus. Le code exact que vous écrivezsera 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ésentela notion du chemin d’objet. Le chemin d’objet ressemble à un chemin sur le système,

ANNEXE B. SYSTÈME DBUS ix

par exemple un objet pourrait être nommé /org/kde/kspread/sheets/3/cells/4/5. Leschemins avec des noms simples et lisibles sont meilleurs, mais vous êtes libre de créerun objet nommé /com/mycompany/c5yo817y0c1y1c5b si elle a un sens pour votreapplication.

Les méthodes et les signaux

Chaque objet a des membres, les deux types de membres identifiés par leurs nomsqui sont :

Les méthodes : sont des opérations qui peuvent être invoquées sur un objet, avecdes éventuels arguments en entrée et des valeurs de retour en sortie.

Les signaux : sont les émissions en provenance de l’objet à tous les observateursintéressés de l’objet, les signaux peuvent contenir une charge utile de données.

Les proxies

Les proxies sont des objets natifs créés pour représenter un objet distant dans unautre processus. Il sont utilisés pour simplifier le code permettant d’appeler l’ancienobjet. Le code aura donc des chemins courts et la complexité sera caché dans le coeurdu proxy.

Les noms de bus

Lorsqu’une application se connecte au démon de bus, le démon attribue immédia-tement un nom, appelé le nom de connexion unique. Un nom unique commence parle caractère deux points “ :”. Ces noms ne sont jamais réutilisés pendant la durée devie du démon de bus, le nom donné fera toujours référence à la même application. Unexemple d’un nom unique peut être :34-907. Les chiffres après les deux points n’ontpas de sens autre que leur unicité.

rapport - pfe.boulabiar.netpfe.boulabiar.net/rapport.pdf · réf : 2009/ii/ soutenu à la session...

Documents