Rapport Pfe (Configurateur D'entrée Pour Linux)

Soutenu la session de Septembre 2009
Rf : 2009/II/
Universit de la Manouba
Ecole Nationale des Sciences de LInformatique
RAPPORT
DE
MEMOIRE DE FIN DETUDES
Prsent en vue de lobtention du titre

dINGENIEUR EN INFORMATIQUE
Par
Mohamed-Ikbel BOULABIAR
Sujet :
Configurateur dentre pour Linux
Organisme daccueil : Laboratoire dInformatique Interactive
Responsable : Pr. Stphane CHATTY

Encadr par : Pr. Stphane CHATTY
Supervis par : Pr. Nejib BEN HADJ ALOUANE
Rsum
USQU nos jours, les applications demeurent cbls pour un unique paradigme
dinteraction limit aux vnements produits par seulement le clavier et la sou-
ris. Les tudes concernant ladaptabilit et la configuration de lentre restent encore

trs peu nombreuses et non directement implmentables dans les systmes dexploitation surtout pour Linux. Dans ce travail, nous proposons un nouveau modle dentre
faisant intervenir le paradigme de configuration travers des adaptateurs entre les dispositifs matriels et les applications. Ce modle qui sintgre entre le noyau Linux et
les applications permet un large contrle en injectant des vnements dentre virtuels
et adaptables ou en invoquant les mthodes internes des applications existantes sans
ncessiter aucune modification ou rcriture.
Mots cls : Interaction Homme-Machine, Multi-tactile, Priphriques dentre, Techniques dinteraction, Adaptabilit, Accessibilit, Interfaces Post-WIMP.
Abstract
UST to our days, applications are still wired to a single interaction paradigm restricted to events produced by keyboard and mouse. Studies concerning the adap-
tability 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 doesnt require rewriting .
Key words : Human-Computer Interaction, Multitouch, Input Device, Interaction
Techniques, Adaptability, Accessibility, Post-WIMP.
Signatures des encadrants
Prof. Nejib BEN HADJ ALOUANE

(ENSI)
Prof. Stphane CHATTY

(LII-ENAC)
Remerciements
EST parce que jai beaucoup estim tous ceux qui mont cout, conseill, critiqu et encadr que je tiens leur faire part de toute ma gratitude, et plus
particulirement, je tiens remercier travers ces courtes lignes :

Mon encadrant le Professeur Stphane Chatty, pour mavoir incit mener bien
ce travail, pour son aide, son temps pass pour me guider, ses efforts pour mintgrer
dans lenvironnement, son dvouement et ses prcieux conseils.
Mon superviseur le Professeur Nejib Ben-Hadj-Alouane, parce quil a accept de me
superviser et suivre les dtails de lavancement de mon travail, ainsi que son aide et ses
conseils dans plusieurs tapes du projet.
Tous les membres de lquipe du laboratoire Stphane Conversy, Thierry Garcia,
Hlne Gaspard-Boulinc, Yannick Jestin, pour leurs aide, leurs remarques, leurs esprit
ouvert et leurs respect.
Ma famille dont je ne me permettrai pas doublier de la remercier, pour son soutien
la fois moral et matriel durant toute ma carrire et surtout durant les moments
difficiles.
Je tiens aussi remercier ceux qui ont partag le mme 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 Sbastien Hamdani
Et je tiens aussi remercier toute autre personne ayant contribu dune faon ou
dune autre, au bon droulement 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 socit Intuilab et les personnes qui aident dans les
salons de discussions IRC.
Table des matires
Remerciements
Introduction gnrale
1 Contexte du projet
1.1
Prsentation de lorganisme daccueil . . . . . . . . . . . . . . . . . . .
1.1.1
Lcole Nationale de lAviation Civile . . . . . . . . . . . . . . .
1.1.2
Le Laboratoire dInformatique Interactive . . . . . . . . . . . .
1.1.3
IntuiLab et son secteur dactivit . . . . . . . . . . . . . . . . .
1.1.4
Cadre du travail : Projet ShareIT . . . . . . . . . . . . . . . . .
1.2
Prsentation du travail demand . . . . . . . . . . . . . . . . . . . . . .
1.3
Processus de dveloppement adopt . . . . . . . . . . . . . . . . . . . .
1.3.1
La Datalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2
Le Maquettage . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3
Ralisation et prototypage . . . . . . . . . . . . . . . . . . . . .
2 tude pralable et tat de lart

2.1
2.2
Gestion de lentre . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1
Signification . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2
Diversits des dispositifs et des paradigmes dinteraction . . . .
2.1.3
Ncessit dun modle . . . . . . . . . . . . . . . . . . . . . . .
Modles et tudes Scientifiques . . . . . . . . . . . . . . . . . . . . . .
10
TABLE DES MATIRES
2.3
2.4
viii
2.2.1
Modles de transition . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.2
tude des performances et exprimentation . . . . . . . . . . .
11
2.2.3
Taxinomie des dispositifs . . . . . . . . . . . . . . . . . . . . . .
11
2.2.4
Lutilisation de plusieurs dispositifs . . . . . . . . . . . . . . . .
13
2.2.5
Les systmes multi-tactiles . . . . . . . . . . . . . . . . . . . . .
14
2.2.6
mergence de la configurabilit . . . . . . . . . . . . . . . . . .
15
Modle HID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3.1
Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3.2
Principe du modle . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3.3
Limites du modle . . . . . . . . . . . . . . . . . . . . . . . . .
17
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3 Spcification
18
3.1
Mthodologie participative . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2
Scnarios dutilisation
. . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2.1
Scnario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2.2
Scnario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2.3
Scnario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.3.1
Dfinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.3.2
Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.3.3
Mthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
Extraction des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.4.1
mergence dun modle . . . . . . . . . . . . . . . . . . . . . .
23
3.4.2
Intgration au systme Linux . . . . . . . . . . . . . . . . . . .
23
3.4.3
Interface de configuration . . . . . . . . . . . . . . . . . . . . .
23
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.3
3.4
3.5
4 Analyse et conception lmentaire
25
TABLE DES MATIRES
4.1
4.2
4.3
4.4
ix
Analyse des systmes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.1.1
Systme de gestion dentre de Linux . . . . . . . . . . . . . . .
25
4.1.2
Systme 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
tude des priphriques . . . . . . . . . . . . . . . . . . . . . . . . . .
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
Conception lmentaire et Solutions . . . . . . . . . . . . . . . . . . . .
30
4.3.1
Intgration du configurateur au noyau Linux . . . . . . . . . . .
30
4.3.2
Cration dun daemon spar . . . . . . . . . . . . . . . . . . .
31
4.3.3
Intgration la chaine traditionnelle dentre
. . . . . . . . . .
31
4.3.4
Accs DBus aux applications . . . . . . . . . . . . . . . . . . . .
31
4.3.5
Principe dinjection des vnements . . . . . . . . . . . . . . . .
32
4.3.6
Validation des choix . . . . . . . . . . . . . . . . . . . . . . . .
32
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5 Modlisation et Prototypage
5.1
5.2
33
Modlisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.1.1
Units minimales dentre . . . . . . . . . . . . . . . . . . . . .
33
5.1.2
Reprsentation dun priphrique . . . . . . . . . . . . . . . . .
34
5.1.3
Projection de la configuration . . . . . . . . . . . . . . . . . . .
34
Prototypage des modles . . . . . . . . . . . . . . . . . . . . . . . . . .
35
TABLE DES MATIRES
5.3
5.2.1
Communications DBus . . . . . . . . . . . . . . . . . . . . . . .
35
5.2.2
Injection de lentre . . . . . . . . . . . . . . . . . . . . . . . . .
36
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
6 Mise en oeuvre et ralisation

6.1
38
Environnements Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . .
38
6.1.1
Systmes dexploitation . . . . . . . . . . . . . . . . . . . . . . .
38
6.1.2
Le reste de lenvironnement . . . . . . . . . . . . . . . . . . . .
38
Environnements Matriel . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.2.1
Machines utiliss . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.2.2
Priphriques . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Ralisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.3.1
Corps du configurateur . . . . . . . . . . . . . . . . . . . . . . .
40
6.3.2
Interface graphique de configuration . . . . . . . . . . . . . . . .
40
6.4
Problmes rencontrs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.5
Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.2
6.3
Conclusion et Perspectives
43
Bibliographie
44
Acronymes
A Diffusion des rsultats des travaux
ii
iii
A.1 Travail avec la communaut de Linux . . . . . . . . . . . . . . . . . . .
iii
A.2 Gnration des vidos de dmonstration . . . . . . . . . . . . . . . . .
iv
A.3 Les retours reus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
A.4 Design du site du laboratoire . . . . . . . . . . . . . . . . . . . . . . . .
B Systme DBus
vi
TABLE DES MATIRES
xi
B.1 Prsentation de D-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
B.2 Applications D-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
B.3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Liste des figures
1.1
Mthodologie de travail IntuiSignTM . . . . . . . . . . . . . . . . . . . .
2.1
Exemple de priphriques, tablette et TrackPen, manette Wiimote et
une spaceball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Modle de transition 3 tats de Buxton . . . . . . . . . . . . . . . . .
10
2.3
Application du modle sur la souris . . . . . . . . . . . . . . . . . . . .
11
2.4
Taxinomie de Buxton . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.5
Lespace de conception de Card [CMR90] . . . . . . . . . . . . . . . . .
13
2.6
Lutilisation de deux souris avec deux mains dans la plateforme Whizz
14
2.7
Les surfaces computer : Microsoft Surface et IntuiFace dIntuiLab . . .
14
2.8
Exemple de configuration de lentre avec ICon . . . . . . . . . . . . .
15
2.9
Principe du transfert HID . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1
Conception itrative et participative . . . . . . . . . . . . . . . . . . . .
18
3.2
Le rsultat dun Brainstorming . . . . . . . . . . . . . . . . . . . . . .
22
4.1
Abstraction de la constitution du systme Linux . . . . . . . . . . . . .
26
4.2
Quelques phidgets : des boutons, des sliders et des capteurs divers . . .
28
4.3
Tablette Wacom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.1
Units dentre minimales . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.2
Reprsentation dun priphrique . . . . . . . . . . . . . . . . . . . . .
34
LISTE DES FIGURES
xiii
5.3
Principe dinclusion de la configuration dans le modle . . . . . . . . .
35
5.4
Architecture de la communication DBus utilise . . . . . . . . . . . . .
36
5.5
Architecture de linjection de lentre . . . . . . . . . . . . . . . . . . .
37
6.1
Le contrlleur Nanokontrol . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.2
Architecture du configurateur . . . . . . . . . . . . . . . . . . . . . . .
40
6.3
Interface de gnration des paramtres pour le configurateur . . . . . .
41
6.4
Chronogramme du projet . . . . . . . . . . . . . . . . . . . . . . . . . .
42
A.1 La liste de diffusion de Linux . . . . . . . . . . . . . . . . . . . . . . .
iii
A.2 Capture de la vido diffuse . . . . . . . . . . . . . . . . . . . . . . . .
iv
A.3 Le nombre lev de visualisations . . . . . . . . . . . . . . . . . . . . .
iv
A.4 Le nouveau site du laboratoire . . . . . . . . . . . . . . . . . . . . . . .
B.1 Schma prsentant les Concepts de DBus . . . . . . . . . . . . . . . . . viii
Introduction gnrale
A majorit des utilisateurs des ordinateurs savent obligatoirement comment taper

sur un clavier et faire bouger le pointeur lcran en dplaant la souris. Les
applications quotidiennes ainsi que les systmes dexploitation ont t conus pour
supporter ces deux priphriques et ils sont prpars pour que linteraction se fera
toujours de la mme faon. Notre faon de contrler les ordinateurs est devenue alors
un standard que les fabricants du matriel et les diteurs des logiciels y compris-les
systmes se sont mis daccord de la garder.
Il existe nanmoins bien dautres manires de contrler les applications, les manettes
de jeu sont utilises, les contrlleurs midi pour les applications musicales ainsi que les
outils et les surfaces tactiles. Il existe mme des priphriques trs spcialiss utiliss
dans les applications de dessin 3D.
Chaque jour de nouveaux dispositifs apparaissent mais la chose commune entre
tous ces dispositifs est quils sont tous adapts un contexte dutilisation donn et
fig. On peut pas malheureusement utiliser la manette pour remplacer la souris ni le
contrlleur midi pour remplacer un clavier. On ne peut pas mme les utiliser hors de
leurs contextes trs restreint.
Par contre, beaucoup de travaux de recherche montrent des analyses sur la possibilit quun dispositif remplace un autre. Et rien encore ne peut nier quon peut trouver
parfois des contextes dutilisation beaucoup plus naturels et adapts que ceux figs par
le constructeur ou par le systme dexploitation.
Cest dans ce cadre que notre projet se situe. Nous tudions les techniques dadaptation du contexte de lutilisation des dispositifs dentre. Nous cherchons rendre cette
utilisation configurable et dans la porte de lutilisateur final. Nous cherchons enlever
les limitations des systmes et mme des fabricants pour lutilisation quotidienne en se
rfrant des modles scientifiques et tudes de scnarios rels des utilisateurs.
INTRODUCTION GNRALE
Notre tche commence par llaboration dun modle gnrale et simple capable de
supporter lintgration de la configuration. Les travaux seront applicables sur le systme
dexploitation Linux et cherchent amliorer la faon dinteragir avec lordinateur et de
faciliter la recherche dautres paradigmes dinteraction. Nous avons aussi concentr une
grande partie de notre travail sur les nouvelles techniques dinteraction multi-tactiles
ou multitouch.
Lorganisation du rapport sera comme suit :
Le premier chapitre est un chapitre introductif prsentant le contexte dans lequel
a t merg le projet : le sujet, lorganisme daccueil et la mthodologie adopte,
Le deuxime chapitre est ddi une tude pralable et un tat de lart des
travaux de recherche dans ce domaine ainsi que les grands systmes utiliss,
Le troisime chapitre comporte une spcification des besoins du projet suite
une tude de scnarios rels dutilisation,
Le quatrime chapitre est consacr pour lanalyse des systmes modifier et la
conception lmentaire des solutions,
Dans le cinquime chapitre, nous exposons notre modlisation des priphriques
et les travaux de prototypage raliss,
Le dernier chapitre prsentera le travail ralis, lenvironnement et les difficults
rencontrs.
CHAPITRE
Contexte du projet
Dans ce chapitre, Nous exposons le contexte gnral du projet. On prsente en

premier lieu lorganisme daccueil, le travail demand et on termine par lexplication
de la mthodologie de travail quon a suivi.
1.1
1.1.1
Prsentation de lorganisme daccueil

Lcole Nationale de lAviation Civile
Lcole nationale de laviation civile (ENAC) est une grande cole aronautique
situe Toulouse (Haute-Garonne). Cest un tablissement public caractre administratif plac sous la tutelle du Ministre de lcologie, de lnergie, du Dveloppement
durable et de la Mer. Cette tutelle est exerce en pratique par la Direction Gnrale
de lAviation Civile (DGAC). LENAC est membre associ de lUniversit de Toulouse
et membre du ple de comptitivit Aerospace Valley.
A lexception du domaine de la construction aronautique, lcole assure des formations pour la plupart des mtiers de laviation civile : exploitation aronautique,
exploitation aroportuaire, gestion du trafic arien, scurit et sret aronautiques,
systmes de communication, navigation et surveillance. LENAC est la fois une cole
dingnieurs et un centre national de formation de la DGAC et au profit dautres institutions franaises ou trangres ; elle assure notamment une trs importante activit
de formation continue.
Fonde en 1948 Orly, lcole a t dlocalise Toulouse en 1968. Elle est aujourdhui implante sur le complexe scientifique de Rangueil, proximit du futur
Aerospace Campus.
CHAPITRE 1. CONTEXTE DU PROJET
1.1.2
Le Laboratoire dInformatique Interactive
Le dpartement mathmatiques et informatique consacre une importante partie

de son activit de recherche et denseignement lingnierie des systmes informatiques,
et en particulier lIHM. Il est co-habilit dlivrer des diplmes dans un master pro
dingnierie des systmes interactifs (avec les universits Toulouse 1 et Toulouse 3) et
un mastre dingnierie systme (avec lEcole Nationale Suprieure de lAronautique
et de lEspace).
Le laboratoire dInformatique Interactive a t cr en 2006. Il est issu de collaborations croises entre lENAC, lex Centre dEtudes de la Navigation Arienne (CENA),
et la socit IntuiLab.
Le laboratoire a pour mission de mener des recherches amont et transversales sur

lingnierie des systmes interactifs, et les thories, modles et outils informatiques
associs. Le laboratoire bnficie pour cela des expriences concrtes de dveloppement
de systmes de ses partenaires.
Il contribue au dveloppement doutils gr par ces derniers. Sa premire mission
consiste reprendre sa charge les travaux de recherche fondamentale sur les problmes
rencontrs par ses partenaires, et collaborer sur leurs thmes de recherche appliqus.
Le laboratoire est dirig par Stphane Chatty et il est constitu de Stphane
Conversy, Yannick Jestin, Thierry Garcia, Hlne Gaspard-Boulin et de trois doctorants. Il est impliqu dans des projets sur les thmes suivants :
un thme Visualisation dinformation, perception, codage dinformation. Projets
Kabuki, Anims
un thme Techniques et styles dinteraction : graphisme, animation, multimodal,
geste. Projet Mammi
un thme Modlisation des logiciels interactifs : architecture, excution, langage
Projets IntuiKit, Sauvage, Anims, Mammi, I* et Share-IT
un thme Ingnierie des logiciels interactifs : mthodes de conception, gnie
logiciel multidisciplinaire Projets Erasmus, Callisco
1.1.3
IntuiLab et son secteur dactivit
La socit Intuilab, partenaire de lENAC dans plusieurs projets de recherche, prend

en charge la gestion administrative et financire de ce stage. Intuilab est une PME innovante cr en 2002 par trois chercheurs en IHM dont Stphane Chatty. Elle sest depuis
dveloppe grce son expertise sur le domaine de linteraction Humain-Machine et
sest spcialise dans la ralisation de logiciels pour surface tactile (surface computing).
Elle comporte actuellement 25 employs et elle a ralis un chiffre daffaires de 1,8

millions deuros en 2008. Son offre se dcoupe en une branche matrielle, avec lIntuiface
Surface Computer (anciennement Intuiface) et une branche service. Cette branche service se distingue par lemploi de mthodes de conceptions centres utilisateurs et par
une quipe pluridisciplinaire (ergonomes, graphistes, architectes, concepteurs), ainsi
que par une expertise technique et lutilisation dateliers de dveloppement internes :
Intuikit et Intuiface
IntuiLab est spcialise dans lidation, la conception et le dveloppement dapplications interactives innovantes. IntuiLab couvre quatre domaines dexpertise : la
rnovation des interfaces de leurs clients, la numrisation des processus mtiers, la
transformation dides en produits ou services intuitifs, lanticipation des modes dinteractions innovants.
1.1.4
Cadre du travail : Projet ShareIT
ShareIT est projet de recherche qui est commenc au dbut de 2008 pour trois ans
et sponsoris par Aerospace Valley. Lobjectif du projet est de concevoir et de tester
les interfaces tactile qui seront partag par le pilote et le copilote dans le cockpit dun
avion. Cela ncessite des technologies multitouch et le projet comprend :
la conception matrielle, faite par Stantum
Expertise oprationnelle, introduit par lENAC
Analyse des besoins et des tests, effectus par Thales Avionics
Interface design et le prototypage, effectu par IntuiLab
Support logiciel pour le multitouch, ralis par notre laboratoire lENAC.
1.2
Prsentation du travail demand
Le projet se situe dans le cadre des tudes de la gestion des dispositifs dentre
qui sont menes depuis longtemps et qui nincluent pas seulement les priphriques
standards comme le clavier et la souris. Dans ce cadre, une tude doit tre ralise
sur les diffrents dispositifs dentre existants ainsi que leurs reprsentations dans les
systmes dexploitations et dans les publications scientifiques.
Les modlisations existantes sont dans la plupart des cas dpasss par rapport
aux nouveaux priphriques qui sont entrain dapparatre actuellement, que ce soit
dans les publications scientifiques ou dans les modles implments dans les systmes
dexploitation pour les grer.
Les modles utiliss considrent principalement le clavier et la souris comme priphriques principales dentre, alors que les nouvelles innovations dans le domaine
de linformatique ne font qumerger de nouvelles modalits et techniques dinteraction non habituelles et qui ont commenc gagner le terrain, ainsi quune utilisation
courante comme les tabletop ou les ordinateurs de table.
Il est demand de faire merger un modle de gestion dentre rpondant aux nouvelles contraintes en fournissant des solutions pour les problmes existants. Le but est
aussi de minimiser leffort faire pour les dveloppeurs des pilotes des nouvelles priphriques sils veulent chapper des limitations dues larchitecture des systmes et
des applications non adapts une gestion avance de lentre de lutilisateur.
1.3
Processus de dveloppement adopt
Le processus de dveloppement adopt dans llaboration de ce travail nest pas

celui traditionnel et sattache en grande partie au processus IntuiSign dvelopp par la
socit InuiLab [SVC04]. Ce processus suit 3 phases principales :
1.3.1
La Datalyse
Cette opration se rsume la collecte dinformations et leur analyse (tches de lutilisateur, systmes existants, technologies disponibles, etc.) pour fournir le bon matriel
pour la conception (cahier des charges, points clef de conception, tendances graphiques,
profiles utilisateurs, scnarios dusage, etc.). La procdure de la collecte dinformation

contient aussi en grande partie ltude des publications scientifiques existantes comme
source dinformation et danalyses anciennement effectus ainsi que ltude des scnarios rels dutilisation partir de chaque profil ventuel dutilisateur.
1.3.2
Le Maquettage
Cette tape consiste crer des petites maquettes ou des bouts de code ou MashUps,
appel aussi code exploratoire. Cette exploration qui peut mme aller dans les projets
de pure IHM utiliser des modles papier.
La programmation exploratoire, les illustrations et les valuations lmentaires permettent de valider des choix et dliminer dautres dans une tape assez prliminaire.
Malgr le temps que cote cette tape, elle permet de le rattraper en liminant un
temps qui sera consomm suite limplication dans des mauvais choix une tape
assez avance.
1.3.3
Ralisation et prototypage
Cette tape consiste la cration de prototypes avancs pouvant tre transforms

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 itrative de
prototypes aide raffiner et illustrer les solutions et permettent une transition graduelle
vers limplmentation finale.
Figure 1.1 Mthodologie de travail IntuiSignTM
CHAPITRE
tude pralable et tat

de lart
Dans ce chapitre, on prsente ltat de lart des tudes scientifiques ralises sur la
gestion de lentre. On les classe par sujet et domaine de recherche. On cite aussi les
travaux sur linterfaage multi-tactile. Et on termine par la prsentation du protocole
HID et ses sources scientifiques.
2.1
2.1.1
Gestion de lentre
Signification
La mthode la plus commune pour transfrer les ordres vers lordinateur est de les
passer travers des priphriques spcifiques qui sont les priphriques dentre. Toute
personne qui utilise un micro-ordinateur est habitue taper sur un clavier, cliquer sur
des boutons, ouvrir des menus et dplacer un pointeur sur lcran. Les deux moyens
physiques les plus utiliss sont alors srement le clavier suivi par la souris. Cest une
faon de contrler une machine et elle prsente en partie, un paradigme dinteraction
largement utilis appel WIMP.
2.1.2
Diversits des dispositifs et des paradigmes dinteraction
Depuis longtemps, les industriels ainsi que les chercheurs nont pas cess de proposer plusieurs dispositifs permettant de faire une tche particulire dune faon plus
rapide ou plus parfaite. Plusieurs nouveaux priphriques physiques sont apparus, des
manettes de jeu, des contrleurs midi, sans oublier les TrackPad ou les TrackPoint.
CHAPITRE 2. TUDE PRALABLE ET TAT DE LART
Figure 2.1 Exemple de priphriques, tablette et TrackPen, manette Wiimote et

une spaceball
Vu le nombre trs grand de ces dispositifs, certains constructeurs ont par exemple
cr des objets qui substituent une souris en point de vue systme mais qui ont des
structures et des critres compltement diffrents. La substitution dune souris par un
TouchPad ou un TrackPad est faite mais dans la majorit des cas on ne tient pas
compte des avantages ou des inconvnients dune structure physique diffrente.
Plusieurs tudes et des taxinomies ont t aussi labors comme rponse cette
diversit et pour extraire les spcificits ventuelles dun dispositif par rapport un
autre[Bux83]. Mais chaque fois, lutilisation dun priphrique ne tient pas toujours
compte des rsultats prouvs ou des taxinomies et elle est directement lie celle que
le dveloppeur initial a choisi. Cette diversit de priphriques a impliqu une diversit
doutils combins chaque dispositif. Il a alors fallu avoir un modle qui facilite la
gestion de priphriques malgr la diversit et rduit les problmes.
2.1.3
Ncessit dun modle
Lorsquon parle de diversit entre dispositifs, on doit parler aussi de la diversit

dans limplmentation des pilotes et des sous-systmes pour les grer. Vu cette diversit
universelle que ce soit cot pilote pour le noyau du systme dexploitation ou mme cot
liaison directe avec les applications et la production des vnements, un modle demeure
ncessaire pour proposer une mthode commune pour simplifier la reconnaissance du
dispositif en premier lieu puis la configuration et ladaptation en se basant sur les
composites de ce modle l.
Un modle unique ou au moins groupant la majorit des cas possibles doit liminer
une complexit de gestion hasardeuse dans les systmes, faciliter la cration des couches
10
implmentant une nouvelle utilisation des priphriques mais il doit tre aussi simple mais pas plus simple dans le sens o il ne faut pas rduire des caractristiques
primordiales.
2.2
Modles et tudes Scientifiques
Lmergence des dispositifs physiques tait le rsultat de la coopration entre les

scientifiques et les socits impliqus. Les tudes scientifiques ont permis dextraire
les rsultats des expriences et de les interprter pour dgager les points forts dun
dispositif et la meilleure application pour tre utilis avec.
2.2.1
Modles de transition
Des modles de gestion des messages mis lentre sont aussi apparus afin de
simplifier linterprtation des actions excuter pour le contrle du systme. Lun des
ces modles est celui de la machine trois tats de William Buxton[Bux90]. Buxton
a propos une faon pour grer les dispositifs de pointage qui consiste faire une
abstraction rsumant lespace des vnements une machine 3 tats.
Figure 2.2 Modle de transition 3 tats de Buxton
Tout priphrique de pointage sera projet sur la machine trois tats et les vnements grs sont un sous ensemble de la machine globale, il a donc simplifi normment la partie de gestion de ce genre de dispositifs dans le systme dexploitation. Et
la gestion sera gr de faon dterministe.
11
Figure 2.3 Application du modle sur la souris
2.2.2
tude des performances et exprimentation
Plusieurs tudes de performances ont t effectues sur des tranches de personnes afin danalyser les caractristiques des dispositifs et de les classer en terme
dadaptabilit[JSMJ94]. Ltude de Jacob a permis de dire que chacun des priphriques est adapt pour faire une tche dune faon meilleure quun autre. Il a aussi
prcis quen terme de contrlabilit, on peut subdiviser les priphriques en sous composants dcrits par la notion de la sparabilit et quil nest pas possible pour dautres
dcrite par la notion de lintgralit.
Des dimensions sparables selon Jacob peuvent tre contrls sparment sans nuire
ni aux performances finales ni la prcision comme le contrle des couleurs dun objet et
ses dimensions. Alors que les critres intgraux ne peuvent pas tre spars en contrle
et prserver les performance. Et on prend comme exemple le contrle des dimensions
selon les axes x et y dans une souris.
Cette tude est trs importante car elle explique pourquoi la substitution dune
souris, o le contrle des axes se fait simultanment, ne peut pas tre remplace par
une manette contenant des boutons ou des flches spars pour ce mme contrle. On
a donc une tude qui nous guide sur les limites de la configuration et le morphisme
entre dispositifs.
2.2.3
Taxinomie des dispositifs
Vu que lespace des priphriques ainsi que les caractristiques de chacun est entrain
de sexploser, les chercheurs ont tabli plusieurs taxinomies pour classifier les dispositifs.
12
Aprs avoir fait cette rpartition et indexation la gestion sera faite selon les critres
dcrites.
Buxton a class les priphriques dans son papier[Bux83] sur un tableau selon les
deux critres des proprits physiques sentis et le nombre de dimensions reportes. Ce
classement donne une premire ide sur limpossibilit dun dispositif tre utilis dans
un contexte impliquant plus de dimensions (rf. Figure.2.4).
Figure 2.4 Taxinomie de Buxton
Dautres 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 proprits structurelles dun priphrique. Il a donc prsent les notions de la prcision, de
la vitesse, des erreurs, du temps ncessaire apprendre utiliser et mme la quantit
ncessaire de donnes transfrer entre le priphrique et lordinateur pour rapporter
lvnement.
Cette tude de Card semble la plus complte puisquelle fait intervenir un grand
nombre de critres pour le classement et en ajoutant une tude dhirarchie entre les
petits composants dans un seul dispositif.
Dans la figure prcdente (rf. Figure.2.5) on remarque un classement des anciens
dispositifs, mais aussi une dmontration des zones vides qui peuvent influencer la
construction de nouveaux priphriques supportant ces dimensions non encore exploites.
13
Figure 2.5 Lespace de conception de Card [CMR90]
2.2.4
Lutilisation de plusieurs dispositifs
Des anciens tudes ont imagins des interactions avec plusieurs dispositifs en mme
temps et avec les deux mains. Lune de ces publications[Cha94] a montr limportance
de la configuration sur un processus similaire pour spcifier les objectifs de chacun des
matriels utiliss.
Dans la figure prcdente qui reprsente un ancien systme de configuration de
lentre appel Whizz(rf. Figure.2.6), lutilisateur contrle un trait laide de deux
pointeurs de deux souris.
Dautres tudes plus rcentes ont repris ce mme point en prsentant un modle de
configuration qui commence par le filtrage des sources de lentre jusqu lencapsulation de ces sources et lajout dadaptateurs[CLV07]. Lhirarchie a t aussi tudi et
un dispositif est reprsent en tant quun arbre de plusieurs sous composants.
14
Figure 2.6 Lutilisation de deux souris avec deux mains dans la plateforme Whizz
2.2.5
Les systmes multi-tactiles
Les systmes multi-tactiles sont les systmes qui ont le plus de succs ces dernires
annes, vu que des grandes socits investissent dans lamlioration de ce genre de
priphriques.
Figure 2.7 Les surfaces computer : Microsoft Surface et IntuiFace dIntuiLab
Les surfaces multi-tactiles sont les derniers priphriques appliquant la notion de la

manipulation directe invent par Shneiderman[Shn97]. La manipulation directe dcrit
les systmes o ont a une visibilit des objets dintrt et des actions possibles, ces
actions sont rapides, rversibles et incrmentales. Dans ce genre de manipulation on
a un remplacement dune syntaxe complexe par des actions simples semblables aux
manipulations dans la vie relle.
2.2.6
15
mergence de la configurabilit
Aprs lmergence des dispositifs en nombre et en fonctionnalits, des tudes sont

apparus pour grer la configuration des priphriques. Les travaux autour de ICon
(Input Configurator) sont ceux les plus volus.
ICon est un prototype logiciel qui permet dutiliser les entres des dispositifs physiques et de les lier de faon graphique des adaptateurs pour modifier dynamiquement
leur fonctionnement sur une application de dessin. Lutilisateur place les blocs dsignant
les entres de manire avoir une sortie pour chaque variable, puis les lient des adaptateurs comme les sommateurs ou des multiplicateurs pour modifier le flux. Le modle
tait lun des premiers avoir mis en cause la faon classique et statique dutiliser les
priphriques et proposer des dfinitions pour la configurabilit et laccessibilit.
Figure 2.8 Exemple de configuration de lentre avec ICon
Dans la figure (rf. Figure.2.8) on voit comment les entres provenant de la tablette
Wacom sont connectes aux options de lapplication. Lunit dentre indiquant la
pression est utilise pour modifier la grandeur du trait pendant le dessin. Les autres
entres sont utiliss pour le dplacement de faon quivalente une souris.
Le problme du modle de Dragicevic[DF04] est quil ne propose pas une reprsentation des units dentres dans un seul dispositif de faon dynamique. On doit crer
les modles des dispositifs en avance et ceux virtuelles provenant dune combinaison
entre plusieurs dispositifs ne sont pas applicables. Il ny 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.
Lautre tude de configuration[WM03] ne traite que deux priphriques qui sont le
clavier et la souris malgr que le papier prsente un traitement des units dentre avec
des petites oprations algbriques.
2.3
2.3.1
16
Modle HID
Prsentation
Le modle HID, ou Human Interface Device est un standard faisant partie du

protocole USB et labor par la majorit des grandes socits de production de priphriques ou de systmes tel que Microsoft, Intel, Logitech et plein dautres. Ce
consortium dentreprises sest group pour trouver une solution permettant de faciliter
la gestion des nouveaux priphriques. Une gestion de faon simplifier la cration de
pilotes pour les systmes dexploitation.
Avant ce modle l, les constructeurs doivent choisir entre deux solutions : Soit se
contenter aux standards existants qui sont trs limits mais ayant un support dans
tous les systmes. Soit utiliser un autre standard mais fournir les pilotes sur tout les
configurations pour tre fonctionnel.
Les industriels choisissaient la premire solution, mais suite lvolution qui est apparue et de lmergence des technologies, ils ont vu la ncessit dun modle dynamique
pour la dcouverte des composants dun dispositif quelconque.
2.3.2
Principe du modle
Le modle consiste crer un pilote HID unique dans les systmes dexploitation
et une partie prsentatrice embarque dans les priphriques. Le dispositif, une fois
branch lordinateur, entre dans une procdure didentification en envoyant un rapport(rf. Figure.2.9) dcrivant les petits composants qui le constituent avec lhirarchie,
les domaines des valeurs ainsi que lunit et en allant proposer la meilleure utilisation.
Figure 2.9 Principe du transfert HID
Le pilote reoit les informations du descripteur report descriptor, et analyse les

lments de ce rapport puis constitue en mmoire le modle permettant de faire fonc-
17
tionner le priphrique. Le consortium des USB Implementors a aussi publi des tables
dusages fournissant les diffrents possibilits quun report descriptor peut fournir pour
chaque gamme de priphriques.
Le modle HID est aussi dvelopp dune faon fournir mme un descripteur
physique pour spcifier pour chaque item quel est le meilleur membre du corps humain
utiliser.
2.3.3
Limites du modle
Le modle HID constitue un grand saut permettant de faciliter aux constructeurs de

priphriques ainsi quaux producteurs des systmes dexploitation la reconnaissance
des nouveaux matriels. Mais malgr a, il ne permet pas de modifier et dynamiser une
configuration des options fournies selon les besoins de lutilisateur.
2.4
Conclusion
Dans ce chapitre, on a prsent les principales tudes scientifiques qui ont trait
la gestion de lentre en relation avec nos travaux. On a aussi expos le modle HID
en tant que modle trs utilis et qui a t invent pour faciliter cette gestion dans
les systmes dexploitation. Il nous faut maintenant spcifier les scnarios possibles
dutilisation depuis lesquelles on extrait les besoins.
CHAPITRE
3.1
Spcification
Mthodologie participative
Comme dcrit dans le papier [SVC04], la mthodologie utilise ft celle itrative

et participative. Cette manire de rsoudre et grer les projets permet dimpliquer un
groupe de personnes de faon oppos lancienne mthodologie, o seulement chacun
doit prsenter un rsultat la fin sans parfois que les autres membres et chercheurs
soient conscients de chaque tape quil a atteint, et sil a particip ou non aux choix et
la modification des solutions.
Cette mthode(rf. Figure.3.1) permet dincorporer les ides des personnes du
groupe et de rpartir la responsabilit sur tout les membres mais aussi de partager
la russite. Lextraction des besoins ont comme source les scnarios dutilisation relle
suite des questionnaires poss sur des personnes et interprts ensuite selon les dtails
de chaque personne.
Figure 3.1 Conception itrative et participative
Le fait de baser toute ltude, ou une grande partie, sur des personnes permet
dlargir le domaine de connaissance et dimagination au del de celui du dveloppeur.
CHAPITRE 3. SPCIFICATION
19
Les prototypes ainsi crs, trouveront donc une utilisation et ne seront jamais jets comme est le cas avec de nombreuses applications dveloppes sans utiliser cette
mthodologie puis refuses par les utilisateurs.
Les prototypes crs vont ensuite tre amliors, pour faciliter aux utilisateurs lexpression de leurs besoins et les modifications sur une application fonctionnelle. Le fait
dignorer ou de sous-estimer les scnarios est grande erreur que malheureusement beaucoup de dveloppeurs commettent, alors quil nexiste aucun moyen meilleur dextraire
les informations et les dtails depuis un scnario. Dans les autres cas, le dveloppeur
peut tomber dans lerreur de faire trop dabstractions ou oublier des dtails parfois
primordiales.
3.2
3.2.1
Scnarios dutilisation
Scnario 1
Utilisation de la wiimote comme une tlcommande ou une souris : Anne

est une tudiante lENAC, elle a un abonnement ADSL avec des chaines de tlvision
gratuites quelle peut regarder sur son PC. Elle possde aussi une console de jeu Wii.
La console de jeu est livre avec une manette Wiimote, qui entre autre utilise un
protocole de communication Bluetooth. Le PC dAnne supporte la communication
Bluetooth mais elle ne connait pas beaucoup de dtails 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 spcifier des oprations de changement
de chaine ou de commande du volume. Elle veut faire a sans se plonger dans les dtails
techniques et en utilisant une interface graphique simple.
3.2.2
Scnario 2
Rgler la vitesse daffichage des messages dun sniffeur USB : Sbastien

Hamdani est un tudiant en premire anne lENAC, il fait son stage au laboratoire
dinformatique interactive. Son stage consiste produire un pilote Linux pour la table
multi-utilisateur DiamondTouch et la surface multi-tactile Stantum.
Les deux priphriques utilisent le port USB, et pour quil russisse produire un
20
pilote fonctionnel, il doit utiliser un sniffeur USB qui enregistre toute les entrs-sorties
depuis un port USB choisis au dbut de la phase. Il doit toucher chaque fois les tables
pour gnrer une communication USB vers son PC et avec une mthode dingnierie
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 sil russit interprter les donnes
correctement.
Le problme est que dans la majorite des cas, le flux de donnes changes est trs
rapide et il ne russit pas le suivre. Il aime pouvoir rgler la vitesse de dfilement, les
champs afficher et le domaine de tolrance pour la mise jour des champs. Il aime
rgler ces valeurs en utilisant un autre priphrique dentre comme une contrleur midi
et que les changements de ces options se font de faon dynamique. Ceci lui permet de
gagner plus de temps pour dcouvrir le protocole.
Exemple des informations brutes les plus lisibles provenant dune entre 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
Scnario 3
mulation de la souris pour les mouvement complexes : Olivier Saraja

est le responsable du groupe dutilisateurs du logiciel Blender Toulouse, un designer
intress par les logiciels graphiques sous Linux, et il est membre de lassociation Tou-
21
lousaine Toulibre. Il utilise Blender pour la cration danimations vidos. Il utilise

aussi dans beaucoup de cas les logiciels de dessin Inkscape et Gimp.
Dans des nombreuses fois, il voulait crer des figures artistiques avec loutil de plume
dans Gimp et les exporter Blender mais il nobtient pas des bonnes figures. Sil essaye
dutiliser les outils qui sont fournis par dfaut il perd beaucoup de temps. Gimp contient
possde un langage de script pour lautomatisation des dessins, mais il na pas le temps
dapprendre un nouveau langage et veut quil aura des outils graphiques pour spcifier
ses besoins.
Il veut utiliser loutil de dessin dans Gimp et pense que thoriquement, les figures
quil veut dessiner sont faisables sil aura la possibilit de dplacer la souris parfaitement
sur des mouvements continus de va et vient sur chaque axe.
3.3
3.3.1
Brainstorming
Dfinition
Le Brainstorming1 est une technique de rsolution crative de problmes sous la

direction dun animateur, un remue-mninges tant plus spcifiquement une runion
informelle de collecte dides. Cette technique a t conue en 1935 par Alex Osborn,
vice-prsident dune agence de publicit amricaine. Ctait lorigine une mthode
de runion de groupe soigneusement prpare puis tout aussi soigneusement exploite
pour trouver un nombre important dides publicitaires et promotionnelles pour les
clients et les clients potentiels de lagence.
3.3.2
Principe
La principale promesse de la mthode est la rcolte dides 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 rgles :
ne pas critiquer, se laisser aller freewheeling, rebondir hitchhike sur les ides exprimes et chercher obtenir le plus grand nombre dides possibles.
1
source : http ://fr.wikipedia.org/wiki/Brainstorming
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 rserve
peuvent alors tre incits sexprimer, par la dynamique de la formule et les interventions de lanimateur.
3.3.3
Mthode
Pour russir une sance de Brainstorming, lanimateur doit prparer des catalyseurs pour inciter les intervenants sexprimer. Ces scnarios peuvent parvenir des
questionnaires dj poss sur les utilisateurs. Dautres courts documents jugs intressants peuvent aussi tre apports pour tendre le domaine de suggestions.
Lanimateur doit veiller pour que les prsents ne brisent pas les rgles surtout celle
de la critique des ides poses dans la phase de la collecte. Lanimateur ou lun des
intervenants doit aussi exprimer des ides trop imaginaire pour dbrider la crativit en
exprimant toutes ses ides sans rserve et sans autocensure. Les intervenants peuvent
rebondir sur celles des autres et les amliorer car la quantit dides est importante.
Et ne jamais critiquer les ides des autres qui rsultera en un dcouragement des gens
parler.
Figure 3.2 Le rsultat dun Brainstorming
la fin de la sance on commence exploiter les ides recueillies en les reformulant, classant, hirarchisant sous une forme synthtique(rf. Figure.3.22 ) comme, par
2
source : http ://lateralaction.com/articles/brainstorming/
23
exemple, sous la prsentation dune grille de dcision. Les prsents peuvent ensuite
valoriser les meilleures ides en les affectant des pondrations.
3.4
Extraction des besoins
Aprs avoir questionn les quelques personnes et ayant effectu des sances de
brainstorming, qui taient malheureusement limits en nombre de personnes et en
temps, on peut maintenant extraire les besoins, sans quant mme oublier les tudes
bibliographiques dj cits auparavant.
3.4.1
mergence dun modle
Daprs les tudes bibliographiques, le prsent travail doit faire merger un modle
de reprsentation de priphriques qui sajoute aux modles prcdents et avec qui
prsente une abstraction se gnralisant un grand nombre de priphriques. Cette
abstraction permettra de faciliter la suite du travail.
3.4.2
Intgration au systme Linux
Tout le travail doit tre fonctionnel sur le systme Linux. Il doit utiliser les primitives
du systme existantes et permettre dajouter ses nouvelles mthodes et fonctionnalits
sans causer des problmes aux autres composants ou les dsactiver.
Le prototype ne doit pas dsactiver des parties du systme. Il doit sadditionner
comme une mthode supplmentaire facile ajouter et supprimer pour inciter les
utilisateurs de ce systme lintgrer chez eux tout en permettant toujours les autres
mthodes des fonctionnements ordinaires.
3.4.3
Interface de configuration
Le prototype faire doit permettre une configuration de la gestion de lentre. Cest

dire il doit router les entres vers des systmes de modification du flux puis gnrer
dautres entres ou des commandes directes aux applications du systme. Lutilisateur
pourra donc choisir comment grer ses entres sans lui imposer une seule configuration
24
particulire.
3.5
Conclusion
Dans ce chapitre, nous avons procd grce une mthodologie participative et

itrative dfinir les besoins du projet. Nous avons cherch au dbut des scnarios rels
dutilisation puis nous avons enrichi les scnarios par des sances de Brainstorming. Et
enfin nous avons extrait les besoins principaux du travail.
CHAPITRE
Analyse et conception
lmentaire
Dans ce chapitre, nous analysons de faon lmentaire les systmes dentre impliqus dans notre travail et nous procdons une conception pour chacun des cas aux
solutions possibles intgrer.
4.1
Analyse des systmes
Pour russir la ralisation des composants demands, et pour appliquer le modle de

travail dj expliqu. On doit analyser chaque partie du systme gnral de la gestion
dentre de Linux pour dgager toutes les solutions possibles dintgration.
4.1.1
Systme de gestion dentre de Linux
Le systme de gestion dentre dun systme Gnu-Linux se dcompose en deux

grandes parties. La premire des deux se situe dans le noyau du systme lui mme, les
dveloppeurs noyau ainsi que quelques concepteurs de dispositifs crent un pilote de leur
priphrique et lenvoient la mailing-list respective du noyau pour quil soit intgr
aux prochaines versions. Les pilotes soumis, contiennent les primitives bas niveaux
daccs au matriel et permettent de prsenter un interface des messages mis.
Ensuite, pour grer les entres depuis le noyau vers linterface graphique, cest maintenant le rle de Xorg et plus prcisment le module dentre pour faire la gestion principalement du clavier et la souris et des priphriques semblables pour les applications
graphiques lancs. Lenvironnement Xorg est cbl pour tre utilis avec seulement une
CHAPITRE 4. ANALYSE ET CONCEPTION LMENTAIRE
26
souris ayant au maximum 5 boutons, et un clavier ordinaire. Pour faire fonctionner une
souris spciale ou dautres dispositifs, il faut passer par des hack ou la soumission de
pilotes lintrieur du module dentre de Xorg.
Figure 4.1 Abstraction de la constitution du systme Linux
4.1.2
Systme HID du noyau Linux
Le port USB et les priphriques USB sont devenus ceux les plus utiliss suite
lutilisation de ce standard pour une large gamme de priphriques et les larges
possibilits fournies. Le systme HID qui est une sous partie du protocole USB, est
majoritairement utilis pour grer les priphriques dentre grce sa simplicit et sa
capacit sadapter aux options des nouveaux priphriques qui apparaissent.
En ce qui concerne le noyau de Linux, la grande partie de la gestion de son entre
est cod pour supporter le modle HID. Ce support l est en lui mme un sous-systme
complet, il est compos dun parseur qui analyse les paquets du rapport HID et instancie
le modle du priphrique. il est aussi constitu de sous modules/pilote pour lier les
entits des priphriques au messages quil doit mettre. Et sans oublier un systme
de gestion des exceptions dans le cas o certains constructeurs ne respectent pas la
spcification du modle.
4.1.3
Communication DBus
4.1.3.1
Utilit
27
Les utilisateurs de la console Linux, ont parfois besoin de passer des donnes dune
application vers une autre et pour rpondre ceci ils nont qu utiliser les tubes ou les
fichiers et crer des fichiers de script. Mais dans les systmes graphiques, faire passer
les donnes et les commandes doit se faire dune autre faon.
Le support de communication inter-application existe mme dans Xorg, mais il
est trs limit des oprations de copier-coller sans aller plus loin. Les crateurs des
environnements graphiques au dessus de Xorg tel que KDE ou Gnome ont choisi de se
baser sur leurs propres systmes de communications pour commander une application
depuis une autre ou pour transfrer quelques donnes.
4.1.3.2
Historique, Dcop, Bonobo, Corba
Au dbut, chaque environnement a cr son propre systme, sous les premires

versions de KDE le systme tait appel Dcop, et sous Gnome il tait appel Bonobo.
Chacun des systmes utilisait des notions de communications diffrentes et des modles
diffrents sinspirant parfois de Corba. Ensuite les dveloppeurs de chacun des environnements ont voulu standardiser la faon de communiquer entre les applications des
deux environnements qui taient spars et corriger les failles conceptuels des anciens
modles. Et cest pour cel quils ont lanc DBus.
4.1.3.3
Principe
DBus consiste en un serveur satellite dans Linux, dans le langage UNIX il est appele
Daemon. Le serveur permet de router les communications dune application vers une
autre. Et chaque application qui le supporte doit senregistrer ds son ouverture et
se connecter ce serveur. Elle exporte la liste de ses mthodes internes quelle veut
exporter, dans la majorit des cas effectu automatiquement, et les autres applications
auront donc un accs interne aux mthodes exportes.
4.2
28
tude des priphriques
Dans cette partie, on rsume les travaux effectus pour tudier le fonctionnement
interne de certains priphriques durant le stage. Ltude de ces priphriques, qui sont
en majorit des priphriques multi-tactiles, a pour but de comprendre le fonctionnement et pouvoir ensuite proposer un modle qui les supporte.
4.2.1
Les Phidgets
Les phidgets(rf. Figure.4.2) sont des capteurs gnriques de vitesse, dacclration,

des gyroscopes, des capteurs RFID. Ils partagent tous une connexion USB pour chacun
des capteurs. Ces priphriques, en tant que vrai exemple dunits dentre soulignent
que dans le modle proposer, quil devra traiter ces units de faon minimale et que
les autres priphriques 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. On

peut interagir sur la surface avec un ou plusieurs doigts au lieu dun seul uniquement.
Plusieurs utilisateurs peuvent aussi interagir et communiquer. Ltude de ce genre
29
dappareils permet de comprendre ce que signifie ce nouveau genre dinteraction et

comment est dj gr.
Le support des messages de lentre provenant de ce genre de priphriques ne peut
pas tre intgr dans les noyaux des systmes. Donc la gestion restera dans lespace
utilisateur, et le contrle sera fait directement ou dans les cas ncessaire envoy vers le
noyau du systme.
4.2.3
Tablette Wacom
La tablette Wacom, qui permet dmuler une souris mais tout en ajoutant dautres
caractristiques de simplicit et des critres de pression et de rotation ouvre la vue vers
la notion de lextension des modles habituels avec des composants salliant avec elle.
Ces extensions sont cacher sous un modle qui peut grouper les units dentre cits
en addition avec celles-ci.
Figure 4.3 Tablette Wacom
La figure prcdente(rf. Figure.4.3) montre comment cette tablette intgre un slider

et des boutons dans chaque partie de lcran tactile. Qui peuvent tre vue comme les
composants dune mme souris mais rpts avec un identifiant pour chacun et suivant
une hirarchie dattachement.
4.2.4
30
Table DiamondTouch
La table MERL DiamondTouch est une table permettant de diffrencier jusqu

quatre utilisateurs interagissant en parallle. La notion de multi-utilisateur est presque
inconnue dans les autres priphriques. La table utilise un mcanisme transformant
chacun des utilisateurs en une antenne en les liants un type de signal mis. Le
modle, pourra donc accepter dinstancier plusieurs fois un mme type de dispositifs.
4.2.5
Tablette Stantum
La tablette Stantum est un cran TFT combin une technologie qui permet de
reporter les vnements multi-tactiles qui figurent la surface. La tablette nest pas
encore un produit finalis et lun des objectifs de notre travail au laboratoire est de crer
un pilote pour la rendre fonctionnel sous Linux. tant un priphrique USB HID, le
pilote cr suivra le modle dfini. La notion des priphriques multi-tactiles nexistait
pas avant sous Linux. Et cest pour ceci que beaucoup de temps a t consacr aux
discussions sur les types de messages intgrer dans le noyau et la faon avec laquelle
le noyau doit grer le multitouch.
4.3
4.3.1
Conception lmentaire et Solutions

Intgration du configurateur au noyau Linux
Lune des solutions pour la cration dun configurateur dentre pour Linux est de
lintgrer directement dans le noyau. Ainsi, la notion des priphriques virtuelles et
des units dentre devra aussi tre propose pour lintgration. Le rsultat dune
telle solution est un fichier de patch de trs grande taille, et une modification intense
lintrieur du noyau.
Si on sache que les dveloppeurs du noyau doivent tre convaincus pour les plus
petits changements, alors on peut directement savoir quune telle solution est impossible
tre accepte. La gestion interne dans le noyau ne supporte que les options daccs bas
niveau et de gnration de messages systmes. Tout autre systme dit rvolutionnaire
doit tre une option part et sera automatiquement refus daprs la Documentation
officielle du noyau.
4.3.2
31
Cration dun daemon spar
Un daemon est un processus spar du noyau, qui sexcute en arrire plan. Il peut
communiquer entre les deux mondes du systme dexploitation qui sont le user-space
et le kernel-space. Raliser le configurateur dentre en tant que daemon permet une
intgration beaucoup plus facile puisque on ne modifie pas le code du noyau et le
serveur reste accessible depuis lespace utilisateur pour les applications. Lutilisation
du daemon est donc la solution garder pour raliser le configurateur dentre.
4.3.3
Intgration la chaine traditionnelle dentre
On signifie par la chaine traditionnelle dentre la chaine commenant par le noyau

lui mme en passant par le serveur Xorg et allant vers les applications. Si on applique
les principes du configurateur proposer des units dentre composer pour crer
des priphriques virtuels, on sera amen gnrer chaque fois des pilotes noyau,
puis de crer des pilotes Xorg. Puisque ce dernier est dj compos de module dont
celui du la gestion dentre XInput, et qui est lui aussi compos de pilotes pour chaque
priphrique.
En rsum, on sera amen gnrer une quantit trs grande de code, sans aucune
garantie de stabilit de fonctionnement et defficacit.
4.3.4
Accs DBus aux applications
Les applications Linux sont compiles en donnant la possibilit aux autres appeler
leurs mthodes internes. Cet avantage nest possible quavec DBus, qui est un protocole
de communication inter-applications. Le support de DBus intgr dans les nouvelles
bibliothques tel que Qt et GTK, permet dautomatiser la procdure dexportation des
mthodes laide des macros. Cest un trs grand avantage puisque le configurateur
aura la possibilit de communiquer directement aux applications sans entrer dans les
limitations et la complexit du serveur Xorg.
4.3.5
32
Principe dinjection des vnements
Linjection des vnements consiste muler la gnration physique des messages

dinput depuis les priphriques. Le systme qui gnre les vnements est situ dans
lespace utilisateur, il communique avec le noyau Linux travers un module spcifique
appel uinput et lui envoi la structure de donne contenant les dtails du message.
Le message qui nest autre quune structure en C contient le type du message, le
code du message et la valeur. Et une fois les vnements injects, il suivent la chaine
traditionnelle dentre comme sils parviennent dun priphrique physique. Linjection
des vnements dans le noyau permet dviter lcriture de pilotes noyau et dautres
Xorg pour chaque priphrique virtuel cr. On aura aussi la libert de gnrer nimporte quel vnements supports de lensemble des autres priphriques.
4.3.6
Validation des choix
Daprs les tudes prcdentes, on remarque quon est oblig de crer un daemon
spar pour la gestion avance de lentre et de la configuration. Pour encourager les
crateurs de distributions Linux dintgrer notre code. On limine aussi le choix de
passer par les chemins que prend lentre en ralit en passant par le noyau puis par
Xorg, puisque on sera oblig de crer un pilote pour chaque configuration imagine.
On opte donc dans ce cas linjection des vnements en tant que priphriques
standards. Et en dernier lieu, linvocation de messages DBus fournit un trs large
contrle sur le domaine des applications et on surpasse le serveur Xorg ce qui signifie
quon limine ses limites.
4.4
Conclusion
Dans ce chapitre, nous avons analys les domaines dapplications de notre travail.
Nous avons examin dabord les systmes sur lesquelles ont va interagir puis les priphriques que nous devons supporter. Nous avons ensuite procd faire des propositions
de conceptions et valid ceux qui sont applicables.
CHAPITRE
Modlisation et
Prototypage
Dans ce chapitre, nous exposons les premiers fruits de notre tude qui commencent
par la modlisation de lentre puis nous prsentant les prototypes dimplmentation
raliss.
5.1
Modlisation
Daprs ltat de lart des papiers scientifiques, les scnarios et les besoins extraits,
lanalyse et conception lmentaire et toutes les tudes prcdentes, nous proposons ici
notre modle de reprsentation, de gestion et de configuration de dispositifs dentre.
5.1.1
Units minimales dentre
La chose commune entre les dispositifs dentre si on raisonne du cot des transferts
bas niveau, est lexistance de petites entits transfres. Ces lments ou units minimales dentre ont des structures trs simples, et sont associs, surtout dans un modle
comme celui du HID, des proprits et des caractristiques additionnelles dfinissant
lordre de grandeur, lunit et lutilisation.
Figure 5.1 Units dentre minimales
CHAPITRE 5. MODLISATION ET PROTOTYPAGE
34
Nous adhrons ce modle l, et on propose une amlioration dans les proprits

des items. On propose daugmenter lespace des proprits et inclure ces dernires
directement dans llment reprsentatif lui mme. Les transferts utilisaient le modle
standard conu, mais la reprsentation dans la mmoire dun priphrique sera alors
une hirarchie entre ces units dentre, ayant les caractristiques dans les units eux
mmes, et non dans les racines de larbre.
Ceci liminera une gestion de flux et un traitement face des ajouts mmoire. Mais
le plus important est que le modle restera simple grer et unique pour une grande
partie des dispositifs.
5.1.2
Reprsentation dun priphrique
Un priphrique est donc daprs ceci une hirarchie entre plusieurs units dentre
gres de la mme faon et quon peut aprs ajouter des traitements qui seront applicables sur un dispositif A comme un autre B, mme sils sont physiquement diffrents.
Figure 5.2 Reprsentation dun priphrique
Le modle HID ainsi que dautres papiers scientifiques ont trait en partie une
reprsentation similaire, mais aucun deux na facilit lexportation des units dentre
vers lespace utilisateur de faon simplifie et combine la notion de configuration.
5.1.3
Projection de la configuration
Lun des limites du modle HID est la non possibilit de modifier les proprits des
items dynamiquement et avec le contrle de lutilisateur final. Ils sont embarques dans
35
le dispositif lui mme et traites par le parseur du systme dexploitation pendant la

phase de reconnaissance.
Faire approcher la configuration lutilisateur finale lui permet une plus grande
libert dutiliser son priphrique dans dautres contextes et mme de le voir autrement.
Figure 5.3 Principe dinclusion de la configuration dans le modle
Dans lexemple qui prcde(rf. Figure.5.3), une proprit de configuration consiste

changer lintervalle initial et de lexporter vers un autre domaine. On montre dans ce
cas comment il est simple dinclure lintervalle de sortie dans les proprits de lunit de
lentre elle mme et de faire lexportation suite une opration mathmatique simple.
5.2
5.2.1
Prototypage des modles

Communications DBus
DBus est un outil permettant de faciliter la communication entre les applications

dans les systmes Linux. Mais il na pas t imagin ou utilis en tant quun outil de
commande aprs traitement de lentre utilisateur.
En effet, le fait que les applications sous Linux sont conues de faon exporter
leurs mthodes internes et de les exposer aux autres applications travers DBus, nous
inspire une vue particulire envers lespace des applications. On peut voir cette espace
comme tant unifi sans les bords habituels puisquon a garanti un accs horizontal.
Ce qui reste est de proposer un systme situ entre le noyau Linux et ces applications
pour faire la gestion ce qui se rsume notre configurateur.
Comme montre la figure(rf. Figure.5.4), on instancie une nouvelle gestion de lentre avec laquelle on limine lancien contrle des systmes comme Xorg. Cette limi-
36
Figure 5.4 Architecture de la communication DBus utilise
nation est trs avantagieuse puisque on sera libre et on sort des limites du protocole
X11 de Xorg cr dans les annes 80, et ncssitant maintenant des astuces de programmation pour supporter les nouvelles options de ces dernires annes.
La communication DBus a t utilis dans la production du premier prototype
montrant la possibilit pour un systme Linux de grer une entre multi-tactile. Le
systme Xorg est totalement ignor puisque les communications passerait travers
DBus. Lexemple a montr la grande libert acquise et des options non possible mme
dans les autres systmes.
Dans les autres systmes, pour quils supportent la gestion multi-tactile, ils ont eu
seulement deux possibilits, soit rcrire les applications, soit utiliser cette gestion dans
un environnement ferm (comme dans le cas de la Microsoft-Surface). Alors quici,
nous avons le contrle des applications habituels pour supporter le multi-tactiles et
dautres futures technologies sans tre oblig les rcrire. On utilise seulement la
configuration travers un daemon de gestion de lentre.
5.2.2
Injection de lentre
La communication DBus, peut dans certains cas tre limite. Cette limitation provient du fait que les concepteurs des applications nont pas export toutes les mthodes,
ou laccs aux possibilits reste limit.
Le principe de linjection de lentre consiste lire les messages mis par un autre
37
priphrique puis de communiquer avec le noyau et de lui demander de gnrer des

messages, comme sils taient mis par des dispositifs rels. Les messages dentre qui ne
proviennent plus de sources physiques, suit le parcours de la gestion dentre standard
sans que lapplication o on veut lutiliser se rend compte. Linjection ncessite muler
la structures des messages originaux de lentre. Cest dire envoyer des structures de
donnes contenant la valeur de lentre, le type et le code.
Figure 5.5 Architecture de linjection de lentre
Dans lexemple de prototype que nous fait, le configurateur cherche modifier

lentre dune souris avec linjection de messages. Ces messages sont crs selon les paramtres dun autre dispositif utilis pour grer dynamiquement les options dinjection
comme la vitesse et la valeur.
5.3
Conclusion
Dans ce chapitre, nous avons expos notre modlisation de la gestion et la configuration de lentre. Nous avons aussi expliqu deux prototypes appliquant notre notion.
CHAPITRE
Mise en oeuvre et
ralisation
Dans ce chapitre, on prsente lenvironnement avec lequel on a travaill, les rsultats

obtenus et les difficultes rencontrs.
6.1
6.1.1
Environnements Logiciel
Systmes dexploitation
Durant les six mois de travail, on a utilis principalement des systmes dexploitation
Linux 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 cest
cette dernire qui contient les modifications effectues pour supporter la reconnaissance
et la gnration des vnements multi-contacts. Ce mme noyau puis celui qui suit le
2.6.31 contiennent des pilotes pour des priphriques multi-tactiles de la Stantum, la
DiamondTouch ainsi que le HP NTrig, tous dvelopps en totalit ou en partie dans
notre laboratoire.
6.1.2
Le reste de lenvironnement
On a aussi utilis le gestionnaire de fentres de KDE 4, appel KWin ainsi que

le gestionnaire Compiz pour aboutir aux vidos de dmonstrations lances sur le site
Youtube. Et pour la cration des vidos on a utilis Kdenlive.
Linterface graphique a t cod en C++ et la bibliothque Qt a t choisi pour
CHAPITRE 6. MISE EN OEUVRE ET RALISATION
39
les primitives de dessin. Dautres outils graphiques ont t aussi utiliss comme loutil
Inkscape et Gimp pour la gnration des objets graphiques dans linterface de configuration.
6.2
6.2.1
Environnements Matriel
Machines utiliss
Les machines utilises pour aboutir ce travail sont :

PC de Bureau Cest un ordinateur sous le systme ubuntu 9.04, appartenant au
laboratoire dinformatique interactive, il a t utilis pour le raccodrement des
nombreux priphriques dentre tests. Il a t aussi utilis pour le test et le
codage de quelques dmonstrations.
Laptop LG Cest un ordinateur portable avec le systme openSUSE 11.1 (KDE 4.2.4)
surlequel la majorit du travail ft ralise surtout pendant la dernire phase du
travail. Les dmonstrations qui ont rsult en des squences vidos ont t cod
sur cet ordinateur.
Mac Mini Avec le systme MacOS X Tiger 10.4 install, cet ordinateur a permis de
tester quelques applications du monde Mac, conus pour la programmation visuelle
en utilisant des boites avec des entres/sorties connectables.
6.2.2
Priphriques
Nous avons utilis beaucoup de priphriques surtout dans la phase du prototypage.

Parmi ces priphriques nous citons :
MERL Diamond Touch utilis pour vrifier 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 dentre gnrique. Utiliss pour faire des tests sur leurs protocoles.
Contrlleur Korg priphrique(rf. Figure.6.1) utilis habituellement pour les logiciels de musique. Nous lavons utilis pour configurer et contrler linjection de
lentre dun autre dispositif comme la souris.
40
Figure 6.1 Le contrlleur Nanokontrol
6.3
6.3.1
Ralisation
Corps du configurateur
Le corps du configurateur nest que lassociation du code des prototypes dj crs

puis traits de faon les faire fonctionner de faon dynamique et sous forme dun
serveur Linux ou daemon.
Figure 6.2 Architecture du configurateur
Le configurateur principale ne ncessite pas une interface graphique pour fonctionner, il utilise seulement un minimum pour rester rapide et ractif. Mais le dveloppement dun interface a t lanc pour faciliter son utilisation depuis les utilisateurs
simples.
6.3.2
Interface graphique de configuration
Linterface graphique de configuration est la liaison avec laquelle un utilisateur

non expriment accde la configuration. Dans cet interface lutilisateur manipule
des objects graphiques qui sont ensuite traduits vers des commandes textuelles de
configuration.
41
Figure 6.3 Interface de gnration des paramtres pour le configurateur
Linterface nest pas totalement complet, et exige encore plus de travail pour arriver
ltat dtre valid par les autres dveloppeurs des composants Linux.
6.4
Problmes rencontrs
Comme dans tout projet, il a eu des moments difficiles durant plusieurs phases
davancement. Je tiens ici signaler les majeurs problmes rencontrs :
Rattraper les connaissances acquises face la vitesse avec laquelle volue le systme Linux,
Le manque cruel de la documentation dans plusieurs parties du systme Linux
ainsi que pour beaucoup de bibliothques utilises,
La suivie dun processus de dveloppement non habituel et lintgration dans la
communaut des dveloppeurs existantes,
Les pics dans la charge de travail raliser pendant une priode trs rduite de
temps,
La suivie des retours du travail aprs son lancement et maintenir le rythme de
dveloppement.
6.5
Chronogramme
Voici le chronogramme reprsentatif de la totalit du travail ralis :
42
Figure 6.4 Chronogramme du projet
6.6
Conclusion
Dans ce chapitre, nous avons montr lenvironnement de travail que nous avons
vcu que ce soit cot matriel ou logiciels. Nous avons aussi prsent ltat des travaux
raliss et les problmes rencontrs tout au long des six mois de travail.
Conclusion et
Perspectives
U cours de mon stage de fin dtudes, et en plus de la dcouverte dun nouveau

pays et une nouvelle culture, javais aussi la mission de comprendre le processus
de recherche et une mthodologie de travail dont je ntais pas habitu. Javais beaucoup
de choses shabituer avec. Et javais une mission russir pour laisser une bonne image
et une bonne impression.
La mission la plus difficile tait de sintgrer avec les mthodologies de recherche et
analyser les significations et les buts des papiers scientifiques et les points pas encore
explors ou dpasss pour les ajouter ou les amliorer. Cest pour ceci quune trs
grande partie de mon travail consistait analyser les modles et proposer un nouveau
plus gnral et plus applicable.
Le processus sest bas sur les directives de mon encadreur et sa patiente pour
menseigner les bonnes manires de se lancer dans des grands projets et dextraction des
besoins. Le fait de se baser sur des scnarios rels et de les collecter depuis une gamme
large de personnes de diffrents niveaux permet dlargir lespace des connaissances et
dimagination. Les sances de Brainstorming taient aussi un grand facteur de russite
pour la collecte des ides.
Les apports du stage sont alors assez nombreux, on cite alors la proposition du
modle de gestion des priphriques et limagination de nouveaux systmes qui remplacent ceux qui existent dj. Les apports personnels du stage en ce qui concerne les
connaissances du systme dexploitation Linux et la procdure de son dveloppement
sont aussi abondants puisque on sest impliqu dans les basses couches du systme.
Et en ce qui concerne les rsultats de nos travaux, ils seront considrs commes des
prototypes fonctionnant comme des preuves de concept de la possibilit de la rimagination des systmes pour les amliorer et dcouvrir les facettes cachs que personnes
autres na essay ou a eu le courage de les dvoiler.
Bibliographie
[AGA06] Pau Arum, David Garca, 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 123, New York, NY,
USA, 2006. ACM.
[Bux]
William Buxton. More to interaction than meets the eye : Some issues in
manual input. http ://www.billbuxton.com/eye.html.
[Bux83]
William Buxton. Lexical and pragmatic considerations of input structures.

SIGGRAPH Comput. Graph., 17(1) :3137, 1983.
[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 449456, Amsterdam, The Netherlands, The Netherlands, 1990. North-Holland Publishing Co.
[Cha94]
Stphane 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 195204, New York, NY, USA, 1994.
ACM.
[CLV07] Stphane Chatty, Alexandre Lemort, and Stphane Vals. Multiple input
support in a model-based interaction framework. In 2nd Annual IEEE International Workshop on Horizontal Interactive Human-Computer Systems,
pages 179186, Newport, Rhode Island, USA, October 2007. 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
BIBLIOGRAPHIE
45
on Human factors in computing systems, pages 117124, New York, NY,

USA, 1990. 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) :99122, April 1991.
[DF04]
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 212219, New York, NY, USA, 2004. ACM.
[Dra04]
Pierre Dragicevic. Un modle dinteraction en entre pour des systmes interactifs multi-dispositifs hautement configurables. PhD thesis, cole Nationale
Suprieure des Techniques Industrielles et des Mines de Nantes, March 2004.
[FSB05]
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 13751378, New York, NY, USA, 2005.
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, 2006.
[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) :326, 1994.
[Shn97]
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 3339, New York, NY, USA,
1997. ACM.
[SVC04] Cline Schlienger, Stphane Vals, and Stphane Chatty. Une exprience de
conception et de prototypage dinterfaces volues en milieu industriel. In
IHM 2004 : Proceedings of the 16th conference on Association Francophone
dInteraction Homme-Machine, pages 165172, New York, NY, USA, 2004.
ACM.
[USB01] USB Implementers Forum. Device Class Definition for Human Interface
Device 1.11, June 2001.
BIBLIOGRAPHIE
[USB04] USB Implementers Forum. HID Usage Tables, October 2004.

[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 8592, New York, NY, USA, 2003. ACM Press.
Acronymes et dfinitions
Acclromtre capteur dacclration

Contrlleur midi Priphrique contenant une multitude de rgulateurs pour la gestion de la musique
DAEMON Disk And Execution MONitor, processus serveur dans Linux sexcutant
en arrire-plan
DBus Data Bus
Gyroscope capteur dangle dinclinaison
HID Humain Interface Device
IHM Interaction Humain-Machine
RFID Radio-Frequency identifier, priphrique permettant didentifier 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 possdant des manettes riches en capteurs
WIMP Windows, Icons, Menus, Pointer
Xorg Le serveur daffichage des UNIX
ANNEXE
Diffusion des rsultats

des travaux
Puisque notre projet se repose sur des technologies libres, et sintgre au systme
Linux, nous avons eu un parcours un peu spcifique lors de nos travaux. Nous avons
contact beaucoup de gens chacun travaillant sur une partie du systme totale. Et la
fin nous avons t cit dans plusieurs sites dactualits.
A.1
Travail avec la communaut de Linux
Pour pouvoir proposer des modifications dans le noyau Linux, la procdure consiste
bien tudier le systme puis denvoyer les changements sous forme dun patch. Un
patch est tout simplement la diffrence entre le systme initiale et le systme aprs les
modifications dveloppes.
La liste de diffusion principale de Linux est trs active(ref. Figure.A.1), de lordre
de 500 mails par jour. Et cest pour ceci que dautres listes existent, chacune delles se
spcifie une partie du systme
Figure A.1 La liste de diffusion de Linux
ANNEXE A. DIFFUSION DES RSULTATS DES TRAVAUX
A.2
iv
Gnration des vidos de dmonstration
Pour garantir une bonne information de nos travaux. Nous avons fait des vidos
de dmonstration des possibilits 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 vidos montrant pour la premire fois la possibilit de commander un
bureau ordinaire avec des commandes multi-tactiles. La vido dont vous voyez les
captures(ref. Figure.A.2) est lune entre plusieurs diffuses, mais elle est celle qui a pris
le plus de succs.
Figure A.2 Capture de la vido diffuse
A.3
Les retours reus
La vido a eu du succs et elle tait vue par plus de 78000 personnes jusqu maintenant(ref. Figure.A.3). Mais nous avons eu aussi des retours depuis des personnes
voulant tester ces nouvelles possibilits sur leurs systmes. Les retours les plus importants proviennent de quelques socits qui fabriquent des crans multi-tactiles et qui
voulaient cooprer et garantir le support de leurs plateformes sous Linux.
Figure A.3 Le nombre lev de visualisations
ANNEXE A. DIFFUSION DES RSULTATS DES TRAVAUX
A.4
Design du site du laboratoire
Avant davoir diffus les rsultats des travaux, il faut dabord prparer 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 dfini. Donc nous avons dit les pages et fait les mises jour pour arriver un
rsultat acceptable et qui attire le visiteur et le motive revenir encore une fois.
Figure A.4 Le nouveau site du laboratoire
ANNEXE
B.1
Systme DBus
Prsentation de D-Bus
D-Bus est un systme de communication interprocessus (IPC). Architecturalement,

il dispose de plusieurs niveaux :
Une bibliothque, libdbus, qui permet deux applications de se connecter les uns
aux autres et changer des messages.
Un daemon bus de messages excutable, construit sur libdbus, vers lequel plusieurs applications peuvent se connecter. Le dmon peut router les messages dune
application une ou plusieurs autres applications.
Des bibliothques de liaison qui sappuyent sur des frameworks applicatives particulires. Par exemple, libdbus-glib et libdbus-qt. Il existe galement des liaisons
des langages tels que Python. Ces bibliothques de liaison sont les API que
les personnes devraient utiliser car ils simplifient les dtails de la programmation
D-Bus. La libdbus est destin tre une bibliothque bas niveau pour les liaisons
de niveau suprieur. Une grande partie de lAPI libdbus nest utile que pour cette
liaison.
libdbus ne supporte que des connections un--un, tout comme une prise rseau
brute. Toutefois, plutt que denvoyer les flux doctets sur la connexion, vous envoyez
des messages. Les messages ont un en-tte indiquant le type de message, et un corps
contenant une charge utile de donnes.
Le dmon bus de messages est le noyau dune roue. Chaque rayon de la roue est
une connexion un--un une application utilisant libdbus. Une application envoie un
message au dmon de bus sur sa parole, et le dmon de bus transfre le message vers
dautres applications lies au besoin. Pensez le dmon comme un routeur.
ANNEXE B. SYSTME DBUS
vii
Le dmon du bus a plusieurs instances sur un ordinateur ordinaire. Une instance a

des restrictions de scurit lourde sur les messages quelle accepte, et est utilis pour
la communication lensemble du systme. Les autres instances sont cres par session
utilisateur une connexion. Ces exemples permettent aux applications en session de
lutilisateur de communiquer avec lun lautre.
Les dmons utilisateur et systmes sont spares. Les messages mis seulement dans
linstance session ou systme nimpliquent pas lautre instance.
B.2
Applications D-Bus
Il y a beaucoup de technologies dans le monde pour grer la communication

inter-processus ou en rseau comme : CORBA, DCE, DCOM, DCOP, XML-RPC,
SOAP, MBUS, Internet Communications Engine (ICE), et probablement des centaines
dautres. Chacune delles est adapte des types particuliers dapplication. D-Bus est
conu pour deux cas particuliers :
1. Communication entre les applications de bureau dans la mme session bureau,
pour permettre lintgration de la session du bureau dans son ensemble, et adresse
les problmes du cycle de vie des processus (quand dmarrer et darrter les composants de bureau).
2. La communication entre la session du bureau et le systme dexploitation, o le
systme dexploitation inclue en gnral les dmons du noyau et tout systme ou
processus.
Pour lutilisation dans le bureau, GNOME et KDE ont lexprience antrieure significative avec des solutions diffrentes IPC tels que CORBA et DCOP. D-Bus est
construit sur cette exprience et soigneusement conue pour rpondre aux besoins de
ces projets de bureau en particulier.
D-Bus peut tre utiles dautres fins que celle quelle a t conue. Ses proprits
gnrales qui le distinguent des autres formes de IPC sont les suivantes :
Protocole binaire conu pour tre utilis de faon asynchrone (mme esprit que
le protocole X Window System).
Les connexions sont fiables et maintenues ouvertes au cours du temps.
Le bus de messages est un dmon, et non pas une architecture distribue.
viii
Beaucoup de mise en oeuvre et de dploiement sont prcises plutt que laiss

ambigu / configurable.
Smantique est similaire au systme existant DCOP, permettant KDE de ladopter plus facilement.
B.3
Concepts
Quelques concepts de base sappliquent peu importe dans quel cadre dapplication
que vous utilisez pour crire une application D-Bus. Le code exact que vous crivez
sera diffrent pour les applications Qt, Glib ou Python.
Figure B.1 Schma prsentant les Concepts de DBus
Les Objets et les chemins

Le protocole bas-niveau de DBus ne permet pas de crer des objets mais il prsente
la notion du chemin dobjet. Le chemin dobjet ressemble un chemin sur le systme,
ix
par exemple un objet pourrait tre nomm /org/kde/kspread/sheets/3/cells/4/5. Les

chemins avec des noms simples et lisibles sont meilleurs, mais vous tes libre de crer
un objet nomm /com/mycompany/c5yo817y0c1y1c5b si elle a un sens pour votre
application.
Les mthodes et les signaux

Chaque objet a des membres, les deux types de membres identifis par leurs noms
qui sont :
Les mthodes : sont des oprations qui peuvent tre invoques sur un objet, avec
des ventuels arguments en entre et des valeurs de retour en sortie.
Les signaux : sont les missions en provenance de lobjet tous les observateurs
intresss de lobjet, les signaux peuvent contenir une charge utile de donnes.
Les proxies
Les proxies sont des objets natifs crs pour reprsenter un objet distant dans un
autre processus. Il sont utiliss pour simplifier le code permettant dappeler lancien
objet. Le code aura donc des chemins courts et la complexit sera cach dans le coeur
du proxy.
Les noms de bus

Lorsquune application se connecte au dmon de bus, le dmon attribue immdiatement un nom, appel le nom de connexion unique. Un nom unique commence par
le caractre deux points :. Ces noms ne sont jamais rutiliss pendant la dure de
vie du dmon de bus, le nom donn fera toujours rfrence la mme application. Un
exemple dun nom unique peut tre :34-907. Les chiffres aprs les deux points nont
pas de sens autre que leur unicit.

Rapport Pfe (Configurateur D'entrée Pour Linux)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Pfe (Configurateur D'entrée Pour Linux)

Transféré par

Droits d'auteur :

Formats disponibles

Soutenu la session de Septembre 2009

Ecole Nationale des Sciences de LInformatique

MEMOIRE DE FIN DETUDES

Prsent en vue de lobtention du titre

Configurateur dentre pour Linux

Organisme daccueil : Laboratoire dInformatique Interactive

Responsable : Pr. Stphane CHATTY

ris. Les tudes concernant ladaptabilit et la configuration de lentre restent encore

Signatures des encadrants

Prof. Nejib BEN HADJ ALOUANE

Prof. Stphane CHATTY

particulirement, je tiens remercier travers ces courtes lignes :

Kevin Ottens (KDE),

Table des matires

Prsentation de lorganisme daccueil . . . . . . . . . . . . . . . . . . .

Lcole Nationale de lAviation Civile . . . . . . . . . . . . . . .

Le Laboratoire dInformatique Interactive . . . . . . . . . . . .

IntuiLab et son secteur dactivit . . . . . . . . . . . . . . . . .

Cadre du travail : Projet ShareIT . . . . . . . . . . . . . . . . .

Prsentation du travail demand . . . . . . . . . . . . . . . . . . . . . .

Processus de dveloppement adopt . . . . . . . . . . . . . . . . . . . .

2 tude pralable et tat de lart

Diversits des dispositifs et des paradigmes dinteraction . . . .

Ncessit dun modle . . . . . . . . . . . . . . . . . . . . . . .

Modles et tudes Scientifiques . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES

tude des performances et exprimentation . . . . . . . . . . .

Taxinomie des dispositifs . . . . . . . . . . . . . . . . . . . . . .

Lutilisation de plusieurs dispositifs . . . . . . . . . . . . . . . .

Les systmes multi-tactiles . . . . . . . . . . . . . . . . . . . . .

Extraction des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . .

mergence dun modle . . . . . . . . . . . . . . . . . . . . . .

Intgration au systme Linux . . . . . . . . . . . . . . . . . . .

4 Analyse et conception lmentaire

TABLE DES MATIRES

Analyse des systmes . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Systme de gestion dentre de Linux . . . . . . . . . . . . . . .

Systme HID du noyau Linux . . . . . . . . . . . . . . . . . . .

Historique, Dcop, Bonobo, Corba . . . . . . . . . . . .

tude des priphriques . . . . . . . . . . . . . . . . . . . . . . . . . .

Conception lmentaire et Solutions . . . . . . . . . . . . . . . . . . . .

Intgration du configurateur au noyau Linux . . . . . . . . . . .

Cration dun daemon spar . . . . . . . . . . . . . . . . . . .

Intgration la chaine traditionnelle dentre

Accs DBus aux applications . . . . . . . . . . . . . . . . . . . .

Principe dinjection des vnements . . . . . . . . . . . . . . . .

Validation des choix . . . . . . . . . . . . . . . . . . . . . . . .

Units minimales dentre . . . . . . . . . . . . . . . . . . . . .

Reprsentation dun priphrique . . . . . . . . . . . . . . . . .

Prototypage des modles . . . . . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES

6 Mise en oeuvre et ralisation

Interface graphique de configuration . . . . . . . . . . . . . . . .

A.1 Travail avec la communaut de Linux . . . . . . . . . . . . . . . . . . .

A.2 Gnration des vidos de dmonstration . . . . . . . . . . . . . . . . .

A.3 Les retours reus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.4 Design du site du laboratoire . . . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES

B.1 Prsentation de D-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

Liste des figures

Mthodologie de travail IntuiSignTM . . . . . . . . . . . . . . . . . . . .