L'utilisation de surfaces multitouch comme dispositifs d'entrée change beaucoup l'interaction entre homme et ordinateur.

Nous verrons dans cet article les différentes solutions pour implémenter des applications destinées à marcher sur une surface multitouch, les avantages et faiblesses de chacune, et leur fonctionnement.

Driver et parallèle avec cartes son.

Le rôle du driver est de transformer les signaux reçus par le dispositif d'entrée (matériel) en données informatiquement compréhensibles. De plus, comme une surface multitouch est un dispositif d'entrée, il n'est pas idéal de faire du polling sur celui-ci pour obtenir son état, puis l'interpréter. Il est bien plus judicieux de recevoir une séquence d'évènements (events) symbolisant les entrées et changements d'état du dispositif.

Si l'on désire utiliser les surfaces multitouch hors expérimentations, et à une échelle plus grande que l'actuelle, il est capital d'arriver à créer une API unique permettant d'accéder au hardware, indépendamment du hardware en question. En effet, l'erreur à éviter est de créer pour chaque application une interface pour chacune des surfaces multitouch existantes.

Cette erreur avait été faite à l'époque de DOS avec les cartes son: pour avoir du son, il n'existait pas d'interface unique pour accéder au hardware, et il fallait traiter séparément chacune des cartes son disponibles sur le marché. L'approche était valide tant que ce marché était réduit aux cinq cartes son de Creative (Sound Blaster 16/32/etc), mais est totalement impossible à gérer 2 ans plus tard, ce qui a conduit à la création de OSS sous tous les systèmes UNIX, puis ALSA sous GNU/Linux pour remplacer OSS, et DirectSound sous Windows (aujourd'hui DirectX Audio).

Il est donc essentiel de définir une API unifiée pour accéder au hardware, ainsi qu'un protocole pour recevoir des événements d'une surface Multitouch depuis n'importe quelle application, en suivant le modèle de ALSA/DirectX Audio: une couche contenant le driver proprement dit, pour chacune des surfaces multitouch existantes, et une autre pour proposer une API unifiée aux applications.

On peut noter que faire un driver est beaucoup moins simple qu'il n'y parait dans le cas des dispositifs multitouch, car les fonctionnalités d'une surface Multitouch à l'autre varient énormément.

Ceci dépend beaucoup du matériel (optique, par conductivité, autres...) et des capacités de celui-ci (peut-on connaître la position entière de la main, juste la position de chacun des blobs, quel est le nombre maximum de blobs à un instant donné, sait-on faire la différence entre un stylet et un doigt ? Peut-on détecter une main qui ne touche pas la table ? Et les angles en ses doigts ? Etc...).

L'idéal aurait été de fixer un standard permettant de gérer un maximum de capacités du point de vue des surfaces Multitouch, quitte à ne s'en servir qu'en partie dans un premier temps, mais permettant ainsi d'aller plus facilement plus loin au fur et à mesure que le hardware évolue. On évite ainsi de devoir, au choix, perdre la rétrocompatibilité de toutes les anciennes applications, ou bien devoir rajouter et maintenir un support aux anciennes versions du standard au fur et à mesure des évolutions de ce dernier (comme ça a été le cas lors du remplacement de OSS par ALSA, avec la création du plug-in ALSA “alsa-oss” qui fournit la rétrocompatibilité).

Aujourd'hui, différents standards sont disponibles pour utiliser les surfaces multitouch:

• TUIO 1.0 et 1.1 (trop limité, mais le plus utilisé de tous)
• Windows Seven
• Autres (standards propriétaires)

On remarquera enfin que pour les dispositifs optiques, c'est la responsabilité du driver que de traiter et comprendre l'image de la caméra pour en sortir des informations valides. On se retrouve donc avec des drivers qui peuvent se révéler particulièrement lourds à l'exécution, et qui dépendent eux-mêmes d'autres drivers également lourds (driver USB, driver de Webcam...).

Quel doit être le rôle de la table Multitouch?

Deux approches possibles

On a deux approches possibles : rajouter uniquement un dispositif d'entrée qui est un touchpad/écran tactile multitouch, et limiter son utilisation aux applications compatibles, ou bien considérer que l'écran tactile doit remplacer les dispositifs d'entrée traditionnels (clavier, souris).

Avec la deuxième solution on perd toute notion de fenêtre/textbox/bouton actif, car ces concepts sont très liés aux dispositifs d'entrée/sortie traditionnels : le principe du multitouch implique qu'on puisse par exemple, déplacer deux fenêtres simultanément, laquelle des deux est active ?

Le meilleur compromis actuel, car on ne peut raisonnablement pas reprendre de zéro tout ce qui tourne autour des interfaces graphiques que nous utilisons, est de considérer l'écran tactile comme un périphérique d'entrée parmi d'autres. Les applications compatibles peuvent alors s'en servir, et les applications qui ne le sont pas continuent à utiliser les dispositifs d'entrée/sortie traditionnels.

Legacy

Si l'on désire se débarrasser de la souris et du clavier pour réaliser une interface uniquement basée sur une dalle tactile, on doit alors émuler souris et clavier à partir de la surface (de même que OSS est émulé avec ALSA, pour reprendre l'exemple de l'introduction).

Autant émuler un clavier semble évident, car le principe du “clavier virtuel” n'a rien de nouveau.

Émuler une souris est par contre beaucoup plus problématique. Les restrictions que cela apporte sont très lourdes.

• La précision d'un doigt sur la surface est insuffisante pour émuler un pointeur de souris (précis au pixel près).
• On ne peut décider quel comportement adapter quand plusieurs objets/doigts/stylets touchent la surface simultanément.
• Comment émule-t'on un clic, clic droit, roulette de souris, et ainsi de suite ?

La moins pire solution consiste à disposer d'une table capable de reconnaître un stylet particulier (de le différencier des autres blobs présents), et les différents boutons de la souris peuvent être simulés par des gestes avec l'autre main.

On y perd cependant en précision, et cela demande une surface possédant des capacités avancées par rapport à ce qui est généralement disponible.

Enfin, si l'on se base sur des gestes, l'utilisation de la table demandera un apprentissage, ce qui est contraire à l'idée de base (réaliser des interfaces très ergonomiques).

Dans quel domaine utiliser le multitouch?

• Conception 3D: contrôler les trois axes de translation et de rotation est peu commode avec une souris et un clavier.
• Jeux à plusieurs (jeux de société...).
• Dessin.
• Organisation de graphes.
• Consultation de plans, d'images: le multitouch permet de créer une interface naturelle (qui se rapproche de ce qui était fait avec les versions papier).

Implémentation

Périphérique d'I/O sous UNIX

Dans l'idéal, tous les dispositifs d'entrées et de sorties sont gérés au niveau du serveur X sous UNIX. On entend par dispositifs d'entrées/sorties tous ceux qui donnent de l'information ou la recueillent de la part de l'opérateur, c'est à dire, wacom, souris, clavier, écran, webcams.

Continuons notre parallèle entre son et surface tactile:

À l'envers de toute logique, X Server ne propose rien pour gérer le son: les applications se connectent directement à ALSA ou OSS. C'est étonnant dans le sens où le but avoué d'utiliser un X Server est de centraliser toutes les interactions avec l'opérateur, et ainsi de pouvoir prendre le contrôle de la machine, ou simplement d'une seule application graphique à travers une interface réseau. Voir “Remote X11” et “XDMCP” pour approfondir ce sujet.

Pour utiliser une application à distance, en se connectant au serveur X de la machine distante, on arrive donc à la voir, et celle-ci reçoit bien les événements de souris, clavier de la machine cliente, par contre, le son de l'application reste sur la machine distante, à moins qu'on utilise une solution tierce pour le rapatrier sur le client (Esd/arts/PulseAudio...), mais qui pose alors des problèmes de synchronisation entre son et image, cause une duplication de fonctionnalités (gestion du transport des données en double), et enfin, oblige l'utilisateur à se connecter à deux services où un seul devrait suffire.

Ce défaut de conception possède une solution en développement depuis 2008: “Audio Extention for the X Window System” (cf références en fin de document).

On se retrouve exactement avec la même situation pour les surfaces tactiles, qui sont actuellement gérées de la même façon que le son: sans passer par X Server.

La solution est ici aussi en développement, avec la création de MPX. Par contre rien en cours à la connaissance de l'auteur pour ce qui est de développer une extension à X Server traditionnel pour intégrer la gestion des surfaces Multitouch (est-ce possible?)

Comment définir un protocole pour gérer les Events

On a deux approches possibles pour ce qui est de la responsabilité du protocole:

• Faut-il un protocole qui décrit exactement l'état des entrées sur la table?

• Faut-il un protocole qui fait des interprétations? (comprendre un geste et envoyer un event d'agrandissement, de rotation, de drag&drop, etc).

Le meilleur choix et de représenter l'état de la table, puis de réaliser des bibliothèques qui proposent aux applications d'interpréter certaines configurations comme un geste.

Pour ce qui est de la définition du protocole,

• Prendre en compte que l'on puisse utiliser une table avec les doigts, ou avec 1+ stylet

• Prendre en compte que certaines tables sont multiusers, et donc capables de détecter a qui appartient un blob (ou une main...).

• Prendre en compte que l'on peut avoir du hardware qui se limite à détecter des blobs (le cas le plus fréquent en fait), mais d'autres qui vont détecter des mains, différencier main droite et main gauche, et stylet.
• Pour la détection de mains, prendre en compte les angles entre chaque doigt pour les gestes
• Pour les stylets reconnaître différents stylets (utile si on veut faire un blackboard virtuel, et qu'on aura un stylet noir, un stylet bleu, un rouge, ou bien une application 3d, avec un stylet de rotation, un autre de translation... les possibilités sont infinies)

Le groupe de travail travaillant sur MPX a été très loin pour ce qui est de la réflexion sur comment gérer et représenter les entrées de l'opérateur vis à vis d'une surface multitouch. De même pour TUIO avec la nouvelle version de leur protocole.

Cf Références en fin d'article:

• 4ème et 5ème liens dans la catégorie MPX
• Spécifications TUIO 2.0 sur tuio.org

Protocoles existants

TUIO 1, et 1.1

Basés sur OSC, et utilise un socket UDP pour communiquer avec les applications voulant s'en servir, la version 1.1 est rétrocompatible avec la version 1.0.

On peut trouver étonnant le fait d'utiliser un socket réseau dans ce cas la, mais le choix a été fait car les développeurs qui ont réalisé les implémentations de référence de TUIO ont réalisé un produit très portable, sans vouloir s'embarrasser de devoir faire varier l'implémentation d'un OS à l'autre. Ce problème est d'ailleurs déjà mentionné dans le point III.1.

Autre faille de conception de TUIO, il est parfait pour décrire les tables de type FTIR, qui ne détectent que l'emplacement de doigts qui touchent la table, et qui sont incapables de différencier un doigt d'un objet (téléphone, feuille de papier, paume de la main, stylet), ou différents doigts entre eux.

Ce protocole est le plus utilisé, mais aussi le plus "deprecated".

Sa deuxième version, dont les spécifications techniques sont prêtes, mais les implémentations de référence en cours de création sont donc plus que justifiées.

Windows Seven

Windows 7 propose son propre protocole pour communiquer avec du hardware multitouch, ainsi que les bibliothèques qui vont avec pour construire des applications utilisant ces fonctionnalités. Un accent a été mis sur la rétrocompatibilité, avec l'émulation d'une souris par la table tactile pour les applications non compatibles.

Il existe un serveur TUIO qui se base sur les events de Vista, afin de pouvoir faire marcher des applications utilisant un client TUIO sur, par exemple, un tablet PC sous Vista.

Cf Références en fin d'article:

• Liste de serveurs TUIO sur tuio.org
• MSDN

Protocoles propriétaires

On trouve certaines entreprises qui proposent des solutions capables de traiter beaucoup plus que les possibilités de TUIO 1.1, mais qui ne sont clairement pas implémentées sur Windows 7 (angle entre les doigts reconnaissance de marqueurs...).

Il est fort probable qu'ils aient utilisé un protocole complètement propriétaire, ou pire, n'aient pas établi de couche entre le driver du hardware utilisé, et les applications multitouch qu'ils proposent.

Cf Références en fin d'article:

• multitouch.fi

Protocole à venir: TUIO 2

Propose toutes les capacités qu'on peut attendre pour l'instant. Peut traiter des events sur des mains qui ne touchent pas la table, des stylets, différents utilisateurs, et ainsi de suite.

Cf Références en fin d'article:

• Spécifications TUIO 2.0 sur tuio.org

Protocoles à venir: avec MPX

MPX est une version modifiée de X Server, afin de pouvoir gérer les surfaces multitouch.

La création de MPX va beaucoup plus loin que la définition d'un standard pour utiliser une surface Multitouch comme dispositif d'entrée, mais la contient.

Cf Références en fin d'article:

• X11 Input Extension Protocol Specification
• Redefining Input in X

Sources:

La même problématique, avec les cartes son.

Utile pour comprendre la responsabilité d'une API unifiée, le rôle du driver, de son lien avec XServer...

http://en.wikipedia.org/wiki/Open_Sound_System

http://en.wikipedia.org/wiki/Advanced_Linux_Sound_Architecture

http://www.alsa-project.org

http://www.agnula.info/documentation/dp_tutorials/alsa_jack_ladspa/images/JACK-Diagram.html

http://www.chaoticmind.net/~hcb/murx/xaudio/index.html

Multipoint X Server

http://www.x.org/wiki/Development/Documentation/MPX

http://en.wikipedia.org/wiki/MPX

Driver Xorg/MPX convertissant un flux TUIO en flux d'events d'input MPX

http://socghop.appspot.com/student_project/show/google/gsoc2009/nuigroup/t124022895795

X11 Input Extension Protocol Specification: http://www.x.org/docs/Xi/port.pdf

Redefining Input in X: http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/088-redefining_input_in_X.pdf

http://grafitiproject.files.wordpress.com/2008/12/grafiti.pdf

http://code.google.com/p/sparsh-ui/

Autres

http://nuigroup.com/forums/viewthread/4832/

http://nuigroup.com/forums/viewthread/4975/

http://blogs.msdn.com/e7/archive/2009/03/25/touching-windows-7.aspx

http://multitouch.fi/why-multitouch

http://tuio.org

Tags: mpx, multitouch, seven, TUIO

Cet article a été publié le Friday 5 February 2010 à 0:42 et est classé dans Autres. Vous pouvez en suivre les commentaires par le biais du flux RSS 2.0. Vous pouvez laisser un commentaire, ou faire un trackback depuis votre propre site.