FR2767210A1 - Procede et architecture pour simplifier les communications avec les dispositifs d'interface-utilisateur - Google Patents

Abstract

La présente invention concerne un procédé et une architecture destinés à simplifier les communications avec les dispositifs HID (100). Selon la présente invention, un système informatique comporte une couche transport USB (104) et un gestionnaire de classe HID (106) implémenté en haut de la couche transport. Un programme-client (102) appelle le gestionnaire (106) (soit directement, soit indirectement) pour obtenir des reports HID et des descripteurs de reports. Avant de renvoyer les reports aux programmes appelants, cependant, le gestionnaire (106) normalise les reports en leur donnant une longueur uniforme et en ajoutant des identificateurs de report à tous les reports qui ne possèdent pas déjà un identificateur de report. Un analyseur (130) est pourvu d'une fonction d'analyse de descripteur et d'une fonction de récupération d'éléments.

Description

La présente invention concerne des gestionnai-

res ("drivers") destinés à être utilisés en association

avec des dispositifs d'interfaçage-utilisateur (Human In-

terface Devices ou HID), ainsi que des procédés de lec-

ture et d'écriture utilisés avec de tels gestionnaires et dispositifs.

Le Bus USB (Universal Serial Bus) est une ar-

chitecture adaptée aux communications qui permet d'inter-

connecter un ordinateur personnel à toute une variété de

dispositifs en utilisant un simple câble à quatre fils.

Les protocoles USB permettent de configurer des disposi-

tifs lors de la mise en marche ou lorsqu'on les branche en cours de marche. Ces dispositifs se répartissent en

diverses classes de dispositifs. Chaque classe de dispo-

sitifs définit le comportement et les protocoles communs

de dispositifs dont les fonctions sont similaires.

L'invention que l'on va décrire ci-après est utilisée en association avec la classe HID. La classe HID comprend principalement des dispositifs (appelés par la suite dispositifs HID ou dispositifs de la classe HID) qui sont utilisés par des hommes afin de commander le fonctionnement de systèmes informatiques. Comme exemples

typiques de dispositifs de la classe HID, on mentionne-

ra

* Les claviers et les dispositifs de poin-

tage - par exemple, les souris standards, les

boules roulantes ou les manettes de jeux.

* Les commandes du panneau frontal - par exem-

ple: molettes, commutateurs, boutons, et

curseurs.

* Les commandes qu'il est possible de trouver

sur des dispositifs tels que téléphones, té-

lécommandes de magnétoscopes, jeux ou dispo-

sitifs de simulation - par exemple: gants sensoriels, commandes des gaz, volants, et

pédales de gouvernes.

Les dispositifs susceptibles de ne pas néces-

siter d'interaction humaine, mais fournissant des données se trouvant dans un format simi- laire à celui des dispositifs de la classe HID - par exemple, lecteurs de codes-barres,

thermomètres ou voltmètres.

Le descriptif courant des HID, qui est incorpo-

ré ici à titre de référence, est diffusé par une organi-

sation à but non-lucratif dénommée USB - IF et est dispo-

nible auprès de cette organisation, laquelle est située à Hillsboro en Oregon. Le descriptif peut aussi être obtenu en passant par l'Internet à l'adresse www.usb.org. Le descriptif des HID est susceptible d'évoluer, bien que

ses caractéristiques les plus significatives soient au-

jourd'hui relativement bien définies et acceptées.

Une caractéristique bien définie et acceptée

des dispositifs HID, qui concerne principalement la pré-

sente invention, est que de tels dispositifs émettent et reçoivent les données dans des paquets de données appelés "reports". Les dispositifs offrent une grande souplesse

quant au formatage de tels reports.

Les reports contiennent deux types différents de données générées par les dispositifs HID: boutons et valeurs - appelés d'une manière générique ici éléments de données. Chaque élément de données est généré par une commande, comme par une touche, un curseur, l'un des axes d'une manette de jeu, etc. Un élément de données du type

bouton est un binaire et possède l'une parmi deux va-

leurs: 0 ou 1. Les éléments de données du type bouton sont générés par des choses telles que des touches ou des

commutateurs. Un élément de données du type valeur pos-

sède une plage de valeurs, indiquant habituellement la position analogique d'une commande continûment variable, telle qu'un curseur, un axe de manette de jeu, ou une commande des gaz. Bien que les dispositifs HID génèrent

habituellement des éléments de données d'entrée, des re-

ports peuvent aussi être reçus par des dispositifs HID, permettant à un ordinateur de commander des LED, le vo- lume de haut-parleurs, ainsi que d'autres dispositifs de

sortie situés sur un dispositif HID.

Chaque commande est associée à un "usage" spé-

cifié par le fabricant du dispositif HID. Les usages fournissent aux programmes d'application de l'ordinateur

des informations concernant des paramètres que l'on me-

sure via différentes commandes et indiquant ce qu'il faut

faire des éléments de données générés par les comman-

des - par exemple, entrées X, Y et Z. Le dispositif des HID comporte lui-même des définitions d'usages pour un

certain nombre de dispositifs différents, tels que cla-

viers, manettes de jeu, curseurs et autres dispositifs.

Un usage HID contient deux composants: une

page d'usage et un index d'usage. La page d'usage corres-

pond à un dispositif particulier. Il est probable que les pages d'usage les plus communes sont la page "ordinateur

générique" et la page "clavier". Les index d'usage cor-

respondent à des commandes spécifiques au sein de la

page, telles que touches de manette de jeu, axes, cur-

seurs, touches de clavier, etc. Dans la pratique, le terme "usage" fait parfois référence à un index d'usage. Dans le présent document, cependant, le terme "usage" fait référence à une paire de

valeurs comprenant une page d'usage et un index d'usage.

Le terme "spécification d'usage" est utilisé ici pour faire référence plus généralement à l'un ou l'autre des

deux composants d'un usage.

Comme déjà mentionné, la disposition et le for-

matage de reports HID varient fortement d'un dispositif à l'autre. D'une manière générale, chaque report contient

une pluralité d'éléments de données, ordonnés arbitraire-

ment, spécifiés par le dispositif, chaque élément de don-

nées possédant un nombre arbitraire de bits et un aligne-

ment arbitraire de bits au sein d'un report. En outre, les éléments de données, eux-mêmes, peuvent être reportés dans différents formats, tels que les formats champ de

bits et les formats combinaison d'index.

Un dispositif peut aussi séparer ses éléments de données en deux ou plus de deux reports, auquel cas

chaque report commence par un identificateur de report.

Les reports, eux-mêmes, ont des longueurs non-uniformes qui varient, et sont générés par le dispositif HID dans le cas uniquement o un élément de données contenu dans

le report change.

De plus, un dispositif peut grouper diverses commandes en différentes "collections", chaque collection

possédant son propre usage spécifié. Les collections peu-

vent recouvrir des reports différents. Des collections

peuvent aussi être imbriquées les unes dans les autres.

Des éléments de données correspondant à un même usage

peuvent être reportés dans des collections différentes.

Chaque dispositif HID génère un descripteur de

reports HID qui spécifie les reports générés par le dis-

positif. Pour chaque report, le descripteur de reports décrit la disposition et le formatage des éléments de

données contenus dans le report, ainsi que les usages as-

sociés à chaque élément de données.

Les descripteurs de reports HID sont codés en

utilisant un protocole sophistiqué. Tout programme d'ap-

plication qui utilise des données de report HID doit tout d'abord analyser le descripteur de reports associé pour déterminer comment interpréter les reports individuels, et comment trouver les éléments de données au sein des reports. L'analyse d'un descripteur de reports est une

tâche qui est extrêmement complexe.

Le protocole HID décrit ci-dessus est très ef-

ficace en termes de largeur de bande. De plus, il est re-

lativement simple a implémenter dans les dispositifs HID.

Cependant, ce système présente un certain nombre de dif-

ficultés pour les développeurs de programmes d'applica-

tion. Ces difficultés concernent principalement la flexi-

bilité admise dans les reports HID et la complexité des

descripteurs de reports HID.

L'écriture d'un programme d'application pour un dispositif HID connu n'est pas difficile. Dans un tel cas, le développeur sait à l'avance quelle est la nature exacte de tous les éléments de données disponibles et

comment ceux-ci sont disposés et formatés au sein des re-

ports HID.

Des difficultés surviennent, cependant, lorsque

l'on tente d'écrire un programme à utiliser avec diffé-

rents périphériques qui implémentent tous potentiellement

leurs reports de manières différentes et imprévisibles.

Un premier périphérique pourrait n'utiliser qu'un seul report, tandis qu'un autre pourrait diviser ses éléments de données en deux ou trois reports. Un premier clavier pourrait reporter les frappes sous la forme de champs de

bits, tandis qu'un autre pourrait utiliser une combinai-

son d'index. Une manette de jeu pourrait ne comporter que des commandes très basiques, tandis qu'une autre pourrait fournir des commandes plus sophistiquées, telles que des commandes de commutation et d'accouplement. Même les

tailles des reports diffèrent d'un périphérique à l'au-

tre, ce qui rend difficile la détermination des tailles

de tampon requises. Les collections, d'une manière simi-

laire, peuvent être implémentées d'une manière relative-

ment différente dans des périphériques différents.

Bien que toutes ces informations puissent être obtenues à partir du descripteur de reports, analyser les informations est relativement difficile - buffériser et

analyser les reports réels est aussi relativement compli-

qué lorsque l'on doit faire face à une telle diversité de formats. Par conséquent, bien que la technologie HID soit potentiellement en mesure d'assurer la compatibilité entre une diversité de dispositifs ou de périphériques et un programme d'application donné, une telle compatibilité ne peut être actuellement obtenue que par un très gros

investissement quant au développement du programme d'ap-

plication, si l'on veut que le programme d'application puisse s'adapter aux divers formats de report que l'on

trouve sur les périphériques HID.

La présente invention inclut un procédé et une architecture qui permettent à des programmes-client de

recevoir des éléments de données HID d'une manière con-

sistante, indépendamment du dispositif HID dont ils pro-

viennent et sans exiger des programmes-client qu'ils ef-

fectuent une analyse sophistiquée. Dans le mode de réali-

sation proposé à titre d'exemple, l'architecture comporte une couche transport à partir de laquelle des reports HID et des descripteurs de reports peuvent être obtenus, sur laquelle ils peuvent être écrits. Un gestionnaire de

classe HID est implémenté en haut de la couche transport.

Les programmes-client, parmi lesquels des programmes

d'application et des composants du système d'exploita-

tion, sont interfacés avec les dispositifs HID via le

gestionnaire de classe HID.

Selon un premier aspect de l'invention, le ges-

tionnaire de classe HID ajoute des identificateurs de re-

port à tous les reports qui ne contiennent pas déjà

d'identificateur de report. Cette étape ajoute de la con-

sistance aux reports HID, ce qui les rend plus faciles à lire et à analyser. De plus, le gestionnaire de classe

HID détermine le report le plus grand généré par un dis-

positif HID, et complète tous les autres reports émis par ce dispositif HID de manière à ce que tous les reports

émis par un dispositif donné aient une longueur uniforme.

Ceci ajoute à nouveau de la consistance, ce qui facilite pour les applications consommatrices la bufferisation et l'analyse des reports. Selon un autre aspect de la pré-

sente invention, un ensemble d'interfaces permet aux pro-

grammes-client de demander des éléments de données spéci-

fiés uniquement par leurs usages.

Durant une phase d'initialisation, le pro-

gramme-client récupère un descripteur de reports à partir du gestionnaire de classe, via un appel d'entrée/sortie de fichier normal. Il soumet ensuite ce descripteur de

reports à un analyseur, qui analyse le descripteur de re-

ports et retourne une structure de données contenant une

description de reports analysée. Lorsque le pro-

gramme-client tente de lire des éléments de données HID,

il récupère tout d'abord un report HID à partir du ges-

tionnaire de classe. Il appelle ensuite une fonction d'interfaçage avec des arguments qui incluent le report

HID, la structure de données contenant la description de

reports analysée, et une spécification d'usage (telle qu'une page d'usage et un index d'usage). La fonction d'interfaçage recherche le report HID de l'élément de

données associé à l'usage spécifié, en utilisant la des-

cription de reports analysée comme index dans le report HID, et retourne l'élément de données au client demandeur si l'élément de données est trouvé dans le report. Un identificateur de collection peut être spécifié en option dans les arguments à la fonction d'interfaçage, auquel

cas la fonction d'interfaçage limite les valeurs des don-

nées retournées à celles d'une collection HID spécifiée

par l'identificateur de collection.

La présente invention a pour objet un système

informatique caractérisé en ce qu'il comporte un gestion-

naire de dispositifs qui fournit des reports HID conte-

nant des éléments de données et un descripteur de reports

HID décrivant les reports HID et la disposition, le for-

matage, ainsi que des spécifications d'usage d'éléments de données au sein des reports HID, un gestionnaire de classe HID configuré pour demander les reports HID et le descripteur de reports HID à partir du gestionnaire de

dispositifs et les recevoir, une première fonction d'in-

terfaçage qui peut être appelée par un programme-client,

la première fonction d'interfaçage recevant une spécifi-

cation d'usage à partir du programme-client et, en ré-

ponse, trouvant et renvoyant un ou plusieurs éléments de données provenant d'un report HID spécifié qui ont les mêmes spécifications d'usage que celles reçues à partir

du programme-client.

Selon des caractéristiques particulières: - la première fonction d'interfaçage reçoit de

plus le report HID spécifié en provenance du pro-

gramme-client, - la première fonction d'interfaçage reçoit de plus le report HID spécifié, ainsi qu'une structure de données, en provenance du programme-client, la structure

de données contenant une description de reports analysée

basée sur le descripteur de reports HID, - la première fonction d'interfaçage reçoit de

plus un identificateur de collection et, en réponse, li-

mite les éléments de données à ceux d'une collection HID spécifiée par l'identificateur de collection, - il comporte en outre une seconde fonction d'interfaçage qui reçoit le descripteur de reports HID

et, en réponse, renvoie une structure de données conte-

nant une description de reports analysée, la première

fonction d'interfaçage recevant de plus ladite structure de données et utilisant ladite structure de données pour trouver lesdits éléments de données,

- il comporte une seconde fonction d'interfa-

çage qui reçoit le descripteur de reports HID en prove-

nance du programme-client et, en réponse, renvoie une

structure de données contenant une description de reports

analysée, la première fonction d'interfaçage recevant de plus ladite structure de données et utilisant ladite structure de données pour trouver lesdits éléments de données, - la première fonction d'interfaçage renvoie un code d'erreur si aucun élément de données ne possède la spécification d'usage dans le report HID spécifié, dans

lequel le report HID spécifié a été généré par un dispo-

sitif particulier, et dans lequel le code d'erreur indi-

que si une commande avec la spécification d'usage reçue est disponible sur ledit dispositif particulier, - il comporte en outre une seconde fonction d'interfaçage qui reçoit le descripteur de reports HID en provenance du programme-client et, en réponse, renvoie

une structure de données contenant une description de re-

ports analysée, la première fonction d'interfaçage rece-

vant de plus ladite structure de données et utilisant la-

dite structure de données pour trouver lesdits éléments

de données, dans lequel la première fonction d'interfa-

çage renvoie un code d'erreur s'il n'existe aucun élément

de donnée avec la spécification d'usage reçue dans le re-

port HID spécifié, dans lequel le report HID spécifié a été généré par un dispositif particulier, et dans lequel

le code d'erreur indique si une commande avec la spécifi-

cation d'usage reçue est disponible sur ledit dispositif particulier, - le gestionnaire de classe HID est en outre configuré pour normaliser les reports HID en provenance d'un dispositif HID particulier en leur donnant une taille uniforme, - le gestionnaire de classe HID est en outre configuré pour normaliser les reports HID en ajoutant un identificateur de report à tout report HID qui ne possède pas déjà d'identificateur de report et en donnant une taille uniforme aux reports HID provenant d'un dispositif HID particulier - la spécification d'usage reçue identifie une

page d'usage, et dans lequel les éléments de données ren-

voyés comprennent une combinaison d'index d'usage corres-

pondant à des boutons HID qui sont enfoncés, peu importe que le report HID spécifié contienne des combinaisons d'index ou des champs de bits, - les éléments de données renvoyés comportent une pluralité de valeurs HID,

- il comporte une seconde fonction d'interfa-

çage qui renvoie une combinaison de structures de données

spécifiant des collections HID, ainsi que leurs rela-

tions, sur la base du descripteur de reports HID,

- il comporte une seconde fonction d'interfa-

çage qui renvoie une combinaison de structures de données spécifiant des collections HID, ainsi que les relations

existant entre elles, sur la base du descripteur de re-

ports HID, dans lequel la première fonction d'interfaçage

reçoit de plus un identificateur de collection et, en ré-

ponse, trouve les éléments de données dans une collection HID spécifiée par l'identificateur de collection, - le gestionnaire de dispositifs écrit aussi des reports HID sur des dispositifs HID, comportant en outre une seconde fonction d'interfaçage qui accepte un élément de données et une spécification d'usage et, en réponse, positionne et formate l'élément de données dans

un report HID à écrire sur un dispositif HID.

L'invention a également pour objet un support de mémorisation lisible par ordinateur caractérisé en ce

qu'il comporte des instructions exécutables par ordina-

teur qui définissent une première fonction d'interfaçage dans un système informatique comportant un dispositif HID qui fournit des reports HID contenant des éléments de données et un descripteur de reports HID décrivant les reports HID et la disposition, le formatage, ainsi que des spécifications d'usage d'éléments de données au sein

des reports HID, la première fonction d'interfaçage rece-

vant un report HID et une spécification d'usage en prove-

nance d'un programme-client et, en réponse, trouvant et renvoyant un ou plusieurs éléments de données à partir du report HID qui ont les mêmes spécifications d'usage que

celles reçues à partir du programme-client.

Selon des caractéristiques particulières: - la première fonction d'interfaçage reçoit de

plus une description de reports analysée sur la base du

descripteur de reports HID provenant du programme-client, - la première fonction d'interfaçage reçoit de

plus un identificateur de collection et, en réponse, li-

mite les éléments de données renvoyés à ceux d'une col-

lection HID spécifiée par l'identificateur de collection, - les instructions définissent une seconde

fonction d'interfaçage qui reçoit le descripteur de re-

ports HID et, en réponse, renvoie une description de re-

ports analysée, la première fonction d'interfaçage rece-

vant de plus ladite description de reports analysée et

utilisant ladite description de reports analysée pour

trouver lesdits éléments de données, - la première fonction d'interfaçage renvoie un code d'erreur s'il n'existe aucun élément de données avec la spécification d'usage reçue dans le report HID reçu, dans lequel le report HID spécifié a été généré par un dispositif particulier, et dans lequel le code d'erreur

indique si une commande avec la spécification d'usage re-

çue est disponible sur ledit dispositif particulier, - les instructions définissent une seconde

fonction d'interfaçage qui reçoit le descripteur de re-

ports HID et, en réponse, renvoie une structure de don-

nées contenant une description de reports analysée, la

première fonction d'interfaçage recevant de plus ladite structure de données et utilisant ladite structure de données pour trouver lesdits éléments de données, dans lequel la première fonction d'interfaçage renvoie un code d'erreur s'il n'existe aucun élément de données avec la spécification d'usage reçue dans un report HID spécifié, dans lequel le report HID spécifié a été généré par un dispositif particulier, et dans lequel le code d'erreur

indique si une commande avec la spécification d'usage re-

çue est disponible sur ledit dispositif particulier, - la spécification d'usage reçue identifie une

page d'usage, et dans lequel les éléments de données ren-

voyés comprennent une combinaison d'index d'usage corres-

pondant à des boutons HID qui sont enfoncés, peu importe que le report HID reçu contienne des combinaisons d'index ou des champs de bits, - les éléments de données renvoyés incluent une pluralité de valeurs HID, - les instructions définissent une seconde fonction d'interfaçage qui renvoie une combinaison de structures de données spécifiant des collections HID et

les relations existant entre elles sur la base d'un des-

cripteur de reports HID, - les instructions définissent une seconde fonction d'interfaçage qui renvoie une combinaison de structures de données spécifiant des collections HID et

* les relations existant entre elles sur la base d'un des-

cripteur de reports HID, dans lequel la première fonction

d'interfaçage reçoit de plus un identificateur de collec-

tion et, en réponse, limite les éléments de données ren-

voyés à ceux d'une collection HID spécifiée par l'identi-

ficateur de collection, - les instructions définissent une seconde fonction d'interfaçage qui accepte un élément de données et une spécification d'usage et, en réponse, positionne et formate l'élément de données dans un report HID à

écrire sur un dispositif HID.

L'invention a également pour objet un procédé de lecture d'éléments de données HID, caractérisé en ce

qu'il comporte les étapes consistant à obtenir un des-

cripteur de reports HID décrivant des reports HID asso-

ciés et la disposition, le formatage, ainsi que des spé-

cifications d'usage d'éléments de données au sein de tels reports HID, soumettre le descripteur de reports HID à un analyseur via une interface, l'analyseur implémentant une étape consistant à analyser le descripteur de reports HID

et à renvoyer une description de reports analysée sur la

base du descripteur de reports HID, obtenir un report HID

contenant des éléments de données décrits par le descrip-

teur de reports HID, appeler une première fonction d'in-

terfaçage avec des arguments comprenant le report HID, la

description de reports analysée, et une spécification

d'usage, la première fonction d'interfaçage trouvant et renvoyant un ou plusieurs éléments de données du report HID qui ont les mêmes spécifications d'usage que celles spécifiées dans les arguments à la première fonction d'interfaçage. Selon des caractéristiques particulières: -.la première fonction d'interfaçage renvoie un code d'erreur si elle ne peut trouver ledit ou lesdits plusieurs éléments de données dans le report HID, le code d'erreur indiquant si une commande avec la spécification

d'usage est disponible dans un report décrit par le des-

cripteur de reports HID, - il comporte en outre une étape consistant à normaliser les reports HID en provenance d'un dispositif HID particulier en leur donnant une taille uniforme, - il comporte en outre une étape consistant à normaliser les reports HID en ajoutant un identificateur de report à tout report HID qui ne possède pas déjà

d'identificateur de report et en donnant une taille uni-

forme aux reports HID provenant d'un dispositif HID par-

ticulier, - les arguments transmis à la première fonction

d'interfaçage comprennent un identificateur de collec-

tion, le procédé comportant une autre étape consistant à limiter les éléments de données renvoyés à ceux d'une

collection HID spécifiée par l'identificateur de collec-

tion, - il consiste en outre à appeler une seconde fonction d'interfaçage avec un argument comprenant la

description de reports analysée, la seconde fonction

d'interfaçage renvoyant une combinaison de structures de données spécifiant des collections HID et les relations

existant entre elles, les arguments de la première fonc-

tion d'interfaçage comprenant en outre un identificateur

de collection, la première fonction d'interfaçage limi-

tant les éléments de données renvoyés à ceux d'une col-

lection HID spécifiée par l'identificateur de collection, - la spécification d'usage est une page d'usage, et dans lequel les éléments de données renvoyés incluent une pluralité de valeurs HID, - la spécification d'usage est une page d'usage, et dans lequel les éléments de données renvoyés comprennent une combinaison d'index d'usage correspondant à des boutons HID qui sont enfoncés, peu importe que le report HID contienne des combinaisons d'index ou des

champs de bits.

L'invention a également pour objet un support de mémorisation lisible par ordinateur caractérisé en ce

qu'il comporte des instructions exécutables par ordina-

teur qui définissent un ensemble de fonctions d'interfa-

çage qui peuvent être appelées dans un système informati- que comportant un dispositif HID qui fournit des reports HID contenant des éléments de données et un descripteur

de reports HID décrivant les reports HID et la disposi-

tion, le formatage, ainsi que des spécifications d'usage d'éléments de données au sein des reports HID, l'ensemble de fonctions d'interfaçage définies par les instructions

comportant une fonction d'analyse de descripteur qui re-

çoit un argument de fonction comportant un descripteur de

reports HID et, en réponse, analyse le descripteur de re-

ports HID et renvoie une description de reports analysée basée sur le descripteur de reports HID, une ou plusieurs fonctions de

récupération d'éléments qui reçoivent des

arguments de fonctions comprenant un report HID, la des-

cription de reports analysée, et une spécification

d'usage, ladite ou lesdites plusieurs fonctions de récu-

pération d'éléments trouvant et renvoyant un ou plusieurs

éléments de donnée à partir du report HID qui ont les mê-

mes spécifications d'usage que celles fournies dans les

arguments aux fonctions de récupération d'éléments.

Selon des caractéristiques particulières:

- les fonctions de récupération d'éléments com-

prennent une fonction de récupération de boutons, la spé-

cification d'usage incluant une page d'usage, dans lequel

la fonction de récupération de boutons renvoie une combi-

naison d'index d'usage correspondant à des boutons HID

qui sont enfoncés, peu importe que le report HID con-

tienne des combinaisons d'index ou des champs de bits,

- les fonctions de récupération d'éléments com-

prennent une fonction de récupération de valeurs, la spé-

cification d'usage incluant une page d'usage et un index

d'usage, dans lequel la fonction de récupération de va-

leurs renvoie une valeur HID correspondant à la spécifi-

cation d'usage,

- la fonction de récupération d'éléments ren-

voie une combinaison de valeurs HID correspondant à la spécification d'usage,

- les fonctions de récupération d'éléments com-

prennent une fonction de récupération de boutons qui ren-

voie une combinaison d'index d'usage correspondant à des boutons HID qui sont enfoncés, peu importe que le report HID contienne des combinaisons d'index ou des champs de bits, une fonction de récupération de valeurs qui renvoie une ou plusieurs valeurs HID, - l'ensemble de fonctions d'interfaçage défini par les instructions exécutables par ordinateur définit en outre une fonction d'identification de collection qui

reçoit des arguments de fonction comprenant la descrip-

tion de reports analysée et, en réponse, renvoie une com-

binaison de structures de données spécifiant des collec-

tions HID et les relations existant entre elles, - l'ensemble de fonctions d'interfaçage défini par les instructions exécutables par ordinateur définit en outre une fonction d'identification de collection qui

reçoit des arguments de fonction comprenant la descrip-

tion de reports analysée et, en réponse, renvoie une com-

binaison de structures de données spécifiant des collec-

tions HID et les relations existant entre elles, dans le-

quel les arguments reçus par les fonctions de récupéra-

tion d'éléments incluent un identificateur de collection

optionnel, les fonctions de récupération d'éléments limi-

tent les éléments de données renvoyés à ceux d'une col-

lection HID spécifiée par l'identificateur de collection lorsqu'un tel identificateur de collection est fourni, - l'ensemble de fonctions d'interfaçage défini par les instructions exécutables par ordinateur définit en outre une ou plusieurs fonctions d'écriture d'éléments qui reçoivent des arguments de fonction comprenant un ou plusieurs éléments de données et une spécification

d'usage, ladite ou lesdites plusieurs fonctions d'écri-

ture d'éléments positionnant et formatant lesdits élé-

ments de données dans un report HID à écrire sur un dis-

positif HID, - les fonctions de récupération d'éléments sont

définies pour recevoir des reports HID qui sont normali-

sés en termes de taille.

L'invention a également pour objet un gestion-

naire de classe HID qui reçoit des reports HID de tailles différentes en provenance de un ou plusieurs dispositifs

HID, procédé pour renvoyer des reports HID à des program-

mes-client demandeurs, caractérisé en ce qu'il comporte

les étapes consistant à recevoir des reports HID en pro-

venance d'un dispositif HID, normaliser les reports HID provenant du dispositif HID en leur donnant une taille

uniforme, renvoyer les reports HID normalisés aux pro-

grammes-client demandeurs.

Selon des caractéristiques particulières: - la taille uniforme est au moins aussi grande que celle du report HID le plus grand, généré par ledit dispositif HID, - l'étape de normalisation comporte l'ajout d'un identificateur de report à tout report HID qui ne possède pas déjà un identificateur de report, - l'étape de normalisation comporte l'ajout d'un identificateur de report à tout report HID qui ne possède pas déjà un identificateur de report, la taille

uniforme est la taille du report HID le plus grand, géné-

ré par ledit dispositif HID, incluant tout identificateur

de report ajouté.

L'invention a également pour objet un système

informatique, caractérisé en ce qu'il comporte un ges-

tionnaire HID qui fournit des reports HID de tailles dif-

férentes à partir de un ou plusieurs dispositifs HID, un

gestionnaire de classe HID configuré pour demander et re-

cevoir les reports HID en provenance du gestionnaire HID et pour renvoyer les reports HID en réponse à des deman-

des émanant de programmes-client, dans lequel le ges-

tionnaire de classe HID normalise les reports HID d'un dispositif HID particulier en leur donnant une taille uniforme. Selon des caractéristiques particulières: - la taille uniforme est au moins aussi grande que celle du report HID le plus grand, généré par ledit dispositif HID particulier,

- la normalisation inclut l'ajout d'un identi-

ficateur de report à tout report HID qui ne possède pas déjà un identificateur de report,

- la normalisation inclut l'ajout d'un identi-

ficateur de report à tout report HID qui ne possède pas déjà un identificateur de report, la taille uniforme est la taille du report HID le plus grand, généré par ledit dispositif HID particulier, incluant tout identificateur

de report ajouté.

L'invention a enfin pour objet un support de

mémorisation lisible par ordinateur comportant des ins-

tructions qu'implémente un gestionnaire de classe HID, caractérisé en ce que les instructions sont exécutables par ordinateur pour implémenter les étapes consistant à recevoir des reports HID en provenance de un ou plusieurs dispositifs HID, ajouter un identificateur de report à tout report HID qui ne possède pas déjà un identificateur de report, normaliser les reports HID d'un dispositif HID particulier en leur donnant une taille uniforme, renvoyer

les reports HID normalisés aux programmes-client deman-

deurs. Selon des caractéristiques particulières: - la taille uniforme est au moins aussi grande

que la taille du report HID le plus grand, généré par le-

dit dispositif HID particulier, - l'étape de normalisation comprend l'ajout d'un identificateur de report à tout report HID qui ne possède pas déjà un identificateur de report, la taille uniforme est la taille du report

HID le plus grand, généré par ledit dispositif HID parti-

culier, incluant tout identificateur de report ajouté.

On va maintenant décrire la présente invention, à titre d'exemple uniquement, en se reportant aux dessins annexés sur lesquels: - la figure 1 est un schéma fonctionnel d'un

exemple de contexte d'exploitation pour la présente in-

vention,

- la figure 2 est un schéma fonctionnel repré-

sentant un système et une architecture destinés aux com-

munications de données HID selon la présente invention,

- la figure 3 est un schéma fonctionnel illus-

trant la normalisation de reports HID selon la présente invention, et

- la figure 4 est un schéma fonctionnel illus-

trant des fonctions d'interfaçage avec l'analyseur selon

la présente invention.

La figure 1 et la description qui va suivre

sont destinées à fournir une brève description générale

d'un contexte d'exploitation adapté dans lequel peut être implémentée la présente invention. Bien que cela ne soit pas nécessaire, on va décrire la présente invention dans

le contexte générale d'instructions exécutables par ordi-

nateur, comme des modules de programme, exécutées par un ordinateur personnel. D'une manière générale, des modules de programme comportent des routines, des programmes, des objets, des composants, des structures de données, des interfaces, des fonctions d'interfaçage, etc. mémorisés

dans une mémoire lisible par ordinateur. Lorsque exécu-

tés, ces modules effectuent des tâches particulières, im-

plémentent des types de données abstraites particulières,

et mettent à disposition ou implémentent diverses inter-

faces et fonctions d'interfaçage. De plus, l'homme du mé-

tier appréciera que la présente invention peut être im-

plémentée en utilisant d'autres configurations pour le

système informatique, y compris des dispositifs porta-

bles, des systèmes multiprocesseurs, de l'électroménager

à base de microprocesseur ou programmable, des ordina-

teurs communiquants, des mini-ordinateurs, des ordina-

teurs centraux, et analogues. La présente invention peut aussi être implémentée dans des contextes informatiques distribués dans lesquels les tâches sont effectuées par des dispositifs de traitement éloignés qui sont reliés

entre eux via un réseau de communication. Dans un con-

texte informatique distribué, les modules de programme peuvent être placés dans des dispositifs de mémorisation

locaux et éloignés.

En se reportant à la figure 1, un exemple de système pour implémenter la présente invention comporte un dispositif informatique universel qui se présente sous

la forme d'un ordinateur personnel ou d'un système infor-

matique 1 conventionnel, incluant une unité de traitement 21, une mémoire-systéme 22 et un bus-système 23 qui relie

divers composants du système, parmi lesquels la mé-

moire-système, à l'unité de traitement 21. Le bus-système 23 peut avoir une structure de n'importe quel type et peut être y compris un bus de mémoire ou un gestionnaire

de mémoire, un bus périphérique, et un bus local utili-

sant n'importe laquelle parmi une diversité d'architectu-

res. La mémoire-système inclut une mémoire à lecture seule (ROM) 24, et une mémoire à accès aléatoire (RAM) 25. Un système de gestion de base des entrées/sorties 26 (BIOS), contenant les routines de base qui aident au transfert des informations entre les éléments contenus

dans l'ordinateur personnel 20, tel que durant le lance-

ment, est mémorisé dans la ROM 24. L'ordinateur personnel inclut en outre une mémoire à disque dur 27 destinée à permettre qu'une lecture et une écriture soient effec- tuées sur un disque dur, non- représenté, une mémoire à disque magnétique 28 destinée à permettre une lecture ou une écriture sur un disque magnétique amovible 29, et une

mémoire à disque optique 30 destinée à permettre une lec-

ture ou une écriture sur un disque optique amovible 31, tel qu'un CD ROM ou autres supports optiques. La mémoire à disque dur 27, la mémoire à disque magnétique 28 et la mémoire à disque optique 30 sont reliées au bus-systéme

23 par une interface 32 de mémoire à disque dur, une in-

terface 33 de mémoire à disque magnétique, et une inter-

face 34 de mémoire optique, respectivement. Les mémoires

et leurs supports lisibles par ordinateur associés garan-

tissent la mémorisation non-volatile des instructions li-

sibles par ordinateur, des structures de données, des mo-

dules de programme, ainsi que d'autres données, pour l'ordinateur personnel 20. Bien que le contexte proposé à titre d'exemple, décrit ici, utilise un disque dur, un

disque magnétique amovible 29 et un disque optique amovi-

ble 31, l'homme du métier notera qu'il est aussi possible

d'utiliser, dans le contexte d'exploitation proposé à ti-

tre d'exemple, d'autres types de supports lisibles par ordinateur, capables de mémoriser des données accessibles à un ordinateur, tels que des cassettes magnétiques, des cartes à mémoire-flash, des disques vidéonumériques, des cartouches Bernoulli, des mémoires à accès aléatoire

(RAM), des mémoires à lecture seule (ROM), et analogues.

Un certain nombre de modules de programme peu-

vent être mémorisés sur le disque dur, le disque magnéti-

que 29, le disque optique 31, la ROM 24 ou la RAM 25, y compris un système d'exploitation 35, un ou plusieurs

programmes d'application 36, d'autres modules de pro-

gramme 37 et des données de programme 38. Un utilisateur peut entrer des instructions et des informations sur l'ordinateur personnel 20 via des dispositifs d'entrée, tels qu'un clavier 40 et un dispositif de pointage 42. D'autres dispositifs d'entrée (non-représentés) peuvent comprendre un microphone, une manette de jeu, un clavier

de jeu, une antenne-satellite, un scanner, ou analogues.

Ces dispositifs d'entrée, ainsi que d'autres, sont sou-

vent reliés à l'unité de traitement 21 via une interface

à port série 46 qui est reliée au bus-système, mais peu-

vent être reliés par d'autres interfaces, comme par un port parallèle, un port de jeu, ou un bus série universel

(USB). Un moniteur 47 ou autre type de dispositif d'affi-

chage est aussi relié au bus-système 23 via une inter-

face, tel qu'un adaptateur vidéo 48. En plus du moniteur,

les ordinateurs personnels comportent d'une manière typi-

que d'autres dispositifs de sortie périphériques

(non-représentés), tels que des haut-parleurs et des im-

primantes.

L'ordinateur personnel 20 peut être utilisé dans un contexte d'intégration à un réseau en utilisant des connexions logiques vers un ou plusieurs ordinateurs éloignés, tel qu'un ordinateur éloigné 49. L'ordinateur éloigné 49 peut être un autre ordinateur personnel, un

serveur, un routeur, un ordinateur communiquant, un dis-

positif pair ou autre noeud de réseau commun, et comporte

d'une manière typique une grande partie, voire la totali-

té des éléments décrits ci-dessus en référence à l'ordi-

nateur personnel 20, bien que seul un dispositif de mémo-

risation 50 ait été illustré sur la figure 1. Les con-

nexions logiques représentées sur la figure 1 incluent un réseau local (LAN) 51 et un réseau étendu (WAN) 52. De tels contextes d'intégration à un réseau sont communs dans les bureaux, les réseaux informatiques d'entreprise,

les intranets, et l'Internet.

Lorsque utilisé dans un contexte d'intégration à un réseau local, l'ordinateur personnel 20 est relié au réseau local 51 via une interface-réseau ou adaptateur 53. Lorsque utilisé dans un contexte d'intégration à un réseau étendu, l'ordinateur personnel 20 comporte d'une manière typique un modem 54, ou d'autres moyens, pour établir les communications via le réseau étendu 52, tel

que l'Internet. Le modem 54, qui peut être interne ou ex-

terne, est relié au bus-système 23 via l'interface à port série 46. Dans un contexte d'intégration à un réseau, les modules de programme décrits en référence à l'ordinateur

personnel 20, ou des parties de ceux-ci, peuvent être mé-

morisés dans le dispositif de mémorisation éloigné. On

notera que les connexions au réseau qui ont été représen-

tées ne sont données qu'à titre d'exemple et que d'autres

moyens peuvent être utilisés pour établir un lien de com-

munication entre les ordinateurs.

L'ordinateur illustré utilise un système d'ex-

ploitation similaire aux systèmes d'exploitation de la

famille Windows, commercialisés par Microsoft Corpora-

tion. La fonctionnalité décrite ci-dessous est implémen-

tée en utilisant des techniques de programmation stan-

dards, y compris en utilisant les interfaces OLE et COM, décrites dans le document "Inside OLE 2"; Brockschmidt,

Kraig; Microsoft Press, 1994.

La figure 2 représente les composants implémen-

tés au sein de l'ordinateur 20 pour assurer les communi-

cations entre dispositifs HID 100 et programmes-client,

tels que le programme-client 102 représenté. Tel qu'uti-

lisé ici, le terme "dispositif HID" indique tout disposi-

tif capable de communiquer avec les composants de l'ordi-

nateur en utilisant le protocole HID dans sa forme cou-

rante ou dans n'importe quelle forme révisée. Un pro-

gramme-client est un programme quelconque ou un composant

de programme quelconque, y compris les composants du sys-

tème d'exploitation, qui est un consommateur d'éléments

de données HID.

Conformément à la figure 2, une couche trans-

port ou pile de gestionnaires 104, incluant un ou plu-

sieurs gestionnaires de dispositifs USB, assure les com-

munications de bas niveau avec les dispositifs HID con-

formément aux standards et protocoles USB. Un gestion-

naire de classe HID 106 est implémenté en haut de la cou-

che transport 104, créant l'objet dispositif fonctionnel qui commande l'objet dispositif physique énuméré par la couche transport (telle que la pile de gestionnaires de dispositifs USB). La pile de gestionnaires 104 fournit des reports HID, ainsi que des descripteurs de reports HID décrivant les reports HID. Les reports HID, tels que décrits ci- dessus, sont souvent de tailles différentes et contiennent des éléments de données correspondant à des

commandes implémentées dans les dispositifs HID. Les des-

cripteurs de reports HID spécifient la disposition, le

formatage, ainsi que les spécifications d'usage des élé-

ments de données au sein des reports HID. Le gestionnaire de classe HID 106 est configuré pour demander les reports HID et les descripteurs de reports HID au gestionnaire de

*dispositifs USB et les recevoir.

Les clients du système d'exploitation peuvent appeler le gestionnaire de classe HID afin de lire les reports HID et les descripteurs de reports provenant des dispositifs HID, ainsi que d'autres types de données

fournies par les dispositifs HID. De tels composants peu-

vent aussi écrire sur les dispositifs HID en fournissant des. reports formatés d'une manière appropriée. Les clients du programme d'application communiquent aussi avec les dispositifs HID via le gestionnaire de classe HID, bien qu'indirectement - les programmes d'application communiquent dans la réalité avec les dispositifs HID en procédant à des appels d'entrée/sortie de fichier via le système d'exploitation de l'ordinateur, qui communique à

son tour directement avec le gestionnaire de classe HID.

Le gestionnaire de classe HID 106 est implémen- té généralement en utilisant des techniques classiques, excepté l'amélioration significative de la normalisation

de tous les reports HID avant de les délivrer aux pro-

grammes-client. Une première manière d'effectuer cette

normalisation consiste à ajouter un identificateur de re-

port HID à tout report ne possédant pas déjà d'identifi-

cateur de report. Conformément au descriptif des HID, il est nécessaire que les reports aient des identificateurs de report uniquement lorsque le nombre de reports émis par un dispositif dépasse un; lorsqu'un seul report est disponible à partir d'un dispositif, un identificateur de

report est optionnel.

Suivant une autre étape, lors de la normalisa-

tion des reports HID, le gestionnaire de classe unifor-

mise la taille de tous les reports émis par un dispositif HID donné. D'une manière spécifique, le gestionnaire de classe détermine la taille du report le plus grand généré par un dispositif particulier (incluant un identificateur de report ajouté), et complète tous les reports émanant de ce dispositif de manière à ce que leur taille soit la

même que la taille du report le plus grand.

Ainsi, la présente invention inclut un procédé,

implémenté par un gestionnaire de classe HID, qui con-

siste à ne renvoyer les reports HID aux programmes-client demandeurs qu'après les avoir normalisés. Un tel procédé comporte les étapes consistant à recevoir les reports HID générés par un dispositif HID, puis à les normaliser en

les complétant (par des octets possédant des valeurs ar-

bitraires) afin d'en uniformiser la taille.

Ce traitement est illustré sur la figure 3.

Plusieurs reports différents 108, possédant chacun une

longueur différente, sont récupérés à partir d'un dispo-

sitif HID particulier. Avant de les passer aux programmes demandeurs, le gestionnaire de classe HID 106 les com-

plète de manière à ce qu'ils aient tous la même longueur.

Les reports normalisés sont indiqués par la référence nu-

mérique 109 sur la figure 3 - le complément est indiqué par des traits interrompus. D'une manière similaire, un

report individuel 110 est récupéré à partir d'un disposi-

tif différent. Le report 110, tel que récupéré à partir de la pile de transport, ne contient aucun identificateur de report. En conséquence, le gestionnaire de classe HID

106 ajoute un identificateur de report comme premier oc-

tet du report, d'o l'obtention d'un report normalisé 111.

La normalisation des reports fournit des avan-

tages importants. L'un des avantages les plus significa-

tifs est qu'elle permet aux programmes d'application de garantir que chaque lecture à partir du gestionnaire de

classe 106 ne retournera qu'un seul et unique report HID.

On va examiner, par exemple, la situation résultant d'un dispositif HID qui génère deux reports HID de longueurs différentes. L'un ou l'autre des reports peut être généré à un instant quelconque; un client demandeur ne sait pas

lequel des deux reports sera le suivant. Lorsqu'une en-

trée/sortie de fichier est effectuée pour lire le report

suivant, le client ne sait pas (sans normalisation) com-

bien d'octets doivent être lus. Par conséquent, il est

probable que deux opérations de lecture seront nécessai-

res, ou que la première opération de lecture récupérera une partie du report suivant. Ce problème est éliminé par la normalisation décrite cidessus, du fait que tous les reports ont la même longueur. Un client peut choisir de lire soit un report entier, soit un multiple entier de la

longueur d'un report.

D'une manière similaire, le fait de s'assurer que tous les reports commenceront par un identificateur de report signifie qu'un client peut s'attendre à ce que

la donnée suivante commence toujours au niveau d'un em-

placement particulier.

Bien que la procédure de normalisation ait été décrite en référence à des opérations de lecture,

celle-ci est aussi utilisée lors d'opérations d'écriture.

Lorsqu'une écriture est effectuée sur un dispositif HID, un client demandeur fournit des reports, possédant chacun une taille uniforme, en association avec des éléments de données qui sont à écrire sur le dispositif HID. Avant que le gestionnaire de classe n'écrive sur le dispositif, celui-ci supprime la longueur supplémentaire d'un report normalisé et élimine l'identificateur de report si le

dispositif ne souhaite pas recevoir un tel identifica-

teur. A nouveau, ceci permet aux programmes-client d'uti-

liser des reports et des tampons correspondants dont la

taille est uniforme.

Le système de la figure 2 comporte un composant analyseur 130 qui fournit des services d'analyse à des programmes-clients. L'analyseur 130 est implémenté par

une bibliothèque chargeable dynamiquement ou "DLL".

L'analyseur et ses fonctions associées sont définis et implémentés par des instructions qui résident dans une

mémoire d'ordinateur, et qui sont exécutées par le pro-

cesseur de l'ordinateur.

La figure 4 représente un programme-client 102 et un analyseur 130. L'analyseur 130 définit et met à disposition une pluralité de fonctions d'interfaçage que

peut appeler, via des moyens classiques, le pro-

gramme-client 102. De telles fonctions sont illustrées sur la figure 4 par des cercles, reliés par des traits au

bloc analyseur 130. Les fonctions comprennent une fonc-

tion d'analyse de descripteur 132, une ou plusieurs fonc-

tions de récupération d'éléments 133, et une fonction d'identification de collection 134. Les fonctions sont implémentées en utilisant des techniques de programmation standards, tel qu'en programmant les fonctions dans un

langage compilé de haut niveau tel que le C. Chaque fonc-

tion accepte un ou plusieurs arguments, et retourne une ou plusieurs valeurs ou éléments de données au programme

appelant. La figure 4 représente les arguments se rappor-

tant le plus à la présente invention.

La fonction d'analyse de descripteur 132 reçoit des arguments de fonction qui incluent un descripteur de reports HID réel, obtenu à partir du gestionnaire de classe HID 106. En réponse à l'appel effectué avec cet

argument, la fonction d'analyse de descripteur 132 ana-

lyse le descripteur de reports, et crée une structure de

données contenant une description de reports analysée. La

structure de données est renvoyée au programme-client,

d'une manière préférée en passant un pointeur à la struc-

ture de données.

D'une manière générale, la structure de données

est une version étendue du descripteur de reports brut.

La structure de données se présente généralement sous la

forme d'une combinaison de descriptions d'éléments de

données, correspondant à des commandes du type bouton, à

des commandes du type valeur, ou à des éléments de don-

nées combinés individuels. La description d'élément de

données correspondant à un élément de données particulier indique dans quel report se trouve l'élément de données,

sa position et sa taille dans le report, et ses caracté-

ristiques HID (y compris min/max physique, min/max logi-

que, unités, etc.). D'autres informations, dans une des-

cription d'élément de données, incluent l'usage (page et

index) de l'élément de données correspondant, s'il cor-

respond à un bouton ou à une valeur, s'il est reporté comme étant un élément de données individuel, un champ de bits, ou une partie d'une combinaison, si l'élément fait partie d'une collection et, si c'est le cas, de quelle collection, etc.

La description de reports analysée indique aus-

si la longueur maximale des reports générés par un dispo-

sitif particulier, et indique si des identificateurs de report doivent être ajoutés aux reports respectifs. Cette information est utilisée par le gestionnaire de classe

HID 106 pour implémenter ses étapes de normalisation.

En bref, chaque élément de la structure de don-

nées contient une description complète d'une commande ou

d'une combinaison de commandes. Ceci contraste fortement

avec le descripteur de reports brut, dans lequel les des-

criptions des commandes reposent essentiellement sur le contexte dans lequel elles surviennent (du fait de la présence potentielle de variables globales et de comman-

des de sauvegarde/restauration d'état), nécessitant par

conséquent une analyse extensive pour extraire les des-

criptions intelligibles d'éléments de données donnés. La disposition et le protocole exacts qui sont utilisés dans

la structure de données renvoyée par la fonction d'ana-

lyse de descripteur 132 ne sont pas critiques, si ce

n'est qu'ils définissent d'une manière directe et intel-

ligible les informations nécessaires concernant les re-

ports. En outre, la structure particulière utilisée

dans la description de reports analysée n'a de significa-

tion que pour l'analyseur, lui-même. Bien que la descrip-

tion de reports soit retransmise au client demandeur par la fonction d'analyse de descripteur 132, les étapes de

récupération d'éléments selon la présente invention im-

pliquent d'autres fonctions qui sont implémentées par l'analyseur 130, dans lesquelles l'analyseur utilise les

descriptions de reports analysées. Conformément à la pré-

sente invention, le programme-client appelant n'a jamais

besoin d'utiliser les descriptions de reports analysées,

si ce n'est pour les fournir comme arguments aux fonc-

tions de récupération d'éléments. Les fonctions de récupération d'éléments 133 sont appelées par des programmes-client pour récupérer

des éléments de données correspondant à des usages spéci-

fiés. Chaque fonction de récupération d'éléments 133 re-

çoit des arguments, parmi lesquels:

* une description de reports analysée (obtenue

en utilisant la fonction d'analyse de des-

cripteur 132);

* un report HID (obtenu à partir du gestion-

naire de classe HID 106); * une spécification d'usage HID; et * un identificateur de collection optionnel, spécifiant une collection HID mentionnée dans

le descripteur de reports.

En réponse à ces arguments, une fonction de ré-

cupération d'éléments examine le report HID désigné, trouve un ou plusieurs éléments de données qui- ont les mêmes spécifications d'usage que celles fournies dans les arguments, et renvoie le ou les éléments de données au

client demandeur. La description de reports analysée est

utilisée pour localiser des éléments correspondant à la spécification d'usage donnée. Si un identificateur de collection est inclus dans les arguments, la fonction de récupération d'éléments limite les éléments de données

retournés à ceux de la collection spécifiée.

Toutes les fonctions de récupération d'éléments

sont définies de manière à recevoir des reports HID nor-

malisés. La description de reports analysée, qui est

transmise aux fonctions de récupération d'éléments, est

basée sur des reports normalisés. Chaque fonction de ré-

cupération d'éléments renvoie l'une parmi deux choses différentes: un ou des éléments de données; ou un code d'erreur indiquant si une commande avec la spécification

d'usage reçue est disponible sur le dispositif qui a gé-

néré le report désigné. D'une manière plus spécifique, le code d'erreur indique soit qu'une commande avec l'usage spécifié n'est pas disponible sur le dispositif sujet, soit que la commande est disponible sur le dispositif, mais n'est pas disponible dans le report proposé (elle

sera potentiellement disponible dans les reports sui-

vants). Les fonctions d'interfaçage mises à disposition par l'analyseur 130 incluent en outre une fonction d'identification de collection 134. Cette fonction est implémentée pour aider les programmes d'application dans le traitement de collections HID. Comme noté ci- dessus,

les identificateurs de collection sont les paramètres op-

tionnels pour les fonctions de récupération d'éléments.

Les identificateurs de collection sont obtenus via la

fonction d'identification de collection 134.

La fonction d'identification de collection 134

reçoit un argument comprenant une description de reports

analysée, obtenue précédemment en utilisant la fonction

d'analyse de descripteur 132. Sur la base de cette des-

cription, la fonction renvoie une combinaison de structu-

res de données spécifiant des collections HID, leurs usa-

ges HID, et leurs relations. L'ordre des collections dans la combinaison indique des identificateurs de collection

uniques pour chaque collection. Chaque structure de don-

nées dans la combinaison représente une collection, et

spécifie son usage, ainsi qu'un index indiquant des col-

lections associées dans la combinaison. Par exemple, la

structure de données fait référence à une collection pa-

rente (si tant est qu'il y en ait une), à un jumeau sui-

vant dans une liste chaînée de jumeaux, et à un premier enfant dans une liste chaînée d'enfants. Ceci permet à un

client de déterminer facilement la structure de collec-

tions imbriquées, et, à son tour, de glaner des signifi-

cations additionnelles, associées à des commandes diffé-

rentes - si des éléments de données dupliqués sont dispo- nibles, ceux- ci peuvent être distingués sur la base des

collections auxquelles ils appartiennent.

Ces fonctions d'identification de collection

simplifient considérablement le traitement de récupéra-

tion d'éléments de données à partir de dispositifs HID.

Un procédé de lecture de données HID selon la présente

invention comporte une étape initiale consistant à obte-

nir un descripteur de reports HID et à le soumettre à un analyseur 130 via une fonction d'analyse de descripteur

132. L'analyseur implémente une étape consistant à analy-

ser le descripteur, et retourne une description de re-

ports analysée basée sur le descripteur de reports. Ces

étapes sont implémentées durant une séquence d'initiali-

sation. Pour lire des données à partir du dispositif HID, le programme-client implémente les étapes consistant à obtenir un report HID à partir du gestionnaire de classe HID 106, et à appeler une fonction de récupération d'éléments 133 avec des arguments constitués du report

HID, de la description de reports analysée, d'une spéci-

fication d'usage, et d'un identificateur de collection

optionnel. La fonction de récupération d'éléments (implé-

mentée par l'analyseur 130) recherche dans le report HID désigné un ou plusieurs éléments de données qui ont les mêmes spécifications d'usage que celles désignées dans les arguments de la fonction, et renvoie ces éléments au

programme-client appelant. Si un identificateur de col-

lection est spécifié, la recherche est limitée à la col-

lection d'éléments de données spécifiée. Ce traitement est répété pour les reports HID qui suivent afin de lire

les données d'entrée suivantes.

L'écriture est effectuée d'une manière simi-

laire. L'analyseur inclut une ou plusieurs fonctions d'interfaçage d'écriture d'éléments qui préparent des re- ports à écrire sur des dispositifs HID. Chaque fonction d'écriture d'éléments a des arguments constitués d'un

élément de données (ou d'une pluralité d'éléments de don-

nées), d'une description de reports analysée, d'un report

HID, d'une spécification d'usage, et d'un identificateur de collection optionnel. Initialement, le report HID est

initialisé à zéro. La fonction d'écriture d'éléments dé-

termine l'emplacement approprié dans le report et posi-

tionne et formate d'une manière appropriée l'élément de

données dans le report sur la base de l'usage spécifié.

Si un identificateur de collection est spécifié, l'élé-

ment de données est positionné d'une manière appropriée pour cette collection. La fonction d'écriture d'éléments écrit aussi l'identificateur de report approprié dans le report qui correspond au report o l'usage spécifié se

trouve. La fonction renvoie alors le report au pro-

gramme-client demandeur, qui à son tour écrit le report

sur un dispositif HID via le gestionnaire de classe 106.

Si de multiples usages sont à écrire, le client peut ap-

peler la fonction d'écriture d'éléments plusieurs fois

avec le même report (en spécifiant des usages diffé-

rents), avant d'écrire le report sur le dispositif HID - aussi longtemps que tous les usages spécifiés sont dans le même report. Un code d'erreur est renvoyé si l'un des usages provient d'un report différent. De plus, un

code d'erreur est renvoyé si l'usage spécifié n'est dis-

ponible dans aucun report, ou si les contraintes de for-

mat du report HID empêchent l'écriture d'un usage spéci-

fié en plus dans le report traité.

La présente invention est une amélioration si-

gnificative par rapport à la technique antérieure. Par le passé, les programmes d'application étaient responsables du décryptage des données de report HID. Du fait que les reports de dispositifs différents différaient les uns des autres, cela représentait une tâche très difficile. Avec la présente invention, cependant, le travail nécessaire

pour supporter une multitude de dispositifs HID est for-

tement réduit. Une fois l'initialisation effectuée, un client demandeur doit spécifier un peu plus qu'un usage HID - les fonctions de récupération d'éléments analysent les reports HID et renvoient l'usage demandé sans aucun autre travail pour le client. Le client utilise le même mécanisme de récupération, peu importe que les éléments de données soient formatés dans les reports HID sous la

forme de combinaisons d'index ou de champs de bits.

Les avantages de cette fonctionnalité sont con-

sidérables. Supposons qu'un programme de jeu relativement simple n'utilise que les valeurs X et Y d'une manette de jeu. Par le passé, le jeu pouvait avoir été configuré pour être utilisé avec un seul type de manette de jeu

HID, ou pouvait avoir été conçu avec un composant d'ana-

lyse très complexe pour déterminer comment lire les va-

leurs X et Y d'une manette de jeu HID quelconque. Avec la présente invention, cependant, le jeu récupère simplement des reports et demande alors des usages de manette de jeu

X et Y à partir d'une fonction de récupération d'élé-

ments. Du point de vue du programme de jeu, les facteurs

variables suivants sont maintenant sans intérêt: le nom-

bre de reports produits par la manette de jeu; les

tailles des reports; si les reports incluent des identi-

ficateurs de report; et la disposition et le formatage des éléments de données au sein des reports. Le programme

de jeu peut ignorer tous ces facteurs, et continuera en-

core de fonctionner avec n'importe quelle manette de jeu HID comportant des usages de manette de jeu X et Y. Cela est vrai même si la manette de jeu comporte plusieurs commandes additionnelles qui ne sont pas utilisées par le programme de jeu. De nouvelles manettes de jeu, ayant des commandes additionnelles avec de nouveaux usages, conti- nueront encore de fonctionner avec le programme de jeu

(même si les nouvelles commandes ne sont pas utilisées).

En outre, la présente invention fournit une ma-

nière facile et élégante pour les programmes d'applica-

tion de faire face à de nouveaux dispositifs qui compor-

tent un moins grand nombre de commandes que celles utili-

sées d'une manière optimale par le programme. Si un tel dispositif est branché, les fonctions de récupération d'éléments renverront une valeur d'erreur en réponse à la demande d'un élément de données correspondant à un usage

qui n'existe pas dans le dispositif. Le programme d'ap-

plication peut alors implémenter, par des moyens diffé-

rents, les étapes permettant de fournir une fonctionnali-

té équivalente.

D'une manière similaire, la normalisation des reports apporte des avantages significatifs, à la fois aux programmes-client et à l'analyseur. Du fait de la normalisation des reports, les clients peuvent facilement

lire des reports individuels. De plus, une telle normali-

sation de la taille facilite la transmission de données

aux fonctions de l'analyseur. Le fait d'ajouter d'une ma-

nière consistante des identificateurs de report à des re-

ports simplifie l'indexage des éléments de données au sein des reports les données commencent toujours avec

le deuxième octet du report.

Un autre avantage de la présente invention est

que les descriptions de collection sont accessibles aux

programmes-client dans un format facilement déchiffrable.

Ceci permet aux clients d'obtenir des listes simplifiées de noeuds de collection en associant avec leurs usages

respectifs. Ceci, à son tour, permet aux clients de spé-

cifier d'une manière optionnelle des collections aux fonctions de récupération d'éléments afin de décrire

d'une manière plus spécifique les éléments de données de-

mandés. Bien que la présente invention ait été décrite

dans un langage spécifique aux caractéristiques structu-

relles et/ou aux étapes méthodologiques, il va de soi que la présente invention n'est pas nécessairement limitée

* aux caractéristiques ou aux étapes spécifiques décrites.

Au contraire, les caractéristiques et les étapes spécifi-

ques sont décrites à titre d'exemple d'implémentation de

l'invention revendiquée.

Claims (55)

REVENDICATIONS

1. Procédé de lecture d'éléments de données HID (inter-

face-utilisateur) caractérisé en ce qu'il comporte les étapes consistant à prévoir un gestionnaire de dispositifs (104) qui four-

nit des reports HID contenant des éléments de données et un des-

cripteur de reports HID décrivant les reports HID et la disposi-

tion, le formatage, ainsi que des spécifications d'usage d'élé-

ments de données au sein des reports HID,

prévoir un gestionnaire de classe HID (106) et le con-

figurer pour demander les reports HID et le descripteur de re-

ports HID à partir du gestionnaire de dispositifs et les rece-

voir, définir une première fonction d'interfaçage qui peut

être appelée par un programme-client, la première fonction d'in-

terfaçage recevant une spécification d'usage à partir du pro-

gramme-client et, en réponse, trouvant et renvoyant un ou plu-

sieurs éléments de données provenant d'un report HID spécifié qui ont les mêmes spécifications d'usage que celles reçues à

partir du programme-client.

2. Procédé selon la revendication 1, caractérisé en ce que la première fonction d'interfaçage reçoit de plus le report

HID spécifié en provenance du programme-client.

3. Procédé selon la revendication 1, caractérisé en ce que la première fonction d'interfaçage reçoit de plus le report HID spécifié, ainsi qu'une structure de données, en provenance

du programme-client, la structure de données contenant une des-

cription de reports analysée basée sur le descripteur de reports HID.

4. Procédé selon la revendication 1, caractérisé en ce

que la première fonction d'interfaçage reçoit de plus un identi-

ficateur de collection et, en réponse, limite les éléments de

données à ceux d'une collection HID spécifiée par l'identifica-

teur de collection.

5. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre l'étape consistant à définir une seconde fonction d'interfaçage qui reçoit le descripteur de reports HID et, en réponse, renvoie une structure de données contenant une

description de reports analysée, la première fonction d'interfa-

çage recevant de plus ladite structure de données et utilisant ladite structure de données pour trouver lesdits éléments de données.

6. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre l'étape consistant à définir une seconde fonction d'interfaçage qui reçoit le descripteur de reports HID en provenance du programme- client et, en réponse, renvoie une

structure de données contenant une description de reports analy-

sée, la première fonction d'interfaçage recevant de plus ladite structure de données et utilisant ladite structure de données

pour trouver lesdits éléments de données.

7. Procédé selon la revendication 1, caractérisé en ce que la première fonction d'interfaçage renvoie un code d'erreur si aucun élément de données ne possède la spécification d'usage dans le report HID spécifié, dans lequel le report HID spécifié a été généré par un dispositif particulier, et dans lequel le code d'erreur indique si une commande avec la spécification

d'usage reçue est disponible sur ledit dispositif particulier.

8. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre l'étape consistant à définir une seconde fonction d'interfaçage qui reçoit le descripteur de reports HID en provenance du programme-client et, en réponse, renvoie une

structure de données contenant une description de reports analy-

sée, la première fonction d'interfaçage recevant de plus ladite structure de données et utilisant ladite structure de données pour trouver lesdits éléments de données, et qu'en outre la première fonction d'interfaçage renvoie un code d'erreur s'il n'existe aucun élément de donnée avec la spécification d'usage reçue dans le report HID spécifié, dans lequel le report HID spécifié a été généré par un dispositif

particulier, et dans lequel le code d'erreur indique si une com-

mande avec la spécification d'usage reçue est disponible sur le-

dit dispositif particulier.

9. Procédé selon la revendication 1, caractérisé en ce que le gestionnaire de classe HID est en outre configuré pour normaliser les reports HID en provenance d'un dispositif HID

particulier en leur donnant une taille uniforme.

10. Procédé selon la revendication 1, caractérisé en ce que le gestionnaire de classe HID est en outre configuré pour

normaliser les reports HID en ajoutant un identificateur de re-

port à tout report HID qui ne possède pas déjà d'identificateur

de report et en donnant une taille uniforme aux reports HID pro-

venant d'un dispositif HID particulier.

11. Procédé selon la revendication 1, caractérisé en ce que la spécification d'usage reçue identifie une page d'usage, et dans lequel les éléments de données renvoyés comprennent une combinaison d'index d'usage correspondant à des boutons HID qui sont enfoncés, peu importe que le report HID spécifié contienne

des combinaisons d'index ou des champs de bits.

12. Procédé selon la revendication 1, caractérisé en ce que les éléments de données renvoyés comportent une pluralité de

valeurs HID.

13. Procédé selon la revendication 1, caractérisé en outre en ce qu'il comporte en outre l'étape consistant à définir une seconde fonction d'interfaçage qui renvoie une combinaison de structures de données spécifiant des collections HID, ainsi

que leurs relations, sur la base du descripteur de reports HID.

14. Procédé selon la revendication 1, caractérisé en outre en ce qu'il comporte en outre l'étape consistant à définir une seconde fonction d'interfaçage qui renvoie une combinaison de structures de données spécifiant des collections HID, ainsi

que les relations existant entre elles, sur la base du descrip-

teur de reports HID, dans lequel la première fonction d'interfa-

çage reçoit de plus un identificateur de collection et, en ré-

ponse, trouve les éléments de données dans une collection HID

spécifiée par l'identificateur de collection.

15. Procédé selon la revendication 1, caractérisé en ce que le gestionnaire de dispositifs écrit aussi des reports HID

sur des dispositifs HID, comportant en outre une seconde fonc-

tion d'interfaçage qui accepte un élément de données et une spé-

cification d'usage et, en réponse, positionne et formate l'élé- ment de données dans un report HID à écrire sur un dispositif HID.

16. Procédé de lecture d'éléments de données HID (in-

terface-utilisateur) caractérisé en ce qu'il comporte l'étape consistant à définir une première fonction d'interfaçage dans un système informatique comportant un dispositif HID qui fournit

des reports HID contenant des éléments de données et un descrip-

teur de reports HID décrivant les reports HID et la disposition, le formatage, ainsi que des spécifications d'usage d'éléments de

données au sein des reports HID, la première fonction d'interfa-

çage recevant un report HID et une spécification d'usage en pro-

venance d'un programme-client et, en réponse, trouvant et ren-

voyant un ou plusieurs éléments de données à partir du report HID qui ont les mêmes spécifications d'usage que celles reçues à

partir du programme-client.

17. Procédé selon la revendication 16, caractérisé en ce que la première fonction d'interfaçage reçoit de plus une

description de reports analysée sur la base du descripteur de

reports HID provenant du programme-client.

18. Procédé selon la revendication 16, caractérisé en ce que la première fonction d'interfaçage reçoit de plus un identificateur de collection et, en réponse, limite les éléments de données renvoyés à ceux d'une collection HID spécifiée par

l'identificateur de collection.

19. Procédé selon la revendication 16, caractérisé en

ce qu'il comporte en outre l'étape consistant à définir une se-

conde fonction d'interfaçage qui reçoit le descripteur de re-

ports HID et, en réponse, renvoie une description de reports

analysée, la première fonction d'interfaçage recevant de plus

ladite description de reports analysée et utilisant ladite des-

cription de reports analysée pour trouver lesdits éléments de données.

20. Procédé selon la revendication 16, caractérisé en

ce que la première fonction d'interfaçage renvoie un code d'er-

reur s'il n'existe aucun élément de données avec la spécifica-

tion d'usage reçue dans le report HID reçu, dans lequel le re-

port HID spécifié a été généré par un dispositif particulier, et dans lequel le code d'erreur indique si une commande avec la spécification d'usage reçue est disponible sur ledit dispositif

particulier.

21. Procédé selon la revendication 16, caractérisé en

ce qu'il comporte en outre l'étape consistant à définir une se-

conde fonction d'interfaçage qui reçoit le descripteur de re-

ports HID et, en réponse, renvoie une structure de données con-

tenant une description de reports analysée, la première fonction

d'interfaçage recevant de plus ladite structure de données et

utilisant ladite structure de données pour trouver lesdits élé-

ments de données, et qu'en outre la première fonction d'interfaçage renvoie un code d'erreur s'il n'existe aucun élément de données avec la spécification d'usage reçue dans un report HID spécifié, dans lequel le report HID spécifié a été généré par un dispositif

particulier, et dans lequel le code d'erreur indique si une com-

mande avec la spécification d'usage revue est disponible sur le-

dit dispositif particulier.

22. Procédé selon la revendication 16, caractérisé en ce que la spécification d'usage reçue identifie une page

d'usage, et dans lequel les éléments de données renvoyés com-

prennent une combinaison d'index d'usage correspondant à des

boutons HID qui sont enfoncés, peu importe que le report HID re-

çu contienne des combinaisons d'index ou des champs de bits.

23. Procédé selon la revendication 16, caractérisé en ce que les éléments de données renvoyés incluent une pluralité

de valeurs HID.

24. Procédé selon la revendication 16, caractérisé en

ce qu'il comporte en outre l'étape consistant à définir une se-

conde fonction d'interfaçage qui renvoie une combinaison de

structures de données spécifiant des collections HID et les re-

lations existant entre elles sur la base d'un descripteur de re-

ports HID.

25. Procédé selon la revendication 16, caractérisé en

ce qu'il comporte en outre l'étape consistant à définir une se-

conde fonction d'interfaçage qui renvoie une combinaison de

structures de données spécifiant des collections HID et les re-

lations existant entre elles sur la base d'un descripteur de re-

ports HID, dans lequel la première fonction d'interfaçage reçoit de plus un identificateur de collection et, en réponse, limite les éléments de données renvoyés à ceux d'une collection HID

spécifiée par l'identificateur de collection.

26. Procédé selon la revendication 16, caractérisé en

ce qu'il comporte en outre l'étape consistant à définir une se-

conde fonction d'interfaçage qui accepte un élément de données

et une spécification d'usage et, en réponse, positionne et for-

mate l'élément de données dans un report HID à écrire sur un

dispositif HID.

27. Procédé de lecture d'éléments de données HID (in-

terface-utilisateur), caractérisé en ce qu'il comporte les éta-

pes consistant à:

obtenir un descripteur de reports HID décrivant des re-

ports HID associés et la disposition, le formatage, ainsi que des spécifications d'usage d'éléments de données au sein de tels reports HID, soumettre le descripteur de reports HID à un analyseur (130) via une interface,

l'analyseur implémentant une étape consistant à analy-

ser le descripteur de reports HID et à renvoyer une description

de reports analysée sur la base du descripteur de reports HID, obtenir un report HID contenant des éléments de données décrits par le descripteur de reports HID, appeler une première fonction d'interfaçage avec des

arguments comprenant le report HID, la description de reports

analysée, et une spécification d'usage,

la première fonction d'interfaçage trouvant et ren-

voyant un ou plusieurs éléments de données du report HID qui ont les mêmes spécifications d'usage que celles spécifiées dans les

arguments à la première fonction d'interfaçage.

28. Procédé selon la revendication 27, caractérisé en

ce que la première fonction d'interfaçage renvoie un code d'er-

reur si elle ne peut trouver ledit ou lesdits plusieurs éléments de données dans le report HID, le code d'erreur indiquant si une commande avec la spécification d'usage est disponible dans un

report décrit par le descripteur de reports HID.

29. Procédé selon la revendication 27, caractérisé en ce qu'il comporte en outre une étape consistant à normaliser les reports HID en provenance d'un dispositif HID particulier en

leur donnant une taille uniforme.

30. Procédé selon la revendication 27, caractérisé en ce qu'il comporte en outre une étape consistant à normaliser les

reports HID en ajoutant un identificateur de report à tout re-

port HID qui ne possède pas déjà d'identificateur de report et en donnant une taille uniforme aux reports HID provenant d'un

dispositif HID particulier.

31. Procédé selon la revendication 27, caractérisé en

ce que les arguments transmis à la première fonction d'interfa-

çage comprennent un identificateur de collection, le procédé comportant une autre étape consistant à limiter les éléments de données renvoyés à ceux d'une collection HID spécifiée par

l'identificateur de collection.

32. Procédé selon la revendication 27, caractérisé en ce qu'il consiste en outre à:

appeler une seconde fonction d'interfaçage avec un ar-

gument comprenant la description de reports analysée,

la seconde fonction d'interfaçage renvoyant une combi-

naison de structures de données spécifiant des collections HID et les relations existant entre elles, les arguments de la première fonction d'interfaçage comprenant en outre un identificateur de collection,

la première fonction d'interfaçage limitant les élé-

ments de données renvoyés à ceux d'une collection HID spécifiée

par l'identificateur de collection.

33. Procédé selon la revendication 27, caractérisé en ce que la spécification d'usage est une page d'usage, et dans lequel les éléments de données renvoyés incluent une pluralité

de valeurs HID.

34. Procédé selon la revendication 27, caractérisé en ce que la spécification d'usage est une page d'usage, et dans

lequel les éléments de données renvoyés comprennent une combi-

naison d'index d'usage correspondant à des boutons HID qui sont

enfoncés, peu importe que le report HID contienne des combinai-

sons d'index ou des champs de bits.

35. Procédé de lecture d'éléments de données HID (in-

terface-utilisateur) caractérisé en ce qu'il comporte l'étape consistant à définir un ensemble de fonctions d'interfaçage qui peuvent être appelées dans un système informatique comportant un

dispositif HID qui fournit des reports HID contenant des élé-

ments de données et un descripteur de reports HID décrivant les

reports HID et la disposition, le formatage, ainsi que des spé-

cifications d'usage d'éléments de données au sein des reports

HID, l'ensemble de fonctions d'interfaçage définies par les ins-

tructions comportant: une fonction d'analyse de descripteur (132) qui reçoit un argument de fonction comportant un descripteur de reports HID et, en réponse, analyse le descripteur de reports HID et renvoie

une description de reports analysée basée sur le descripteur de

reports HID, une ou plusieurs fonctions de récupération d'éléments

(133) qui reçoivent des arguments de fonctions comprenant un re-

port HID, la description de reports analysée, et une spécifica-

tion d'usage, ladite ou lesdites plusieurs fonctions de récupé-

ration d'éléments trouvant et renvoyant un ou plusieurs éléments

de donnée à partir du report HID qui ont les mêmes spécifica-

tions d'usage que celles fournies dans les arguments aux fonc-

tions de récupération d'éléments.

36. Procédé selon la revendication 35, caractérisé en ce que les fonctions de récupération d'éléments comprennent une fonction de récupération de boutons, la spécification d'usage

incluant une page d'usage, dans lequel la fonction de récupéra-

tion de boutons renvoie une combinaison d'index d'usage corres- pondant à des boutons HID qui sont enfoncés, peu importe que le report HID contienne des combinaisons d'index ou des champs de bits.

37. Procédé selon la revendication 35, caractérisé en ce que les fonctions de récupération d'éléments comprennent une fonction de récupération de valeurs, la spécification d'usage incluant une page d'usage et un index d'usage, dans lequel la

fonction de récupération de valeurs renvoie une valeur HID cor-

respondant à la spécification d'usage.

38. Procédé selon la revendication 35, caractérisé en

ce que la fonction de récupération d'éléments renvoie une combi-

naison de valeurs HID correspondant à la spécification d'usage.

39. Procédé selon la revendication 35, caractérisé en ce que les fonctions de récupération d'éléments comprennent: une fonction de récupération de boutons qui renvoie une combinaison d'index d'usage correspondant à des boutons HID qui

sont enfoncés, peu importe que le report HID contienne des com-

binaisons d'index ou des champs de bits, une fonction de récupération de valeurs qui renvoie une

ou plusieurs valeurs HID.

40. Procédé selon la revendication 35, caractérisé en ce que l'ensemble de fonctions d'interfaçage définit en outre

une fonction d'identification de collection qui reçoit des argu-

ments de fonction comprenant la description de reports analysée

et, en réponse, renvoie une combinaison de structures de données spécifiant des collections HID et les relations existant entre elles.

41. Procédé selon la revendication 35, caractérisé en ce que l'ensemble de fonctions d'interfaçage définit en outre

une fonction d'identification de collection qui reçoit des argu-

ments de fonction comprenant la description de reports analysée

et, en réponse, renvoie une combinaison de structures de données spécifiant des collections HID et les relations existant entre elles, dans lequel: les arguments reçus par les fonctions de récupération d'éléments incluent un identificateur de collection optionnel, les fonctions de récupération d'éléments limitent les

éléments de données renvoyés à ceux d'une collection HID spéci-

fiée par l'identificateur de collection lorsqu'un tel identifi-

cateur de collection est fourni.

42. Procédé selon la revendication 35, caractérisé en ce que l'ensemble de fonctions d'interfaçage définit en outre une ou plusieurs fonctions d'écriture d'éléments qui reçoivent des arguments de fonction comprenant un ou plusieurs éléments de

données et une spécification d'usage, ladite ou lesdites plu-

sieurs fonctions d'écriture d'éléments positionnant et formatant lesdits éléments de données dans un report HID à écrire sur un

dispositif HID.

43. Procédé selon la revendication 35, caractérisé en ce que les fonctions de récupération d'éléments sont définies pour recevoir des reports HID qui sont normalisés en termes de taille.

44. Procédé pour renvoyer des reports HID (inter-

face/utilisateur) à des programmes-client demandeurs dans un gestionnaire de classe HID qui reçoit des reports HID de tailles différentes en provenance de un ou plusieurs dispositifs HID, caractérisé en ce qu'il comporte les étapes consistant à: recevoir des reports HID en provenance d'un dispositif HID, normaliser les reports HID provenant du dispositif HID en leur donnant une taille uniforme,

renvoyer les reports HID normalisés aux program-

mes-client demandeurs.

45. Procédé selon la revendication 44, caractérisé en ce que la taille uniforme est au moins aussi grande que celle du

report HID le plus grand, généré par ledit dispositif HID.

46. Procédé selon la revendication 44, caractérisé en

ce que l'étape de normalisation comporte l'ajout d'un identifi-

cateur de report à tout report HID qui ne possède pas déjà un

identificateur de report.

47. Procédé selon la revendication 44, caractérisé en ce que

l'étape de normalisation comporte l'ajout d'un identi-

ficateur de report à tout report HID qui ne possède pas déjà un identificateur de report, la taille uniforme est la taille du report HID le plus

grand, généré par ledit dispositif HID, incluant tout identifi-

cateur de report ajouté.

48. Procédé selon la revendication 44, caractérisé en ce qu'il met en oeuvre: un gestionnaire HID (104) qui fournit des reports HID de tailles différentes à partir de un ou plusieurs dispositifs

HID (100),

un gestionnaire de classe HID (106) configuré pour de-

mander et recevoir les reports HID en provenance du gestionnaire HID et pour renvoyer les reports HID en réponse à des demandes émanant de programmes-client, le gestionnaire de classe HID normalisant les reports HID d'un dispositif HID particulier en leur donnant une taille uniforme.

49. Procédé selon la revendication 48, caractérisé en ce que la taille uniforme est au moins aussi grande que celle du

report HID le plus grand, généré par ledit dispositif HID parti-

culier.

50. Procédé selon la revendication 48, caractérisé en ce que la normalisation inclut l'ajout d'un identificateur de

report à tout report HID qui ne possède pas déjà un identifica-

teur de report.

51. Procédé selon la revendication 48, caractérisé en ce que: la normalisation inclut l'ajout d'un identificateur de

report à tout report HID qui ne possède pas déjà un identifica-

teur de report, la taille uniforme est la taille du report HID le plus grand, généré par ledit dispositif HID particulier, incluant

tout identificateur de report ajouté.

52. Procédé selon la revendication 44, caractérisé en ce qu'il comporte les étapes consistant à:

recevoir des reports HID en provenance de un ou plu-

sieurs dispositifs HID, ajouter un identificateur de report à tout report HID qui ne possède pas déjà un identificateur de report,

normaliser les reports HID d'un dispositif HID particu-

lier en leur donnant une taille uniforme,

renvoyer les reports HID normalisés aux program-

mes-client demandeurs.

53. Procédé selon la revendication 52, caractérisé en ce que la taille uniforme est au moins aussi grande que la taille du report HID le plus grand, généré par ledit dispositif

HID particulier.

54. Procédé selon la revendication 52, caractérisé en

ce que l'étape de normalisation comprend l'ajout d'un identifi-

cateur de report à tout report HID qui ne possède pas déjà un

*identificateur de report.

55. Procédé selon la revendication 52, caractérisé en ce que:

l'étape de normalisation comprend l'ajout d'un identi-

ficateur de report à tout report HID qui ne possède pas déjà un identificateur de report, la taille uniforme est la taille du report HID le plus grand, généré par ledit dispositif HID particulier, incluant

tout identificateur de report ajouté.