Partager via

Pilotes clients HID

  • Article

Si un minidriver HID fourni par le système ne prend pas en charge le port ou le bus d’un appareil, un minidriver fourni par un fournisseur est requis.

La figure suivante illustre une pile de pilotes pour un appareil HIDClass générique (qui peut utiliser des composants facultatifs et requis fournis par le fournisseur).

diagramme illustrant une pile de pilotes pour un appareil hidclass générique.

Windows génère la pile des pilotes comme suit :

  • La pile de transport crée un objet de périphérique physique (PDO) pour chaque périphérique HID attaché et charge le pilote de transport HID approprié, qui charge à son tour le pilote de classe HID.
  • Le pilote de classe HID crée un PDO pour le TLC . Pour les appareils complexes avec plusieurs TLC, le pilote de classe HID crée un PDO pour chaque TLC et garantit que l’ID matériel associé au TLC inclut un identificateur pour représenter chaque objet de périphérique.
  • Un pilote de fonction ou de filtre fourni par le fournisseur crée un FDO ou un do de filtre pour une collection HID.
  • Une application fournie par un fournisseur peut également ouvrir l’appareil à l’aide des API SetupDI* pour identifier l’appareil, puis hid des routines prises en charge pour communiquer avec l’appareil. Ces appareils sont dits ouverts en mode RAW.

Si les opérations minidriver fournies par le système ne prennent pas en charge un appareil, un minidriver HID fourni par le fournisseur est requis. Vous pouvez implémenter ce minidriver de deux manières :

  • Pilote client HID
  • L’application accède directement à HID

Si un fournisseur fournit un pilote (autre qu’un minidriver), ce pilote :

  • Doit respecter la configuration minimale requise sur le pilote Windows. Dans l’idéal, cela doit être basé sur l’infrastructure de pilote en mode utilisateur (UMDF) ou l’infrastructure de pilote en mode noyau (KMDF). Une solution moins idéale consiste à créer un pilote de fonction WDM, comme décrit dans Modèle de pilote Windows.
  • Prend généralement en charge une interface d’appareil définie par le fournisseur. Consultez Classes d’interface d’appareil. Les pilotes de niveau supérieur ou les applications en mode utilisateur utilisent l’interface personnalisée pour accéder aux appareils utilisés par le pilote fournisseur. L’interface personnalisée peut ajouter des fonctionnalités ou, peut-être, simplifier l’interface au pilote de classe HID.

Si le pilote n’est pas un pilote de fonction ou un pilote de filtre, il peut utiliser Plug-and-Play notification pour rechercher des regroupements HID. Après avoir trouvé une collection, le pilote ouvre la collection et l’utilise de la même manière qu’un pilote de fonction ou de filtre.

Remarque importante :

  • Si un pilote de fonction fourni par le fournisseur crée une fonction FDO ou un filtre DO pour une collection HID, il ne doit pas utiliser le champ FsContext de FILE_OBJECT pour stocker des données spécifiques à l’objet de fichier. Le champ FsContext est réservé au pilote de classe HID. Si un autre pilote de la pile doit stocker des données de contexte spécifiques à un objet de fichier, il doit utiliser le champ FsContext2 à la place.
  • S’il existe plusieurs appareils attachés à l’AOP, il n’existe aucun mécanisme intégré pour déterminer quel appareil peut utiliser le champ FsContext2.