Visão geral da enumeração de coleções de interface em dispositivos compostos USB

As interfaces em um dispositivo USB composto podem ser agrupadas em coleções. O driver pai genérico USB (Usbccgp.sys) pode enumerar conjuntos de interfaces de quatro maneiras.

Esses quatro métodos de enumeração de coleções de interface são organizados hierarquicamente da seguinte maneira:

1. Rotinas de retorno de chamada fornecidas pelo fornecedor

   Se o fornecedor tiver registrado uma rotina de retorno de chamada com o driver pai genérico USB (Usbccgp.sys), o driver pai genérico dará precedência à rotina de retorno de chamada e permitirá que a rotina de retorno de chamada agrupe interfaces em vez de usar algum outro método. Para obter mais informações sobre a enumeração da coleção de interfaces usando rotinas de retorno de chamada fornecidas pelo fornecedor, consulte Enumeração de coleções de interface em dispositivos compostos USB.

2. Descritores funcionais da União Europeia

   . Se o fornecedor tiver ativado a enumeração CDC e WMCDC no driver pai genérico USB, o driver pai genérico usará descritores funcionais de união (UFDs) para agrupar interfaces em conjuntos. Quando habilitado, esse método tem precedência sobre todos os outros métodos, exceto para rotinas de retorno de chamada fornecidas pelo fornecedor.

3. Descritores de associação de interface

   Se os descritores de associação de interface (IADs) estiverem presentes, o driver pai genérico USB sempre agrupa interfaces usando IADs em vez de usar métodos herdados. A Microsoft recomenda que os fornecedores usem IADs para definir coleções de interface.

4. Método de áudio antigo

   O driver genérico principal USB é capaz de enumerar coleções de interfaces usando técnicas legadas reservadas para funções de áudio. O driver principal genérico não usa este método se houver IADs no dispositivo.

Personalizando a enumeração de coleções de interface para dispositivos compostos

Alguns dispositivos USB têm coleções de interfaces que o descritor de associação de interface USB (IAD) não consegue descrever. No Windows Vista e em sistemas operativos posteriores, os fornecedores podem customizar a forma como o controlador genérico USB (Usbccgp.sys) define e enumera as coleções de interfaces de um dispositivo. Isso é feito por meio de uma rotina de retorno de chamada de enumeração num driver de filtro. A rotina de callback auxilia o driver pai genérico na definição de coleções de interfaces personalizadas para o dispositivo.

Para que o driver pai genérico defina coleções de interface personalizadas, o fornecedor do dispositivo composto deve:

1. Implemente a rotina de callback de enumeração (USBC_START_DEVICE_CALLBACK).
2. Forneça um ponteiro para a rotina de callback na interface de configuração do dispositivo USB (StartDeviceCallback membro do USBC_DEVICE_CONFIGURATION_INTERFACE_V1).
3. Forneça um arquivo INF que corresponda ao ID do dispositivo composto e carregue explicitamente o driver pai genérico USB e o driver de filtro.

Considerações de implementação

O driver de filtro que contém a função de callback de enumeração pode ser um driver de filtro superior ou inferior. Quando o driver pai genérico USB recebe um pedido IRP_MN_START_DEVICE para iniciar um dispositivo composto, ele consulta a interface de configuração do dispositivo USB enviando um pedido IRP_MN_QUERY_INTERFACE para o topo da pilha de drivers.

Ao receber um pedido IRP_MN_QUERY_INTERFACE, o driver de filtro deve verificar o tipo de GUID no membro InterfaceType do pedido para confirmar se a interface solicitada é do tipo USB_BUS_INTERFACE_USBC_CONFIGURATION_GUID. Se assim for, o driver de filtro devolve um ponteiro para a interface no membro Interface do IRP.

A rotina de retorno de chamada de enumeração deve retornar um ponteiro para uma matriz de descritores de função (USBC_FUNCTION_DESCRIPTOR) que descrevem as coleções de interface. Cada descritor de função contém uma matriz de descritores de interface (USB_INTERFACE_DESCRIPTOR) que descrevem a coleção de interface. A rotina de retorno de chamada deve alocar descritores de função e de interface a partir do pool não paginado. O driver pai genérico libera essa memória. A rotina de retorno de chamada deve garantir que o membro NumberOfInterfaces de cada USB_INTERFACE_DESCRIPTOR informe com precisão o número de interfaces na coleção de interfaces.

O driver pai genérico cria um objeto de dispositivo físico (DOP) para cada descritor de função.

A interface de configuração do dispositivo USB e a rotina de retorno de chamada de enumeração são resumidas em Rotinas de Driver Pai Genérico.

Mecanismo de carregamento do controlador principal genérico USB

Quando um dispositivo composto atende aos requisitos descritos em Enumeração de dispositivos compostos USB, o sistema operacional gera uma ID compatível de USB\COMPOSITE para indicar que o dispositivo é composto. O ID compatível produz uma correspondência em Usb.inf, e o sistema operativo carrega automaticamente o driver pai genérico USB, sem a ajuda de um ficheiro INF fornecido pelo fornecedor.

No entanto, esse mecanismo padrão não funciona para dispositivos compostos que exigem enumeração personalizada de coleções de interface, porque no mecanismo padrão o sistema não carrega o driver de filtro fornecido pelo fornecedor. Para que o mecanismo da rotina de callback de enumeração funcione, o driver de filtro que expõe a interface de configuração do dispositivo USB já deve estar carregado quando o pai genérico USB enumera as coleções de interfaces do dispositivo composto. Isso requer que o fornecedor do dispositivo composto instale um arquivo INF que corresponda ao ID do dispositivo composto e carregue explicitamente o driver pai genérico USB e o driver de filtro.

Suporte para a classe de dispositivo de comunicação móvel sem fio

No Windows Vista, o USB Generic Parent Driver (Usbccgp.sys) fornece suporte para dispositivos incluídos no Universal Serial Bus (USB) Communication Device Class (CDC) e no USB Wireless Mobile Communication Device Class (WMCDC).

A especificação WMCDC (Wireless Mobile Communication Device Class) estabelece um padrão para conexão, controle e troca de conteúdo entre um host e um dispositivo móvel sem fio (por exemplo, um telefone celular) quando o dispositivo está conectado a uma porta USB. WMCDC é uma extensão da classe de dispositivos de comunicação (CDC), que inclui uma ampla gama de dispositivos de comunicação e rede. Esta seção descreve a arquitetura que oferece suporte a dispositivos CDC e WMCDC em sistemas operacionais Windows.

Os dispositivos WMCDC consistem em várias funções que são agrupadas em aparelhos lógicos. A maioria dos dispositivos WMCDC tem um único aparelho lógico, mas um dispositivo pode ter vários aparelhos lógicos. Os aparelhos lógicos normalmente incluem funções como um modem de dados/fax, um armazenamento de objetos e um recurso de controle de chamadas. Um aparelho lógico também pode incluir funções de suporte definidas por outras especificações USB, como a especificação de classe de áudio USB, a especificação de classe HID (dispositivo de entrada humana USB) e a especificação de classe de vídeo USB.

A arquitetura WMCDC do Windows usa drivers nativos do Windows para gerenciar as funções do seu dispositivo WMCDC. Por exemplo, você pode usar o subsistema TAPI (interface de programa de aplicativo de telefonia) do Windows para gerenciar as funções de voz e data/fax modem do seu dispositivo e o subsistema NDIS (Network Driver Interface Specification) do Windows para gerenciar a função Ethernet LAN do dispositivo. Além disso, você pode gerenciar algumas funções, como uma função OBEX (Object Exchange Protocol), em software de modo de usuário com a assistência de WinUSB (Winusb.sys).

Esta imagem mostra um stack de controladores de exemplo para um dispositivo WMCDC.

Na figura anterior, o dispositivo WMCDC contém um único aparelho lógico: uma função OBEX e uma função de modem. Um arquivo INF fornecido pelo fornecedor carrega drivers nativos do Windows para gerenciar o modem. A função OBEX é gerenciada por um driver de modo de usuário fornecido pelo fornecedor que é executado no User-Mode Driver Framework (UMDF). O driver em modo utilizador utiliza o protocolo WPD (Windows Portable Devices) para comunicar com aplicações de utilizador e a interface que a Introdução ao WinUSB para Desenvolvedores exporta para comunicar com a pilha USB. Em geral, um arquivo INF fornecido pelo fornecedor carregará uma instância separada de Winusb.sys para cada coleção de interface que usa Winusb.sys.

Configurações do Registro

A camada USB não suporta automaticamente WMCDC. Você deve fornecer um arquivo INF que carregue uma instância de Usbccgp.sys. O arquivo INF deve conter uma seção AddReg que define o valor do Registro EnumeratorClass na chave de software associada ao Usbccgp.sys para um valor REG_BINARY construído a partir de três números: 0x02, 0x00 e 0x 00. O exemplo de código a seguir de um arquivo INF de exemplo ilustra como definir EnumeratorClass para o valor apropriado.

[CCGPDriverInstall.NT]
Include=usb.inf
Needs=Composite.Dev.NT
AddReg=CCGPDriverInstall.AddReg

[CCGPDriverInstall.NT.Services]
Include=usb.inf
Needs=Composite.Dev.NT.Services

[CCGPDriverInstall.AddReg]
HKR,,EnumeratorClass, 0x00000001,02,00,00

O valor que você deve atribuir a EnumeratorClass é construído a partir de três valores binários de 1 byte que são representados no arquivo INF por pares de dígitos hexadecimais: 02, 00 e 00. Esses três números correspondem aos valores que o USB Implementers Forum atribuiu à classe de dispositivo CDC, subclasse de dispositivo CDC e protocolo de dispositivo CDC, respectivamente.

Os tópicos a seguir descrevem melhor o WMCDC:

Enumerando coleções de interface no WMCDC

A classe de dispositivo de comunicação móvel sem fio USB (WMCDC) é uma subclasse da classe de dispositivo de comunicação USB (CDC). A especificação WMCDC estende, mas não altera substancialmente as diretrizes do CDC para definir coleções de interfaces. Em particular, os dispositivos WMCDC devem estar em conformidade com as diretrizes do CDC para definir coleções de interfaces.

As coleções de interface CDC contêm uma interface mestre (USB_INTERFACE_DESCRIPTOR) que pertence à classe de interface de comunicação (bInterfaceClass = 0x02) ou à classe de interface de dados (bInterfaceClass = 0x0A). Se a interface mestre pertencer à classe de interface de comunicação (que é a situação típica), a subclasse da interface mestre (bInterfaceSubClass) especificará um modelo de controle CDC. O modelo de controle indica o tipo de interfaces incluídas na coleção de interfaces. Para obter uma descrição dos modelos de controle que o USB Implementers Forum define, consulte a especificação CDC e a especificação WMCDC.

A interface principal de uma coleção de interfaces é seguida por um conjunto de descritores funcionais obrigatórios específicos da classe, incluindo um descritor funcional de união (UFD). O UFD lista os números das interfaces que pertencem à coleção. O campo bMasterInterface do UFD contém o número da interface mestre. Zero ou mais campos bSubordinateInterface contêm os números das outras interfaces (subordinadas) da coleção.

Para a maioria dos tipos de modelos de controle, o USB Generic Parent Driver (Usbccgp.sys) cria um objeto de dispositivo físico (DOP) para cada UFD. Mas alguns modelos de controle incluem uma interface de áudio que o driver pai genérico enumera separadamente da coleção de interface à qual a interface de áudio pertence. A interface de áudio aparece na lista de interfaces subordinadas (bSubordinateInterface) no UFD da coleção de interfaces, mas o driver pai genérico cria um PDO separado para a interface de áudio. Tanto o PDO para a interface de áudio quanto o PDO para a coleção de interfaces à qual a interface de áudio pertence estão diretamente acima do objeto de dispositivo funcional (FDO) do dispositivo composto pai na árvore de objetos do dispositivo. O PDO da interface de áudio não é um elemento filho da coleção de interfaces.

Há dois modelos de controle cujas características de enumeração são configuráveis no registro: o modelo de controle de aparelho sem fio (WHCM), que define um aparelho lógico, e o modelo de controle OBEX (Object Exchange Protocol). Para configurar as características de enumeração desses dois modelos de controle, você deve fornecer um arquivo INF que carrega uma instância de Usbccgp.sys e define o valor de CdcFlags na chave de software para essa instância de Usbccgp.sys. A tabela a seguir descreve as opções de configuração de CdcFlags.

Por exemplo, para limpar ambos os bits (defina-os como 0), seu arquivo INF deve ter a seguinte linha em uma seção DDInstall.AddReg .

HKR, , CdcFlags, 0x00010001, 0x00000000

Para definir ambos os bits como 1, o arquivo INF deve ter a seguinte linha.

HKR, , CdcFlags, 0x00010001, 0x00000011

Para definir o bit 0 para 1 e o bit 1 para 0, o arquivo INF deve ter a seguinte linha.

HKR, , CdcFlags, 0x00010001, 0x00000001

Qualquer bit pode ser definido ou redefinido, independentemente do outro bit.

As figuras a seguir ilustram como diferentes configurações de registro podem criar árvores de dispositivos diferentes para o mesmo dispositivo.

A figura a seguir ilustra a configuração do PDO quando o bit 0 e o bit 1 do CdcFlags são 0.

A coleção de interface do modelo de controle de aparelho sem fio (WHCM) na figura anterior contém três coleções de interface subordinadas (bSubordinateInterface): duas coleções OBEX e uma coleção de modem. O bit 0 do CdcFlags é 0, portanto, o driver pai genérico USB não cria um PDO para a coleção de interface WHCM. O Bit 1 do CdcFlags é 0, portanto, o driver pai genérico USB gera um PDO separado para cada coleção de interface OBEX.

A figura a seguir ilustra a configuração do PDO quando os bits 0 e 1 de CdcFlags são definidos.

Uma vez que o bit 0 do CdcFlags está definido como 1, o driver pai genérico USB cria um PDO para a coleção de interfaces WHCM. Como o bit 1 de CdcFlags está definido para 1, o driver pai genérico USB agrupa as duas coleções OBEX e gera um único PDO para ambas as coleções OBEX.

Você pode querer representar colecções OBEX com um único PDO ao nível do kernel e distinguir entre cada colecção OBEX individual dentro de um driver de modo utilizador. O protocolo Windows Portable Devices (WPD) pode ajudá-lo a multiplexar fluxos de dados entre diferentes funções OBEX no nível do usuário, quando todas as funções OBEX são agrupadas em um único DOP no nível do kernel.

O seguinte arquivo INF de exemplo carrega o driver pai genérico USB para gerenciar um dispositivo WMCDC e instrui o pai genérico USB a criar PDOs para dispositivos lógicos e a criar um único PDO para todas as coleções OBEX no dispositivo lógico.

[Version]
Signature="$Windows NT$"
Class=USB
ClassGUID={36FC9E60-C465-11CF-8056-444553540000}
Provider=%MSFT%
DriverVer=07/01/2001,5.1.2600.0
CatalogFile=ExampleCatalog.cat
PnpLockdown=1

[ControlFlags]
ExcludeFromSelect=*

[Manufacturer]
CompanyName=CompanyName,NTamd64

[CompanyName.NTamd64]
%COMPANYNAME.DeviceDesc%=CCGPDriverInstall,USB\Vid_????&Pid_????

[CCGPDriverInstall.NT]
Include=usb.inf
Needs=Composite.Dev.NT
AddReg=CCGPDriverInstall.AddReg

[CCGPDriverInstall.NT.Services]
Include=usb.inf
Needs=Composite.Dev.NT.Services

[CCGPDriverInstall.AddReg]
HKR,,EnumeratorClass,0x00000001,02,00,00
HKR,,CdcFlags,0x00010001,0x00010001

[Strings]
MSFT="Microsoft"
COMPANYNAME.DeviceDesc="USB Phone Parent"

Manipulando coleções de interface CDC e WMCDC

O controlador pai genérico USB lida com modelos de interface de controlo de dispositivo sem fio (WHCM) de uma maneira especial.

A lista a seguir resume as maneiras mais importantes pelas quais o tratamento de coleções de interface CDC e WMCDC difere de outras coleções de interface:

• A classe de dispositivo de comunicação móvel sem fio permite uma quantidade limitada de aninhamento de coleções de interface. Em particular, uma coleção de interface de telefone lógico (ou seja, uma coleção de interface WHCM) pode conter outras coleções de interface subordinadas. Por exemplo, um telefone compatível com WMCDC pode ter uma coleção de interface WHCM, que, por sua vez, contém uma coleção de modelo de controle abstrato e uma coleção OBEX.
• Pode configurar o driver genérico USB para não enumerar coleções de interfaces WHCM. As coleções de interface WHCM que não são enumeradas permanecem ocultas, mas o driver pai genérico usa informações dos descritores de função de união (UFDs) que pertencem a uma coleção de interface WHCM para agrupar e enumerar coleções de interface subordinadas.
• Você pode configurar o driver pai genérico USB para criar objetos de dispositivos físicos (PDO) separados para coleções de interfaces do modelo de controlo OBEX ou para criar um único PDO para todas as coleções de interfaces do modelo de controlo OBEX.
• A lista de números de interface em um UFD pode ter lacunas. Ou seja, os números de interface de um UFD podem referir-se a interfaces que não são contíguas. Este tipo de numeração não é válido, por exemplo, para o descritor de associação de interface USB (IAD), cujas interfaces devem ser contíguas e ter números sequenciais.
• Os UFDs podem incluir coleções de interfaces de áudio relacionadas
• Os identificadores de hardware (IDs) para coleções de interface CDC e WMCDC devem incluir a subclasse de interface. Outras interfaces USB, cujos IDs de hardware contêm um sufixo MI_%02X que especifica o número da interface, não contêm informações sobre a subclasse da interface. As informações da subclasse são incluídas no ID de hardware para permitir aos fornecedores fornecer arquivos INF com IDs de hardware correspondentes para coleções de interfaces específicas, em vez de confiar na posição da interface no layout do descritor para determinar qual driver carregar para a coleção. As informações de subclasse no ID de hardware também permitem uma migração gradual de drivers fornecidos pelo fornecedor atual que gerem coleções de interface WMCDC para alternativas, como drivers em modo de utilizador. Para obter uma discussão geral sobre como os IDs de hardware da interface USB são formatados, consulte Identificadores para dispositivos USB.

Modelos de controle CDC e WMCDC

A seção Modelos de controle CDC e WMCDC descreve as propriedades das coleções de interface suportadas nos sistemas operacionais Microsoft Windows. Cada descrição inclui, entre outros elementos, uma lista de identificadores de hardware e dispositivo (IDs) que o driver pai genérico USB gera para o conjunto de interfaces.

A maioria das coleções de interface suportadas pelo Windows corresponde a modelos de controle que pertencem à classe de dispositivo de comunicação (CDC) e à classe de dispositivo de comunicação móvel sem fio (WMCDC), mas o sistema operacional também suporta coleções de interface de áudio e vídeo herdadas e uma coleção de interface que o Mobile Computing Promotion Consortium (MCPC) define.

As coleções de interface descritas nesta seção são as seguintes:

Interfaces de classe de áudio

As coleções de interfaces da classe de dispositivo de áudio USB que ocorrem em dispositivos CDC e WMCDC têm as seguintes propriedades.

Modelo de Controle Abstrato CDC

Existem duas versões do Modelo de Controle Abstrato (ACM). A versão original é definida na especificação USB Communication Device Class (CDC). A especificação USB Wireless Mobile Communication Device Class (WMCDC) contém uma definição estendida do ACM.

As coleções de interfaces que estão em conformidade com a especificação WMCDC são descritas nesta página.

As coleções de interfaces que estão em conformidade com a especificação CDC têm as seguintes propriedades.

Modelo de controle de rede ATM CDC

As coleções de interface USB CDC ATM Networking Control Model (ANCM) têm as seguintes propriedades.

Modelo de controle CDC CAPI

As coleções da interface do Modelo de Controle USB CDC Common ISDN API (CAPI) têm as seguintes propriedades.

Modelo de controle de linha direta CDC

As coleções de interface USB CDC direct line control model (DLCM) têm as seguintes propriedades.

Modelo de controle de rede Ethernet CDC

As coleções de interface USB CDC Ethernet Network Control Model (ENCM) têm as seguintes propriedades.

Modelo de controlo RDIS multicanal CDC

As coleções de interfaces USB CDC do Modelo de Controlo ISDN Multicanal (MCCM) têm as seguintes propriedades.

Modelo de controle telefônico CDC

As coleções de interfaces do modelo USB CDC de controle telefônico (TCM) têm as seguintes propriedades.

Interfaces exclusivas do fornecedor MCPC

O Mobile Computing Promotion Consortium (MCPC) definiu um formato para coleções de interfaces antes que a especificação WMCDC (Wireless Mobile Communication Device Class) fornecesse um formato para dispositivos CDC exclusivos do fornecedor. Portanto, as coleções de interface MCPC não estão em conformidade com o padrão WMCDC.

No entanto, o driver pai genérico USB pode enumerar coleções de interface MCPC se WMCDC estiver habilitado. As coleções de interface MCPC têm as seguintes propriedades.

Interfaces de aulas em vídeo

As coleções de interfaces da classe de dispositivos de vídeo USB ocorrentes em dispositivos CDC e WMCDC têm as seguintes propriedades.

Modelo de controle abstrato WMCDC

Existem duas versões do modelo de controle abstrato (ACM). A versão original é definida na especificação USB Communication Device Class (CDC). A especificação USB Wireless Mobile Communication Device Class (WMCDC) contém uma definição estendida do ACM. As coleções do ACM que contêm uma função de fax/modem devem usar a definição WMCDC de ACM em vez da definição original do CDC ACM.

As coleções de interfaces que estão em conformidade com a especificação CDC são descritas nesta página.

As coleções de interface que estão em conformidade com a especificação WMCDC têm as seguintes propriedades.

Modelo de gerenciamento de dispositivos WMCDC

As coleções de interface do modelo de gerenciamento de dispositivos WMCDC (DMM) USB têm as seguintes propriedades.

Modelo de linha direta móvel WMCDC

As coleções de interfaces do modelo de linha direta móvel WMCDC USB (MDLM) têm as seguintes propriedades:

Modelo de controlo de OBEX WMCDC (múltiplos PDOs)

Há duas maneiras de enumerar coleções de interface de modelo de controle OBEX (Object Exchange Protocol): o driver pai genérico USB pode agrupar todas as interfaces OBEX e criar um único objeto de dispositivo físico (DOP) para todas as interfaces OBEX, ou o driver pai pode criar um PDO separado para cada interface OBEX.

Quando o driver pai genérico USB atribui PDOs separados a cada interface OBEX, os PDOs têm as seguintes propriedades.

Modelo de controlo WMCDC OBEX (DOP único)

Existem duas maneiras de enumerar as coleções de interfaces do modelo de controlo OBEX (Protocolo de Troca de Objetos): o controlador genérico principal USB pode agrupar todas as interfaces OBEX e criar um único objeto de dispositivo físico (ODF) para todas as interfaces OBEX, ou o controlador principal pode criar um ODF separado para cada interface OBEX.

Quando o driver pai genérico USB atribui um único PDO a todas as interfaces OBEX, o PDO tem as seguintes propriedades.

Modelo de controle de aparelho sem fio WMCDC

O driver principal genérico USB nem sempre enumera as coleções de interface de modelo de controlo de dispositivos sem fio (WHCM). As configurações do Registro associadas à instância do driver pai genérico USB que gerencia a coleção de interface WHCM determinam se o driver pai genérico USB cria um objeto de dispositivo físico (DOP) para a coleção de interface ou não. Para obter uma explicação das definições do registo que especificam a forma como o driver pai genérico USB enumera as interfaces WHCM, consulte Enumeração de coleções de interface em dispositivos compostos USB.

As coleções de interface WHCM enumeradas têm as seguintes propriedades.

Os formatos de ID de hardware nos tópicos anteriores descrevem o uso das seguintes convenções:

• um formato printf em linguagem C representa números inteiros. Por exemplo, "%04x" significa um inteiro hexadecimal de 4 dígitos, "%02x" significa um inteiro hexadecimal de 2 dígitos, e assim por diante.
• O inteiro que segue a cadeia de caracteres "Vid_" é uma representação hexadecimal de 4 dígitos do código do fornecedor que o comitê USB (<www.usb.org>) atribui ao fornecedor.
• O inteiro que segue a cadeia de caracteres "Pid_" é uma representação hexadecimal de 4 dígitos do código do produto que o fornecedor atribui ao dispositivo.
• O inteiro que segue a cadeia de caracteres "Rev_" é uma representação hexadecimal de 4 dígitos do número de revisão do dispositivo.
• O inteiro que segue a cadeia de caracteres "Cdc_" é a subclasse da interface.
• O inteiro que segue a cadeia de caracteres "Prot_" é o número do protocolo.
• O inteiro que segue a cadeia de caracteres "MI_" é uma representação hexadecimal de 2 dígitos do número da interface, que é extraída do campo bInterfaceNumber do descritor da interface.

Enumeração de coleções de interface em dispositivos USB com IADs

Se um dispositivo composto USB tiver um descritor de associação de interface (IAD) em seu firmware, o Windows enumerará coleções de interface como se cada coleção fosse um único dispositivo e atribui um único objeto de dispositivo físico (DOP) a cada coleção de interface e associa hardware e identificadores compatíveis (IDs) com o DOP. Para obter uma descrição detalhada dos IADs, consulte USB Interface Association Descriptor. Esta seção descreve os IDs de hardware e identificadores compatíveis (IDs) atribuídos a coleções de interface associadas a um IAD.

IDs de hardware de dispositivos USB com IADs

USB\VID_v(4)&PID_p(4)&Rev_r(4)&MI_z(2)

USB\VID_v(4)&PID_p(4)&MI_z(2)

Nestes identificadores de equipamento,

• v(4) é o código de fornecedor de quatro dígitos que o comité USB atribui ao fornecedor e que é extraído do campo idVendor do descritor do dispositivo.
• p(4) é o código de produto de quatro dígitos que o fornecedor atribui ao dispositivo e que é extraído do campo idProduct do descritor do dispositivo.
• r(4) é o número de liberação do dispositivo de quatro dígitos, em revisão decimal codificada binária, que o fornecedor atribui ao dispositivo e que é extraído do campo bcdDevice do descritor do dispositivo.
• z(2) é o número de interface de dois dígitos extraído do campo bFirstInterface do IAD.

IDs de dispositivos USB compatíveis com IADs

USB\Class_c(2)&SubClass_s(2)&Prot_p(2)

USB\Class_c(2)&SubClass_s(2)

USB\Class_c(2)

Nessas IDs compatíveis, c(2), s(2) e p(2) contêm valores que são obtidos, respectivamente, dos campos bFunctionClass, bFunctionSubClass e bFunctionProtocol do IAD.

Não é possível usar IADs recursivamente para associar funções a funções. Em particular, se um dispositivo tiver descritores IAD em seu firmware, o driver pai genérico não agrupará interfaces por classe de dispositivo de áudio, conforme descrito em Enumeração de coleções de interface em dispositivos compostos USB.

Enumeração de coleções de interface em dispositivos de áudio sem IADs

Para dispositivos de áudio, o sistema operacional Windows pode enumerar grupos de interfaces (coleções de interface) que estão associados a uma função e atribuir um único objeto de dispositivo físico (DOP) a cada grupo, mesmo quando o dispositivo não tem um descritor de associação de interface (IAD).

O sistema operacional agrupa as interfaces de dispositivos de áudio composto em coleções de interfaces, se as interfaces atenderem às seguintes condições:

• Todas as interfaces na coleção de interfaces devem ser consecutivas. Em outras palavras, as interfaces devem ser adjacentes umas às outras na memória de firmware.
• Todas as interfaces na coleção de interfaces devem pertencer à classe de dispositivo de áudio. O fabricante do dispositivo especifica que uma interface pertence à classe de dispositivo de áudio atribuindo um valor de 0x01 ao campo bInterfaceClass do descritor de interface.
• Cada interface na coleção de interfaces deve ter uma subclasse diferente da primeira interface da coleção. O campo bInterfaceSubClass do descritor de interface especifica a subclasse de dispositivo da interface.

Se uma interface não atender a todas essas três condições, o Windows tentará enumerá-la separadamente em vez de agrupá-la com as outras interfaces de classe de áudio.

O sistema operacional não agrupa interfaces de classe de áudio de uma maneira especial se um descritor de associação de interface (IAD) estiver presente no firmware do dispositivo. O método IAD é sempre o método preferido de agrupamento de interfaces USB.

Esta seção descreve o hardware e identificadores compatíveis (IDs) associados ao PDO criado pelo sistema operacional para uma coleção de interfaces cujas interfaces pertencem à classe de dispositivo de áudio.

IDs de hardware de dispositivos de áudio sem IADs

USB\VID_v(4)&PID_p(4)&Rev_r(4)&MI_z(2)

USB\VID_v(4)&PID_p(4)&MI_z(2)

Nestes identificadores de hardware,

• v(4) é o código de fornecedor de quatro dígitos que o comité de normas USB atribui ao fornecedor e que é extraído do campo idVendor do descritor do dispositivo.
• p(4) é o código de produto de quatro dígitos que o fornecedor atribui ao dispositivo e que é extraído do campo idProduct do descritor do dispositivo.
• r(4) é o número de liberação do dispositivo de quatro dígitos, em revisão decimal codificada binária, que o fornecedor atribui ao dispositivo e que é extraído do campo bcdDevice do descritor do dispositivo.
• z(2) é o número de interface de dois dígitos extraído do campo bInterfaceNumber do descritor de interface.

IDs compatíveis de dispositivos de áudio sem IADs

USB\Class_c(2)&SubClass_s(2)&Prot_p(2)

USB\Class_c(2)&SubClass_s(2)

USB\Class_c(2)

Nessas IDs compatíveis, c(2), s(2) e p(2) contêm valores que são obtidos, respectivamente, dos campos bInterfaceClass, bInterfaceSubClass e bInterfaceProtocol do primeiro descritor de interface USB em cada coleção de interface.

Tópicos relacionados

• Driver principal genérico USB (Usbccgp.sys)
• drivers USB fornecidos pela Microsoft