Översikt över uppräkning av gränssnittssamlingar på USB-sammansatta enheter

Gränssnitt på en sammansatt USB-enhet kan grupperas i samlingar. Den allmänna USB-drivrutinen (Usbccgp.sys) kan räkna upp gränssnittssamlingar på fyra sätt.

Dessa fyra metoder för uppräkning av gränssnittssamlingar ordnas hierarkiskt på följande sätt:

1. Rutiner för återanrop från leverantör

   Om leverantören har registrerat en återanropsrutin med USB Generic Parent Driver (Usbccgp.sys), ger den generiska överordnade drivrutinen företräde till återanropsrutinen och tillåter återanropsrutinen att gruppera gränssnitt i stället för att använda någon annan metod. Mer information om uppräkning av gränssnittssamling med hjälp av återanropsrutiner som tillhandahålls av leverantören finns i Uppräkning av gränssnittssamlingar på USB-sammansatta enheter.

2. Unionens funktionella beskrivningar

   . Om leverantören har aktiverat CDC- och WMCDC-uppräkning i den allmänna överordnade USB-drivrutinen använder den allmänna överordnade drivrutinen föreningsfunktionella deskriptorer (UFD) för att gruppera gränssnitt i samlingar. När den här metoden är aktiverad har den företräde framför alla andra metoder, förutom återanropsrutiner som tillhandahålls av leverantören.

3. Gränssnittsassociationsdeskriptorer

   Om gränssnittsassocieringsbeskrivningar (IAD) finns grupperar den allmänna överordnade USB-drivrutinen alltid gränssnitt med hjälp av IAD:er i stället för med äldre metoder. Microsoft rekommenderar att leverantörer använder IAD:er för att definiera gränssnittssamlingar.

4. Äldre ljudmetod

   Den generiska USB-huvuddrivrutinen kan identifiera och hantera gränssnittssamlingar med hjälp av äldre tekniker som är reserverade för ljudfunktioner. Den allmänna överordnade drivrutinen använder inte den här metoden om det finns några IAD:n på enheten.

Anpassa uppräkning av gränssnittssamlingar för sammansatta enheter

Vissa USB-enheter har gränssnittssamlingar som IAD (USB Interface Association Descriptor) inte kan beskriva. I Windows Vista och senare operativsystem kan leverantörer anpassa hur USB Generic Parent Driver (Usbccgp.sys) definierar och räknar upp en enhets gränssnittssamlingar. Detta görs via en återanropsrutin för uppräkning i en filterdrivrutin. Återanropsrutinen hjälper den allmänna överordnade drivrutinen att definiera anpassade gränssnittssamlingar för enheten.

För att den allmänna överordnade drivrutinen ska definiera anpassade gränssnittssamlingar måste leverantören av den sammansatta enheten:

1. Implementera återanropsrutinen för uppräkning (USBC_START_DEVICE_CALLBACK).
2. Ange en pekare till callback-rutinen i USB-enhetens konfigurationsgränssnitt (i medlemmen StartDeviceCallback i USBC_DEVICE_CONFIGURATION_INTERFACE_V1).
3. Ange en INF-fil som matchar enhets-ID:t för den sammansatta enheten och som uttryckligen läser in både den allmänna överordnade USB-drivrutinen och filterdrivrutinen.

Implementeringöverväganden

Filterdrivrutinen som innehåller återanropsrutinen för uppräkning kan vara antingen en övre eller en lägre filterdrivrutin. När den generiska USB-drivrutinen tar emot en IRP_MN_START_DEVICE begäran om att starta en sammansatt enhet, frågar den efter USB-enhetens konfigurationsgränssnitt genom att skicka en IRP_MN_QUERY_INTERFACE begäran högst upp i drivrutinsstacken.

När du tar emot en IRP_MN_QUERY_INTERFACE begäran måste filterdrivrutinen kontrollera GUID-typen i InterfaceType-medlemmen i begäran för att kontrollera att gränssnittet som begärs är av typen USB_BUS_INTERFACE_USBC_CONFIGURATION_GUID. I så fall returnerar filterdrivrutinen en pekare till gränssnittet i gränssnittsmedlemmen i IRP.

Återanropsrutinen för uppräkning måste returnera en pekare till en matris med funktionsbeskrivningar (USBC_FUNCTION_DESCRIPTOR) som beskriver gränssnittssamlingarna. Varje funktionsbeskrivning innehåller en matris med gränssnittsbeskrivningar (USB_INTERFACE_DESCRIPTOR) som beskriver gränssnittssamlingen. Återanropsrutinen måste allokera både funktionsbeskrivningarna och gränssnittsbeskrivningarna från en icke-sidig pool. Den generiska överordnade drivrutinen frigör det här minnet. Återanropsrutinen måste se till att NumberOfInterfaces-medlemmen i varje USB_INTERFACE_DESCRIPTOR korrekt rapporterar antalet gränssnitt i gränssnittssamlingen.

Den allmänna överordnade drivrutinen skapar ett fysiskt enhetsobjekt (PDO) för varje funktionsbeskrivning.

Usb-enhetens konfigurationsgränssnitt och återanrop för uppräkning sammanfattas i Generiska huvuddrivrutinsrutiner.

USB-mekanism för inläsning av generiska huvuddrivrutiner

När en sammansatt enhet uppfyller kraven som beskrivs i Uppräkning av USB-sammansatta enheter genererar operativsystemet ett kompatibelt ID USB\COMPOSITE för för att indikera att enheten är sammansatt. Det kompatibla ID:t genererar en matchning i Usb.inf, och operativsystemet läser automatiskt in den generiska USB-drivrutinen utan hjälp av en INF-fil från leverantören.

Den här standardmekanismen fungerar dock inte för sammansatta enheter som kräver anpassad uppräkning av gränssnittssamlingar, eftersom systemet i standardmekanismen inte läser in den nödvändiga filterdrivrutinen som tillhandahålls av leverantören. För att återanropsrutinen för uppräkning ska fungera, måste filterdrivrutinen som exponerar konfigurationsgränssnittet för USB-enheten redan vara inläst när den generiska USB-föräldern uppräknar gränssnittssamlingarna för den sammansatta enheten. Detta kräver att leverantören av den sammansatta enheten installerar en INF-fil som matchar enhets-ID:t för den sammansatta enheten och uttryckligen läser in både den allmänna överordnade USB-drivrutinen och filterdrivrutinen.

Stöd för enhetens klass för trådlös mobil kommunikation

I Windows Vista ger USB Generic Parent Driver (Usbccgp.sys) stöd för enheter som ingår i Universal Serial Bus (USB) Communication Device Class (CDC) och USB Wireless Mobile Communication Device Class (WMCDC).

Specifikationen för USB Wireless Mobile Communication Device Class (WMCDC) upprättar en standard för anslutning, kontroll och innehållsutbyte mellan en värd och en trådlös mobil enhet (till exempel en mobiltelefon) när enheten är ansluten till en USB-port. WMCDC är en förlängning av kommunikationsenhetsklassen (CDC), som innehåller ett brett utbud av kommunikations- och nätverksenheter. I det här avsnittet beskrivs arkitekturen som stöder CDC- och WMCDC-enheter i Windows-operativsystem.

WMCDC-enheter består av flera funktioner som är grupperade i logiska telefoner. De flesta WMCDC-enheter har en enda logisk handenhet, men en enhet kan ha flera logiska telefoner. Logiska telefoner innehåller vanligtvis funktioner som ett data-/faxmodem, ett objektlager och en anropskontrollfunktion. En logisk handenhet kan också innehålla stödfunktioner som definieras av andra USB-specifikationer, till exempel specifikationen för USB-ljudklassen, HID-klassspecifikationen (USB Human Input Device) och specifikationen för USB Video Class.

Windows WMCDC-arkitekturen använder inbyggda Windows-drivrutiner för att hantera funktionerna i din WMCDC-enhet. Du kan till exempel använda undersystemet För Windows-telefoniprogramgränssnittet (TAPI) för att hantera enhetens röst- och data-/faxmodemfunktioner och undersystemet NDIS (Windows Network Driver Interface Specification) för att hantera enhetens Ethernet LAN-funktion. Dessutom kan du hantera vissa funktioner, till exempel en OBEX-funktion (Object Exchange Protocol), i programvara i användarläge med hjälp av WinUSB (Winusb.sys).

Den här bilden visar en exempeldrivrutinsstack för en WMCDC-enhet.

I föregående bild innehåller WMCDC-enheten en enda logisk handenhet: en OBEX-funktion och en modemfunktion. En INF-fil som tillhandahålls av leverantören läser in inbyggda Windows-drivrutiner för att hantera modemet. OBEX-funktionen hanteras av en drivrutin för användarläge som tillhandahålls av leverantören och som körs i User-Mode Driver Framework (UMDF). Drivrutinen i användarläge använder WPD-protokollet (Windows Portable Devices) för att kommunicera med användarprogram och gränssnittet som Introduktion till WinUSB för utvecklare exporterar för att kommunicera med USB-stacken. I allmänhet läser en INF-fil från leverantören in en separat instans av Winusb.sys för varje gränssnittssamling som använder Winusb.sys.

Registerinställningar

USB-stacken har inte automatiskt stöd för WMCDC. Du måste ange en INF-fil som läser in en instans av Usbccgp.sys. INF-filen måste innehålla ett AddReg-avsnitt som anger registervärdet EnumeratorClass i programvarunyckeln som är associerad med Usbccgp.sys till ett REG_BINARY värde som är konstruerat från tre tal: 0x02, 0x00 och 0x 00. Följande kodexempel från en INF-exempelfil visar hur du anger EnumeratorClass till lämpligt värde.

[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

Värdet som du måste tilldela till EnumeratorClass är konstruerat från tre binära värden på 1 byte som representeras i INF-filen av par med hexadecimala siffror: 02, 00 och 00. Dessa tre tal motsvarar de värden som USB-implementeringsforumet har tilldelat till CDC-enhetsklassen, CDC-enhetens underklass respektive CDC-enhetsprotokollet.

Följande avsnitt beskriver WMCDC ytterligare:

Räkna upp gränssnittssamlingar på WMCDC

USB trådlös mobilkommunikationsenhetsklass (WMCDC) är en underklass till USB-kommunikationsenhetsklass (CDC). WMCDC-specifikationen utökar men ändrar inte CDC-riktlinjerna väsentligt för att definiera gränssnittssamlingar. I synnerhet måste WMCDC-enheter följa CDC-riktlinjerna för att definiera gränssnittssamlingar.

CDC-gränssnittssamlingar innehåller ett huvudgränssnitt (USB_INTERFACE_DESCRIPTOR) som tillhör klassen för kommunikationsgränssnittet (bInterfaceClass = 0x02) eller datagränssnittsklassen (bInterfaceClass = 0x0A). Om huvudgränssnittet tillhör klassen för kommunikationsgränssnitt (vilket är den typiska situationen) anger underklassen för huvudgränssnittet (bInterfaceSubClass) en CDC-kontrollmodell. Kontrollmodellen anger vilken typ av gränssnitt som ingår i gränssnittssamlingen. En beskrivning av de kontrollmodeller som usb-implementeringsforumet definierar finns i CDC-specifikationen och WMCDC-specifikationen.

Huvudgränssnittet för en gränssnittssamling följs av en uppsättning obligatoriska klassspecifika funktionella deskriptorer, inklusive en union funktionell deskriptor (UFD). UFD visar en lista över de gränssnitt som tillhör samlingen. Fältet bMasterInterface i UFD innehåller numret på huvudgränssnittet. Noll eller fler bSubordinateInterface-fält innehåller talen för de andra (underordnade) gränssnitten i samlingen.

För de flesta typer av kontrollmodeller skapar USB Generic Parent Driver (Usbccgp.sys) ett fysiskt enhetsobjekt (PDO) för varje UFD. Men vissa kontrollmodeller innehåller ett ljudgränssnitt som den allmänna överordnade drivrutinen räknar upp separat från den gränssnittssamling som ljudgränssnittet tillhör. Ljudgränssnittet visas i listan över underordnade gränssnitt (bSubordinateInterface) i UFD för gränssnittssamlingen, men den allmänna överordnade drivrutinen skapar en separat PDO för ljudgränssnittet. Både PDO för ljudgränssnittet och PDO för gränssnittssamlingen som ljudgränssnittet tillhör ligger direkt ovanför det funktionella enhetsobjektet (FDO) för den överordnade sammansatta enheten i enhetsobjektträdet. PDO för ljudgränssnittet är inte en del av gränssnittssamlingen.

Det finns två kontrollmodeller vars uppräkningsegenskaper kan konfigureras i registret: den trådlösa handenhetskontrollmodellen (WHCM), som definierar en logisk handenhet och OBEX-kontrollmodellen (Object Exchange Protocol). För att konfigurera uppräkningsegenskaperna för dessa två kontrollmodeller måste du ange en INF-fil som läser in en instans av Usbccgp.sys och anger värdet för CdcFlags i programvarunyckeln för den instansen av Usbccgp.sys. I följande tabell beskrivs konfigurationsalternativen för CdcFlags.

Om du till exempel vill rensa båda bitarna (ange dem till 0) bör INF-filen ha följande rad i ett DDInstall.AddReg-avsnitt .

HKR, , CdcFlags, 0x00010001, 0x00000000

Om du vill ange båda bitarna till 1 bör INF-filen ha följande rad.

HKR, , CdcFlags, 0x00010001, 0x00000011

Om du vill ange både bit 0 till 1 och bit 1 till 0 bör INF-filen ha följande rad.

HKR, , CdcFlags, 0x00010001, 0x00000001

Endera biten kan ställas in eller återställas, oberoende av den andra biten.

Följande siffror visar hur olika registerkonfigurationer kan skapa olika enhetsträd för samma enhet.

Följande bild illustrerar PDO-konfigurationen när både bit 0 och bit 1 av CdcFlags är 0.

Den trådlösa handenhetskontrollmodellens (WHCM) gränssnittssamling i föregående bild innehåller tre underordnade gränssnittssamlingar (bSubordinateInterface): två OBEX-samlingar och en modemsamling. Bit 0 av CdcFlags är 0, så den allmänna USB-drivrutinen skapar inte en PDO för WHCM-gränssnittssamlingen. Bit 1 av CdcFlags är 0, så den generiska USB-drivrutinen genererar en separat PDO för varje OBEX-gränssnittssamling.

Följande bild illustrerar PDO-konfigurationen när både bit 0 och bit 1 av CdcFlags har angetts .

Eftersom bit 0 av CdcFlags är inställt på 1 skapar den allmänna överordnade USB-drivrutinen en PDO för WHCM-gränssnittssamlingen. Eftersom bit 1 av CdcFlags är inställt på 1 grupperar usb-drivrutinen de två OBEX-samlingarna tillsammans och genererar en enda PDO för båda OBEX-samlingar.

Du kanske vill representera OBEX-samlingar med en enda PDO på kernelnivå och skilja mellan varje enskild OBEX-samling inom en drivrutin i användarläge. Protokollet Windows Portable Devices (WPD) kan hjälpa dig att multiplexera dataströmmar mellan olika OBEX-funktioner på användarnivå, när alla OBEX-funktioner är grupperade i en enda PDO på kernelnivå.

I följande exempel läser INF-filen in den allmänna överordnade USB-drivrutinen för att hantera en WMCDC-enhet och instruerar den USB-generiska överordnade drivrutinen att skapa PDOs för logiska telefoner och att skapa en enda PDO för alla OBEX-samlingar i den logiska enheten.

[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"

Hantera CDC- och WMCDC-gränssnittssamlingar

Den allmänna USB-drivrutinen hanterar WHCM-gränssnittet (Wireless Handset Control Model) på ett speciellt sätt.

I följande lista sammanfattas de viktigaste sätten på vilka hanteringen av CDC- och WMCDC-gränssnittssamlingar skiljer sig från andra gränssnittssamlingar:

• Den trådlösa mobila kommunikationsenhetsklassen tillåter en begränsad mängd kapsling av gränssnittssamlingar. I synnerhet kan en logisk handenhetsgränssnittssamling (dvs. en WHCM-gränssnittssamling) innehålla andra underordnade gränssnittssamlingar. Till exempel kan en WMCDC-kompatibel telefon ha en WHCM-gränssnittssamling, som i sin tur innehåller en abstrakt kontrollmodellsamling och en OBEX-samling.
• Du kan konfigurera den generiska USB-huvuddrivrutinen så att den inte listar WHCM-gränssnittssamlingar. WHCM-gränssnittssamlingar som inte är uppräknade förblir dolda, men den allmänna överordnade drivrutinen använder information från union-funktionsbeskrivningar (UFD: er) som tillhör en WHCM-gränssnittssamlingar för att gruppera och räkna upp underordnade gränssnittssamlingar.
• Du kan konfigurera den allmänna överordnade USB-drivrutinen för att skapa separata fysiska enhetsobjekt (PDOs) för OBEX-kontrollmodellgränssnittssamlingar eller för att skapa en enda PDO för alla OBEX-kontrollmodellgränssnittssamlingar.
• Listan över gränssnittsnummer i en UFD kan ha luckor. Det innebär att gränssnittsnumren för en UFD kan referera till gränssnitt som inte är sammanhängande. Den här typen av numrering är inte giltig, till exempel för IAD (USB Interface Association Descriptor), vars gränssnitt måste vara sammanhängande och ha sekventiella tal.
• UFD:er kan innehålla relaterade ljudgränssnittssamlingar
• Maskinvaruidentifierare (ID:n) för CDC- och WMCDC-gränssnittssamlingar måste innehålla gränssnittsunderklassen. Andra USB-gränssnitt, vars maskinvaru-ID:er innehåller ett MI_%02X suffix som anger gränssnittsnumret, innehåller inte information om gränssnittets underklass. Underklassinformationen ingår i maskinvaru-ID:t så att leverantörer kan tillhandahålla INF-filer med maskinvaru-ID-matchningar för specifika gränssnittssamlingar, i stället för att förlita sig på gränssnittets position i beskrivningslayouten för att avgöra vilken drivrutin som ska läsas in för samlingen. Underklassinformationen i maskinvaru-ID:t möjliggör också en gradvis migreringsväg från aktuella drivrutiner som tillhandahålls av leverantören och som hanterar WMCDC-gränssnittssamlingar till alternativ, till exempel drivrutiner i användarläge. En allmän diskussion om hur USB-gränssnitts maskinvaru-ID:er formateras finns i Identifierare för USB-enheter.

CDC- och WMCDC-kontrollmodeller

Avsnittet CDC- och WMCDC-kontrollmodeller beskriver egenskaperna för gränssnittssamlingar som stöds i Microsoft Windows-operativsystem. Varje beskrivning innehåller bland annat en lista över maskinvaru- och enhetsidentifierare (ID:n) som den allmänna överordnade USB-drivrutinen genererar för gränssnittssamlingen.

De flesta gränssnittssamlingar som Windows stöder motsvarar kontrollmodeller som tillhör klassen för kommunikationsenheter (CDC) och WMCDC (Wireless Mobile Communication Device Class), men operativsystemet har också stöd för äldre ljud- och videogränssnittssamlingar och en gränssnittssamling som MCPC (Mobile Computing Promotion Consortium) definierar.

De gränssnittssamlingar som beskrivs i det här avsnittet är följande:

Ljudklassgränssnitt

Usb Audio Device-klassgränssnittssamlingar som förekommer på CDC- och WMCDC-enheter har följande egenskaper.

CDC Abstrakt kontrollmodell

Det finns två versioner av ACM (Abstract Control Model). Den ursprungliga versionen definieras i CDC-specifikationen (USB Communication Device Class ). Specifikationen för USB Wireless Mobile Communication Device Class (WMCDC) innehåller en utökad definition av ACM.

Gränssnittssamlingar som följer WMCDC-specifikationen beskrivs på den här sidan.

Gränssnittssamlingar som uppfyller CDC-specifikationen har följande egenskaper.

CDC ATM-nätverkskontrollmodell

USB CDC-uttagsautomat ANCM-gränssnittssamlingar (Networking Control Model) har följande egenskaper.

CDC CAPI-kontrollmodell

USB CDC Common ISDN API (CAPI) Control Model interface collections har följande egenskaper.

CDC-direktlinjekontrollmodell

DLCM-gränssnittssamlingar (Direct Line Control Model) för USB CDC har följande egenskaper.

CDC Ethernet-nätverkskontrollmodell

USB CDC Ethernet-nätverkskontrollmodell (ENCM) gränssnittssamlingar har följande egenskaper.

CDC-kontrollmodell med flera kanaler i ISDN

USB CDC-gränssnittssamlingarna för ISDN-kontrollmodellen (MCCM) med flera kanaler har följande egenskaper.

CDC-telefonkontrollmodell

USB CDC-gränssnittssamlingar (TCM) för telefonkontroll har följande egenskaper.

MCPC-leverantörsspecifika gränssnitt

Mobile Computing Promotion Consortium (MCPC) definierade ett format för gränssnittssamlingar innan WMCDC-specifikationen (Wireless Mobile Communication Device Class) tillhandahöll ett format för leverantörsspecifika CDC-enheter. Därför uppfyller MCPC-gränssnittssamlingar inte WMCDC-standarden.

Den generiska USB-drivrutinen kan dock räkna upp MCPC-gränssnittskollektioner om WMCDC är aktiverat. MCPC-gränssnittssamlingar har följande egenskaper.

Videoklassgränssnitt

USB-videoenhetsklassgränssnittssamlingar som förekommer på CDC- och WMCDC-enheter har följande egenskaper.

WMCDC abstrakt kontrollmodell

Det finns två versioner av den abstrakta kontrollmodellen (ACM). Den ursprungliga versionen definieras i CDC-specifikationen (USB Communication Device Class). Specifikationen för USB Wireless Mobile Communication Device Class (WMCDC) innehåller en utökad definition av ACM. ACM-samlingar som innehåller en fax-/modemfunktion bör använda WMCDC-definitionen för ACM i stället för den ursprungliga CDC ACM-definitionen.

Gränssnittssamlingar som följer CDC-specifikationen beskrivs på den här sidan.

Gränssnittssamlingar som uppfyller WMCDC-specifikationen har följande egenskaper.

WMCDC-enhetshanteringsmodell

Gränssnittssamlingar för USB WMCDC-enhetshanteringsmodell (DMM) har följande egenskaper.

WMCDC mobil direktlinjemodell

USB WMCDC-gränssnittssamlingar för mobil direktlinjemodell (MDLM) har följande egenskaper:

WMCDC OBEX-kontrollmodell (flera PDOs)

Det finns två sätt att räkna upp Objektutbytesprotokoll (OBEX) kontrollmodellsgränssnittssamlingar: USB:s generiska överordnade drivrutin kan gruppera alla OBEX-gränssnitt tillsammans och skapa ett enda fysiskt enhetsobjekt (PDO) för alla OBEX-gränssnitt, eller den överordnade drivrutinen kan skapa en separat PDO för varje OBEX-gränssnitt.

När den generiska överordnade USB-drivrutinen tilldelar separata PDO till varje OBEX-gränssnitt har de PDO följande egenskaper.

WMCDC OBEX-kontrollmodell (enskild PDO)

Det finns två sätt att räkna upp Object Exchange Protocol (OBEX) kontrollmodellens gränssnittssamlingar: den USB-generiska överordnade drivrutinen kan gruppera alla OBEX-gränssnitt tillsammans och skapa ett enda fysiskt enhetsobjekt (PDO) för alla OBEX-gränssnitt, eller den överordnade drivrutinen kan skapa en separat PDO för varje OBEX-gränssnitt.

När den allmänna överordnade USB-drivrutinen tilldelar en enda PDO till alla OBEX-gränssnitt har PDO:en följande egenskaper.

WMCDC trådlös handenhetskontrollmodell

Den allmänna USB-drivrutinen räknar inte alltid upp whcm-gränssnittssamlingar (wireless handset control model). Registerinställningarna som är associerade med instansen av den allmänna USB-drivrutinen som hanterar WHCM-gränssnittssamlingen avgör om den allmänna överordnade USB-drivrutinen skapar ett fysiskt enhetsobjekt (PDO) för gränssnittssamlingen eller inte. En förklaring av registerinställningarna som anger hur den allmänna överordnade USB-drivrutinen räknar upp WHCM-gränssnitt finns i Uppräkning av gränssnittssamlingar på USB-sammansatta enheter.

Uppräknade WHCM-gränssnittssamlingar har följande egenskaper.

Maskinvaru-ID-formaten i föregående avsnitt beskriver användningen av följande konventioner:

• ett C-språkformat för utskrift representerar heltal. "%04x" betyder till exempel ett fyrsiffrigt hexadecimalt heltal, "%02x" betyder ett 2-siffrigt hexadecimalt heltal och så vidare.
• Heltalet som följer strängen "Vid_" är en 4-siffrig hexadecimal representation av leverantörskoden som USB-kommittén (<www.usb.org>) tilldelar leverantören.
• Heltalet som följer strängen "Pid_" är en 4-siffrig hexadecimal representation av produktkoden som leverantören tilldelar enheten.
• Strängen "Rev_" följs av ett heltal som är en 4-siffrig representation av enhetens revisionsnummer i hexadecimal format.
• Underklassen för gränssnittet är det heltal som följer strängen "Cdc_".
• Det heltal som följer strängen "Prot_" är protokollnumret.
• Heltalet som följer strängen "MI_" är en tvåsiffrig hexadecimal representation av gränssnittsnumret, som extraheras från fältet bInterfaceNumber i gränssnittsbeskrivningen.

Uppräkning av gränssnittssamlingar på USB-enheter med IAD:er

Om en USB-sammansatt enhet har en gränssnittsassociation (IAD) i sin inbyggda programvara räknar Windows upp gränssnittssamlingar som om varje samling vore en enda enhet och tilldelar ett enda fysiskt enhetsobjekt (PDO) till varje gränssnittssamling och associerar maskinvaru- och kompatibla identifierare (ID) med PDO:n. En detaljerad beskrivning av IAD:er finns i USB Interface Association Descriptor. I det här avsnittet beskrivs de maskinvaru-ID:er och kompatibla identifierare (ID:er) som tilldelats gränssnittssamlingar som är associerade med en IAD.

Maskinvaru-ID för USB-enheter med IAD

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

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

I dessa maskinvaru-ID:t

• v(4) är den fyrsiffriga leverantörskod som USB-kommittén tilldelar leverantören och som extraheras från idVendor-fältet i enhetsbeskrivningen.
• p(4) är den fyrsiffriga produktkod som leverantören tilldelar enheten och som extraheras från fältet idProduct i enhetsbeskrivningen.
• r(4) är det fyrsiffriga versionsnumret för enheten, i binärkodad decimalrevision, som leverantören tilldelar enheten och som extraheras från fältet bcdDevice i enhetsbeskrivningen.
• z(2) är det tvåsiffriga gränssnittsnumret som extraheras från fältet bFirstInterface i IAD.

Kompatibla ID:n för USB-enheter med IAD

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

USB\Class_c(2)&SubClass_s(2)

USB\Class_c(2)

I dessa kompatibla ID:n innehåller c(2), s(2) och p(2) värden som hämtas från fälten bFunctionClass, bFunctionSubClass och bFunctionProtocol i IAD.

Du kan inte använda IAD:er rekursivt för att binda funktioner i funktioner. I synnerhet om en enhet har IAD-beskrivningar i sin inbyggda programvara grupperar den allmänna överordnade drivrutinen inte gränssnitt efter ljudenhetsklass, enligt beskrivningen i Uppräkning av gränssnittssamlingar på USB-sammansatta enheter.

Uppräkning av gränssnittssamlingar på ljudenheter utan IAD

För ljudenheter kan Windows-operativsystemet räkna upp grupper av gränssnitt (gränssnittssamlingar) som är associerade med en funktion och tilldela ett enda fysiskt enhetsobjekt (PDO) till varje grupp, även om enheten inte har någon gränssnittsassociationsbeskrivning (IAD).

Operativsystemet grupperar gränssnitten för sammansatta ljudenheter i gränssnittssamlingar, om gränssnitten uppfyller följande villkor:

• Alla gränssnitt i gränssnittssamlingen måste vara i följd. Med andra ord måste gränssnitten vara intill varandra i den inbyggda programvarans minne.
• Alla gränssnitt i gränssnittssamlingen måste tillhöra ljudenhetsklassen. Enhetstillverkaren anger att ett gränssnitt tillhör ljudenhetsklassen genom att tilldela värdet 0x01 till fältet bInterfaceClass i gränssnittsbeskrivningen.
• Varje gränssnitt i gränssnittssamlingen måste ha en annan underklass än det första gränssnittet i samlingen. Fältet bInterfaceSubClass i gränssnittsbeskrivningen anger enhetens underklass för gränssnittet.

Om ett gränssnitt inte uppfyller alla dessa tre villkor försöker Windows räkna upp det separat i stället för att gruppera det med de andra ljudklassgränssnitten.

Operativsystemet grupperar inte ljudklassgränssnitt på ett särskilt sätt om en gränssnittsassociation (IAD) finns i enhetens inbyggda programvara. IAD-metoden är alltid den bästa metoden för att gruppera USB-gränssnitt.

I det här avsnittet beskrivs maskinvara och kompatibla identifierare (ID:n) som är associerade med den PDO som skapas av operativsystemet för en gränssnittssamling vars gränssnitt tillhör ljudenhetsklassen.

Maskinvaru-ID för ljudenheter utan IAD

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

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

I dessa maskinvaru-ID:t

• v(4) är den fyrsiffriga leverantörskod som USB-standardkommittén tilldelar leverantören och som extraheras från idVendor-fältet i enhetsbeskrivningen.
• p(4) är den fyrsiffriga produktkod som leverantören tilldelar enheten och som extraheras från fältet idProduct i enhetsbeskrivningen.
• r(4) är det fyrsiffriga versionsnumret för enheten, i binärkodad decimalrevision, som leverantören tilldelar enheten och som extraheras från fältet bcdDevice i enhetsbeskrivningen.
• z(2) är det tvåsiffriga gränssnittsnumret som extraheras från fältet bInterfaceNumber i gränssnittsbeskrivningen.

Kompatibla ID:n för ljudenheter utan IAD

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

USB\Class_c(2)&SubClass_s(2)

USB\Class_c(2)

I dessa kompatibla ID:n innehåller c(2), s(2) och p(2) värden som hämtas från fälten bInterfaceClass, bInterfaceSubClass och bInterfaceProtocol i den första USB-gränssnittsbeskrivningen i varje gränssnittssamling.

Relaterade ämnen

• Generisk USB-drivrutin för överordnad enhet (Usbccgp.sys)
• USB-drivrutiner som tillhandahålls av Microsoft