Partager via

Architecture de la pile de pilotes USB à double rôle.

  • Article

Les contrôleurs USB à double rôle sont désormais pris en charge dans Windows, à partir de Windows 10 pour les éditions de bureau (Home, Pro, Enterprise et Education) et Windows 10 Mobile.

Introduction

La fonctionnalité USB double rôle permet à un système d'être soit un appareil USB, soit un hôte USB. La spécification détaillée du double rôle USB est disponible sur la page d'information USB on the Go de l'USB-IF.

La fonctionnalité de double rôle permet à un appareil mobile, tel qu'un téléphone ou une tablette, de se désigner lui-même comme étant un appareil ou un hôte.

Lorsqu'un appareil mobile est en mode fonction, il est connecté à un PC ou à un autre appareil qui fait office d'hôte pour l'appareil mobile connecté.

Lorsqu'un appareil mobile est en mode hôte, les utilisateurs peuvent y attacher leur appareil, comme une souris ou un clavier. Dans ce cas, l'appareil mobile héberge les appareils connectés.

La prise en charge du double rôle de l'USB dans Windows 10 offre les avantages suivants :

  • La connectivité aux appareils périphériques mobiles via USB, qui offre une plus grande bande passante de données par rapport aux protocoles sans fil comme Bluetooth.
  • La possibilité de charger la batterie via USB tout en étant connecté à d'autres appareils USB et en communiquant avec eux (dans la mesure où la prise en charge matérielle requise est présente).
  • Permettre aux clients qui possèdent très probablement un appareil mobile, tel qu'un téléphone intelligent, de travailler. Cette fonctionnalité permet d'améliorer la productivité dans un scénario de station d'accueil filaire, où un appareil mobile s'arrime et héberge donc des appareils périphériques.

Le tableau suivant présente la liste des pilotes de classe d'hôte disponibles sur les éditions de bureau et mobile de Windows.

Pilotes de classe d'hôte USB Windows 10 Mobile Windows 10 pour les éditions de bureau
Hubs USB (USBHUB) Oui Oui (depuis Windows 2000)
HID - Clavier/Souris (HidClass, KBDCLass, MouClass, KBDHid, MouHid) Oui Oui (depuis Windows 2000)
Mémoire de masse USB (Bulk & UASP) Oui Oui (depuis Windows 2000)
Pilote d'hôte USB générique (WinUSB) Oui Oui (depuis Windows Vista)
Entrée/sortie audio USB (USBAUDIO) Oui Oui (Depuis Windows XP)
Appareils série (USBSER) Oui Oui (Depuis Windows 10)
Bluetooth (BTHUSB) Oui Oui (Depuis Windows XP)
Impression (usbprint) Non Oui (Depuis Windows XP)
Analyser (USBSCAN) Non Oui (depuis Windows 2000)
WebCam (USBVIDEO) Non Oui (depuis Windows Vista)
Protocole de transfert de média (MTP Initiator) Non Oui (depuis Windows Vista)
NDIS distant (RNDIS) Non Oui (Depuis Windows XP)
IP sur USB (IPoverUSB) Non Oui (nouveau pour Windows 10)

Les pilotes de classe figurant dans le tableau ont été sélectionnés sur la base de la télémétrie des classes d'appareils et en fonction des principaux scénarios retenus pour Windows 10. Nous prévoyons d'inclure un nombre limité de pilotes de boîte de réception, de pilotes d'hôte tiers, pour prendre en charge les appareils clés sur Windows 10 Mobile. Et pour Windows 10 pour les éditions de bureau, ces pilotes sont disponibles soit sur le site web de l'OEM, soit via Windows Update (Windows Update).

Pour Windows 10 Mobile, les pilotes tiers qui ne sont pas inclus dans la boîte de réception ne sont pas disponibles sur Window Update. L'empreinte disque de la pile USB Host + HID est réduite. C'est pourquoi tous les pilotes de classe et peu de pilotes tiers sont inclus dans la boîte de réception pour Windows 10 Mobile. Un OEM qui souhaite mettre à disposition des pilotes tiers peut utiliser un Board Support Package (BSP) pour les ajouter aux images du système d'exploitation pour leurs appareils mobiles.

Le tableau suivant présente les pilotes de classe de fonction disponibles sur les éditions mobiles de Windows.

Remarque

Les pilotes de fonction ne sont pas disponibles sur Windows 10 pour les éditions de bureau.

Pilotes de classe de fonction USB Windows 10 Mobile Windows 10 pour les éditions de bureau Notes
Répondant au protocole de transfert de média (MTP) Oui Non Il n'y a pas de scénarios pour le répondeur MTP sur l'ordinateur de bureau. Les scénarios P2P entre les systèmes de bureau ont été activés via Easy-MigCable sur WinUSB.
Sortie d'affichage vidéo (vidstream) Oui Non
Pilote de fonction USB générique (GenericUSBFn) Oui Non IPoverUSB et d'autres scénarios de flashage du bureau ont besoin de ce pilote.

Nous surveillons les données relatives à l'attachement des appareils pour savoir si nous devons fournir davantage de pilotes de classe au fur et à mesure que la liste de popularité des classes d'appareils se met à jour.

Mise en œuvre du pilote

Le pilote Microsoft USB Role Switch (URS) permet à l'utilisateur d'un système de tirer parti de la capacité USB à double rôle de sa plate-forme.

Le pilote URS est destiné à fournir une fonctionnalité à double rôle pour les plates-formes qui utilisent un contrôleur USB unique pouvant fonctionner à la fois en tant qu'hôte et en tant que périphérique sur un seul port. Le rôle périphérique est également connu sous le nom de rôle fonctionnel. Le pilote URS gère le rôle actuel du port. Le pilote URS charge et décharge les piles logicielles appropriées, en fonction des événements matériels de la plateforme.

Sur un système doté d'un connecteur USB micro-AB, le pilote utilise des interruptions matérielles qui indiquent l'état de la broche ID sur le connecteur. Cette broche est utilisée pour détecter si le contrôleur doit assumer le rôle d'hôte ou de fonction dans une connexion. Pour plus d'informations, consultez la spécification USB On-The-Go. Sur les systèmes dotés d'un connecteur USB de type C, l'équipementier est censé fournir un pilote client de connecteur en utilisant les interfaces de programmation de pilote de connecteur USB de type C. Le pilote client communique avec l'extension de classe USB connector Manager (UcmCx) fournie par Microsoft pour gérer tous les aspects du connecteur USB Type-C, tels que la détection CC, la messagerie PD, et autres. Pour le changement de rôle, le pilote client communique l'état du connecteur USB Type-C au pilote URS.

Le diagramme suivant présente la pile de pilotes logiciels USB pour un contrôleur à double rôle qui utilise le pilote URS.

Architecture de la pile de pilotes usb à double rôle.

Le pilote URS ne charge jamais simultanément les piles Fonction et Hôte présentées dans le diagramme précédent. Le pilote URS charge soit la pile Fonction, soit la pile Hôte, en fonction du rôle du contrôleur USB.

Configuration matérielle requise

Si vous développez une plate-forme qui tire parti du pilote URS pour fournir une fonctionnalité USB à double rôle, les conditions matérielles suivantes doivent être remplies :

  • Contrôleur USB

    Ces pilotes sont fournis par Microsoft en tant que pilotes intégrés.

    Contrôleur Synopsys DesignWare Core USB 3.0. Inbox INF : UrsSynopsys.inf.

    Chipidea High-Speed USB OTG Controller. Inbox INF : UrsChipidea.inf.

  • Interruptions des broches ID

    • Une ou plusieurs interruptions de broche ID pour les systèmes non-USB Type-C sont mises en œuvre de l'une des deux manières suivantes :

      1. Deux interruptions déclenchées par les fronts : une qui se déclenche lorsque la broche ID du connecteur est mise à la terre, et une autre qui se déclenche lorsque la broche ID est flottante.
      2. Une seule interruption active à deux niveaux qui est au niveau actif lorsque la broche ID est mise à la terre.

  • Enumération du contrôleur USB

    Le contrôleur USB à double rôle doit être énuméré par l'ACPI.

  • Support logiciel

    Le pilote URS attend une interface logicielle permettant de contrôler le VBus sur le connecteur. Cette interface est spécifique au SoC. Contactez votre fournisseur de SoC pour plus de détails.

Ces fonctionnalités USB OTG ne sont pas prises en charge par Windows :

  • Détection de l'adaptateur de chargeur d'accessoires (ACA).
  • Protocole de requête de session (SRP).
  • Protocole de négociation avec l'hôte (HNP).
  • Protocole de détection d'attachement (ADP).

Configuration du système ACPI

Pour utiliser le pilote URS, vous devez créer un fichier de définition ACPI pour votre système. En outre, vous devez tenir compte de certaines considérations liées au pilote.

Voici un exemple de définition ACPI pour un contrôleur USB à double rôle.

//
// You may name the device whatever you want; we don't depend on it being called 'URS0'.
//
Device(URS0)
{
    //
    // Replace with your own hardware ID. Microsoft will add it to the inbox INF,
    // or you may choose to author a custom INF that uses Needs & Includes directives
    // to include sections from the inbox INF.
    //
    Name(_HID, "ABCD1234")

    Name(_CRS, ResourceTemplate() {
        //
        // The register space for the controller must be defined here.
        //
        Memory32Fixed(ReadWrite, 0xf1000000, 0xfffff)


        //
        // The ID pin interrupts, if you are using two edge-triggered interrupts.
        //
        GpioInt(Edge, ActiveHigh, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x1001}
        GpioInt(Edge, ActiveHigh, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x1002}

        //
        // Following is an example of a single active-both interrupt.
        //
        // GpioInt(Edge, ActiveBoth, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x12}
        //

        //
        // For a Type-C platform, you do not need to specify any interrupts here.
        //
    })

    //
    // This child device represents the USB host controller. This device node is in effect
    // when the controller is in host mode.
    // You may name the device whatever you want; we don't depend on it being called 'USB0'.
    //
    Device(USB0)
    {
        //
        // The host controller device node needs to have an address of '0'
        //
        Name(_ADR, 0)
        Name(_CRS, ResourceTemplate() {

            //
            // The controller interrupt.
            //
            Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive, , , ){0x10}
        })
    }

    //
    // This child device represents the USB function controller. This device node is in effect
    // when the controller is in device/function/peripheral mode.
    // You may name the device whatever you want; we don't depend on it being called 'UFN0'.
    //
    Device(UFN0)
    {
        //
        // The function controller device node needs to have an address of '1'
        //
        Name(_ADR, 1)
        Name(_CRS, ResourceTemplate() {

            //
            // The controller interrupt (this could be the same as the one defined in
            // the host controller).
            //
            Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive, , , ){0x11}
        })
    }
}

Voici quelques explications sur les principales sections du fichier ACPI :

  • URS0 est la définition ACPI du contrôleur USB à double rôle. Le pilote URS se charge sur cet appareil ACPI.

  • USB0 et UFN0 sont des appareils enfants à l'intérieur de la portée de URS0. USB0 et UFN0 représentent les deux piles enfant énumérées par le pilote URS, et respectivement les piles hôte et fonction. _ADR est le moyen par lequel l'ACPI fait correspondre ces définitions d'appareil avec les objets d'appareil que le pilote URS crée.

  • Si le contrôleur utilise la même interruption pour les deux rôles, la même interruption du contrôleur peut être décrite dans les deux appareils enfants. Même dans ce cas, l'interruption peut toujours être décrite comme « Exclusive ».

  • Vous pouvez ajouter des éléments à ce fichier de définition ACPI si nécessaire. Par exemple, vous pouvez définir d'autres méthodes ou propriétés nécessaires sur n'importe quel appareil dans le fichier de définition ACPI. Ces ajouts n'interfèrent pas avec le fonctionnement du pilote URS. Toute autre ressource requise dans l'une des piles peut également être décrite dans le _CRS de l'appareil approprié.

Le pilote URS attribue des ID matériels aux piles hôte et fonction. Ces ID matériels sont dérivés de l'ID matériel de l'appareil URS. Par exemple, si vous avez un appareil URS dont l'ID matériel est ACPI\ABCD1234, le pilote URS crée des ID matériels pour les piles hôte et fonction comme suit :

  • Pile hôte : URS\ABCD1234&HOST

  • Pile de fonctions : URS\ABCD1234&FUNCTION

Paquets d'installation de pilotes INF

Les packages de pilotes de tierce partie peuvent prendre une dépendance sur ce schéma, si nécessaire.

Si vous êtes un IHV ou un OEM et que vous envisagez de fournir votre propre package de pilotes, voici quelques éléments à prendre en compte :

  • Package de pilotes URS

    L'ID matériel du contrôleur à double rôle de chaque plateforme est ajouté à l'INF de la boîte de réception pour l'URS. Toutefois, si, pour une raison quelconque, l'ID ne peut pas être ajouté, l'IHV/OEM peut fournir un package de pilotes avec un INF qui nécessite/inclut l'INF de la boîte de réception et qui correspond à son ID matériel.

    Ce package de pilotes est nécessaire lorsque l'OEM exige qu'un pilote de filtre soit présent dans la pile de pilotes.

  • Paquet de pilotes de l'hôte

    Un package de pilotes fourni par l'OEM qui nécessite/inclut le fichier usbxhci.inf de la boîte de réception et qui correspond à l'ID matériel de l'appareil hôte est nécessaire. La correspondance de l'ID matériel serait basée sur le schéma décrit dans la section précédente.

    Ce package de pilotes est nécessaire lorsque l'OEM exige qu'un pilote de filtre soit présent dans la pile de pilotes.

    Des travaux sont en cours pour que le pilote URS attribue l'ID compatible XHCI de l'appareil hôte.

  • Package de pilotes de fonction

    Un package de pilotes fourni par l'OEM qui nécessite/inclut l'inbox Ufxsynopsys.inf et qui correspond à l'ID matériel de l'appareil périphérique est nécessaire. La correspondance de l'ID matériel serait basée sur le schéma décrit dans la section précédente.

    L'IHV/OEM peut également inclure un pilote de filtre dans le package de pilotes.

Voir aussi