Przegląd enumeracji kolekcji interfejsów na urządzeniach kompozytowych USB

Interfejsy na złożonym urządzeniu USB można zgrupować w kolekcjach. Ogólny sterownik nadrzędny USB (Usbccgp.sys) może wyliczać kolekcje interfejsów na cztery sposoby.

Te cztery metody wyliczania kolekcji interfejsów są rozmieszczone hierarchicznie w następujący sposób:

1. Rutyny wywołania zwrotnego dostarczone przez dostawcę

   Jeśli dostawca zarejestrował procedurę wywołania zwrotnego za pomocą ogólnego sterownika nadrzędnego USB (Usbccgp.sys), ogólny sterownik nadrzędny ma pierwszeństwo przed procedurą wywołania zwrotnego i umożliwia procedurę wywołania zwrotnego do grupowania interfejsów zamiast używania innej metody. Aby uzyskać więcej informacji na temat wyliczania kolekcji interfejsów przy użyciu procedur wywołania zwrotnego dostarczonego przez dostawcę, zobacz Wyliczenie kolekcji interfejsów na urządzeniach złożonych USB.

2. Deskryptory funkcjonalne unii

   . Jeśli dostawca włączył wyliczanie CDC i WMCDC w ogólnym sterowniku nadrzędnym USB, ogólny sterownik nadrzędny używa deskryptorów funkcji zbiorczej (UFD) do grupowania interfejsów w kolekcje. Po włączeniu ta metoda ma pierwszeństwo przed wszystkimi innymi metodami, z wyjątkiem procedur wywołań zwrotnych dostarczonych przez dostawcę.

3. Deskryptory powiązań interfejsu

   Jeśli istnieją deskryptory skojarzeń interfejsu (IAD), ogólny sterownik nadrzędny USB zawsze grupuje interfejsy przy użyciu identyfikatorów IAD, a nie przy użyciu starszych metod. Firma Microsoft zaleca, aby dostawcy używali identyfikatorów IAD do definiowania kolekcji interfejsów.

4. Starsza metoda audio

   Ogólny sterownik nadrzędny USB umożliwia wyliczanie kolekcji interfejsów przy użyciu starszych technik zarezerwowanych dla funkcji audio. Ogólny sterownik nadrzędny nie używa tej metody, jeśli na urządzeniu znajdują się jakiekolwiek identyfikatory IAD.

Dostosowywanie wyliczania kolekcji interfejsów dla urządzeń złożonych

Niektóre urządzenia USB mają kolekcje interfejsów, których deskryptor skojarzenia interfejsu USB (IAD) nie może opisać. W systemach operacyjnych Windows Vista i nowszych dostawcy mogą dostosować sposób, w jaki ogólny sterownik nadrzędny USB (Usbccgp.sys) definiuje i wylicza kolekcje interfejsów urządzenia. Odbywa się to za pomocą procedury wywołania zwrotnego wyliczenia w sterowniku filtru. Procedura wywołania zwrotnego pomaga ogólnemu sterownikowi nadrzędnemu w definiowaniu kolekcji niestandardowych interfejsów dla urządzenia.

Aby ogólny sterownik nadrzędny mógł definiować kolekcje interfejsów niestandardowych, dostawca urządzenia złożonego musi:

1. Zaimplementuj procedurę wywołania zwrotnego wyliczenia (USBC_START_DEVICE_CALLBACK).
2. Podaj wskaźnik do procedury wywołania zwrotnego w interfejsie konfiguracji urządzenia USB (StartDeviceCallback składowej USBC_DEVICE_CONFIGURATION_INTERFACE_V1).
3. Podaj plik INF, który odpowiada identyfikatorowi urządzenia złożonego i jawnie ładuje zarówno ogólny sterownik główny USB, jak i sterownik filtru.

Uwagi dotyczące implementacji

Sterownik filtru zawierający procedurę wywołania zwrotnego wyliczenia może być sterownikiem górnego lub dolnego filtru. Gdy ogólny sterownik nadrzędny USB odbiera żądanie IRP_MN_START_DEVICE uruchomienia urządzenia złożonego, wysyła zapytanie o interfejs konfiguracji urządzenia USB, wysyłając żądanie IRP_MN_QUERY_INTERFACE do góry stosu sterowników.

Po otrzymaniu żądania IRP_MN_QUERY_INTERFACE sterownik filtru musi sprawdzić typ identyfikatora GUID w elemencie InterfaceType żądania, aby sprawdzić, czy żądany interfejs ma typ USB_BUS_INTERFACE_USBC_CONFIGURATION_GUID. Jeśli tak jest, sterownik filtru zwraca wskaźnik do interfejsu w składniku Interface elementu IRP.

Procedura wywołania zwrotnego enumeracji musi zwrócić wskaźnik do tablicy deskryptorów funkcji (USBC_FUNCTION_DESCRIPTOR), które opisują kolekcje interfejsów. Każdy deskryptor funkcji zawiera tablicę deskryptorów interfejsu (USB_INTERFACE_DESCRIPTOR), które opisują kolekcję interfejsów. Procedura wywołania zwrotnego musi przydzielać zarówno deskryptory funkcji, jak i deskryptory interfejsu z puli niestronicowanej. Ogólny sterownik nadrzędny zwalnia tę pamięć. Procedura wywołania zwrotnego musi zapewnić, że członek NumberOfInterfaces każdego USB_INTERFACE_DESCRIPTOR dokładnie przedstawia liczbę interfejsów w kolekcji interfejsów.

Ogólny sterownik nadrzędny tworzy obiekt urządzenia fizycznego (PDO) dla każdego deskryptora funkcji.

Interfejs konfiguracji urządzenia USB i procedura wywołania zwrotnego wyliczenia jest podsumowana w ogólnych procedurach sterowników nadrzędnych.

Mechanizm ładowania ogólnego sterownika nadrzędnego USB

Gdy urządzenie złożone spełnia wymagania opisane w sekcji Wyliczenie urządzeń złożonych USB, system operacyjny generuje zgodny identyfikator USB\COMPOSITE , aby wskazać, że urządzenie jest złożone. Zgodny identyfikator generuje dopasowanie w Usb.inf, a system operacyjny ładuje uniwersalny sterownik nadrzędny USB automatycznie, bez pomocy pliku INF dostarczonego przez dostawcę.

Jednak ten mechanizm domyślny nie działa w przypadku urządzeń złożonych, które wymagają niestandardowego wyliczania kolekcji interfejsów, ponieważ w domyślnym mechanizmie system nie ładuje wymaganego sterownika filtru dostarczonego przez dostawcę. Aby mechanizm procedury wywołania zwrotnego wyliczania działał, sterownik filtru, który udostępnia interfejs konfiguracji urządzenia USB, musi być już załadowany, gdy ogólny sterownik nadrzędny USB wylicza kolekcje interfejsów urządzenia złożonego. Wymaga to od dostawcy urządzenia złożonego zainstalowania pliku INF, który odpowiada identyfikatorowi urządzenia złożonego, oraz jawnego załadowania zarówno ogólnego sterownika nadrzędnego USB, jak i sterownika filtrującego.

Obsługa klasy urządzeń bezprzewodowej komunikacji mobilnej

W systemie Windows Vista ogólny sterownik nadrzędny USB (Usbccgp.sys) zapewnia obsługę urządzeń, które są zawarte w klasie urządzeń komunikacyjnych USB (CDC) i klasie bezprzewodowych urządzeń komunikacyjnych USB (WMCDC).

Specyfikacja klasy WMCDC (Wireless Mobile Communication Device Class) USB ustanawia standard połączenia, sterowania i wymiany zawartości między hostem a bezprzewodowym urządzeniem przenośnym (na przykład telefonem komórkowym), gdy urządzenie jest podłączone do portu USB. WMCDC to rozszerzenie klasy urządzeń komunikacyjnych (CDC), które obejmuje szeroką gamę urządzeń komunikacyjnych i sieciowych. W tej sekcji opisano architekturę, która obsługuje urządzenia CDC i WMCDC w systemach operacyjnych Windows.

Urządzenia WMCDC składają się z wielu funkcji pogrupowanych w logiczne zestawy słuchawkowe. Większość urządzeń WMCDC ma jedną logiczną słuchawkę, ale urządzenie może mieć wiele logicznych słuchawek. Logiczne urządzenia zazwyczaj zawierają funkcje, takie jak modem danych/faks, przechowywanie obiektów i funkcja sterowania połączeniami. Logiczny zestaw głośnomówiący może również zawierać funkcje pomocnicze zdefiniowane przez inne specyfikacje USB, takie jak specyfikacja klasy audio USB, specyfikacja klasy HID (Human Input Device) USB i specyfikacja klasy wideo USB.

Architektura usługi Windows WMCDC używa natywnych sterowników systemu Windows do zarządzania funkcjami urządzenia WMCDC. Na przykład można użyć podsystemu interfejsu programu telefonii systemu Windows (TAPI) do zarządzania funkcjami modemu głosowego i danych/faksów urządzenia oraz podsystemu specyfikacji interfejsu sterownika sieciowego systemu Windows (NDIS) do zarządzania funkcją Ethernet LAN urządzenia. Ponadto można zarządzać niektórymi funkcjami, takimi jak funkcja OBEX (Object Exchange Protocol), w oprogramowaniu w trybie użytkownika z pomocą winUSB (Winusb.sys).

Ten obraz przedstawia przykładowy stos sterowników dla urządzenia WMCDC.

Poprzednia figura przedstawia, że urządzenie WMCDC zawiera jeden logiczny zestaw słuchawkowy: funkcję OBEX i funkcję modemu. Plik INF dostarczany przez dostawcę ładuje natywne sterowniki systemu Windows do zarządzania modemem. Funkcja OBEX jest zarządzana przez sterownik trybu użytkownika dostarczony przez dostawcę, który działa w User-Mode Driver Framework (UMDF). Sterownik trybu użytkownika używa protokołu Windows Portable Devices (WPD) do komunikowania się z aplikacjami użytkownika oraz z interfejsem, który Wprowadzenie do WinUSB dla deweloperów eksportuje do komunikacji ze stosem USB. Ogólnie rzecz biorąc, plik INF dostarczony przez dostawcę załaduje oddzielne wystąpienie Winusb.sys dla każdej kolekcji interfejsów, która używa Winusb.sys.

Ustawienia rejestru

Stos USB nie obsługuje automatycznie protokołu WMCDC. Musisz podać plik INF, który ładuje wystąpienie Usbccgp.sys. Plik INF musi zawierać sekcję AddReg , która ustawia wartość rejestru EnumeratorClass w kluczu oprogramowania skojarzonym z Usbccgp.sys wartością REG_BINARY skonstruowaną z trzech liczb: 0x02, 0x00 i 0x 00. Poniższy przykład kodu z przykładowego pliku INF ilustruje sposób ustawiania klasy EnumeratorClass na odpowiednią wartość.

[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

Wartość, którą należy przypisać do klasy EnumeratorClass , jest konstruowana z trzech 1-bajtowych wartości binarnych reprezentowanych w pliku INF przez pary cyfr szesnastkowe: 02, 00 i 00. Te trzy liczby odpowiadają wartościom przypisanym odpowiednio przez forum implementatorów USB do klasy urządzeń CDC, podklasy urządzeń CDC i protokołu urządzenia CDC.

W poniższych tematach opisano więcej informacji dotyczących usługi WMCDC:

Wyliczanie kolekcji interfejsów na platformie WMCDC

Klasa urządzenia komunikacji bezprzewodowej USB (WMCDC) jest podklasą klasy urządzenia komunikacyjnego USB (CDC). Specyfikacja WMCDC rozszerza się, ale nie zmienia znacząco wytycznych cdC dotyczących definiowania kolekcji interfejsów. W szczególności urządzenia WMCDC muszą być zgodne z wytycznymi CDC dotyczącymi definiowania kolekcji interfejsów.

Kolekcje interfejsów CDC zawierają interfejs główny (USB_INTERFACE_DESCRIPTOR), który należy do klasy interfejsu komunikacyjnego (bInterfaceClass = 0x02) lub klasy interfejsu danych (bInterfaceClass = 0x0A). Jeśli interfejs główny należy do klasy interfejsu komunikacyjnego (co jest typową sytuacją), podklasa interfejsu głównego (bInterfaceSubClass) określa model kontrolki CDC. Model sterowania wskazuje typ interfejsów zawartych w kolekcji interfejsów. Opis modeli sterowania definiowanych przez forum implementatorów USB można znaleźć w specyfikacji CDC i specyfikacji WMCDC.

pl-PL: Po głównym interfejsie zbioru interfejsów następuje zestaw obowiązkowych deskryptorów funkcjonalnych specyficznych dla klasy, obejmujący deskryptor funkcjonalny unii (UFD). UfD wyświetla numery interfejsów należących do kolekcji. Pole bMasterInterface UFD zawiera liczbę interfejsu głównego. Zero lub więcej pól bSubordinateInterface zawierają liczby innych (podrzędnych) interfejsów w kolekcji.

W przypadku większości typów modeli sterowania ogólny sterownik nadrzędny USB (Usbccgp.sys) tworzy jeden obiekt urządzenia fizycznego (PDO) dla każdej UFD. Jednak niektóre modele sterowania obejmują interfejs dźwiękowy, który ogólny sterownik nadrzędny enumeruje oddzielnie od zbioru interfejsów, do którego należy interfejs dźwiękowy. Interfejs audio jest wyświetlany na liście interfejsów podrzędnych (bSubordinateInterface) w UFD kolekcji interfejsów, ale ogólny sterownik nadrzędny tworzy oddzielne PDO dla interfejsu audio. Zarówno PDO dla interfejsu audio, jak i PDO dla kolekcji interfejsu, do którego należy interfejs audio, znajdują się bezpośrednio nad funkcjonalnym obiektem urządzenia (FDO) nadrzędnego urządzenia kompozytowego w drzewie obiektów urządzenia. Obiekt PDO interfejsu audio nie jest elementem podrzędnym zbioru interfejsów.

Istnieją dwa modele sterowania, których cechy wyliczenia można skonfigurować w rejestrze: model sterowania słuchawkami bezprzewodowymi (WHCM), który definiuje logiczny zestaw słuchawkowy i model sterowania Object Exchange Protocol (OBEX). Aby skonfigurować charakterystyki wyliczania tych dwóch modeli sterowania, należy podać plik INF, który ładuje wystąpienie Usbccgp.sys i ustawia wartość cdcFlags w kluczu oprogramowania dla tego wystąpienia Usbccgp.sys. W poniższej tabeli opisano opcje konfiguracji usługi CdcFlags.

Aby na przykład wyczyścić oba bity (ustaw je na 0), plik INF powinien mieć następujący wiersz w sekcji DDInstall.AddReg .

HKR, , CdcFlags, 0x00010001, 0x00000000

Aby ustawić oba bity na 1, plik INF powinien mieć następujący wiersz.

HKR, , CdcFlags, 0x00010001, 0x00000011

Aby ustawić zarówno bit 0 na 1, jak i bit od 1 do 0, plik INF powinien mieć następujący wiersz.

HKR, , CdcFlags, 0x00010001, 0x00000001

Każdy z bitów można ustawić lub zresetować niezależnie od pozostałych.

Na poniższych ilustracjach pokazano, jak różne konfiguracje rejestru mogą tworzyć różne drzewa urządzeń dla tego samego urządzenia.

Na poniższej ilustracji przedstawiono konfigurację PDO, gdy bit 0 i bit 1 z CdcFlags mają wartość 0.

Kolekcja interfejsu bezprzewodowego modelu sterowania słuchawkami (WHCM) na powyższej ilustracji zawiera trzy kolekcje interfejsów podrzędnych (bSubordinateInterface): dwie kolekcje OBEX i kolekcję modemów. Bit 0 z CdcFlags jest 0, więc ogólny sterownik nadrzędny USB nie tworzy PDO dla kolekcji interfejsów WHCM. Bit 1 z CdcFlags jest 0, więc ogólny sterownik nadrzędny USB generuje oddzielne PDO dla każdej kolekcji interfejsu OBEX.

Na poniższej ilustracji przedstawiono konfigurację PDO, gdy zostaną ustawione zarówno bit 0, jak i bit 1 CdcFlags.

Ponieważ bit 0 CdcFlags jest ustawiony na 1, ogólny sterownik nadrzędny USB tworzy PDO dla kolekcji interfejsu WHCM. Ponieważ bit 1 z CdcFlags jest ustawiony na 1, uniwersalny sterownik nadrzędny USB grupuje te dwie kolekcje OBEX razem i generuje pojedyncze PDO dla obu kolekcji OBEX.

Możliwe, że zechcesz reprezentować kolekcje OBEX za pomocą pojedynczego elementu PDO na poziomie jądra oraz rozróżniać każdą z poszczególnych kolekcji OBEX w sterowniku trybu użytkownika. Protokół Windows Portable Devices (WPD) może pomóc multipleksować strumienie danych między różnymi funkcjami OBEX na poziomie użytkownika, gdy wszystkie funkcje OBEX są pogrupowane w jeden obiekt PDO na poziomie jądra.

Poniższy przykładowy plik INF ładuje ogólny sterownik nadrzędny USB do zarządzania urządzeniem WMCDC i poleca mu utworzenie obiektów PDO dla logicznych zestawów słuchawkowych oraz pojedynczego obiektu PDO dla wszystkich kolekcji OBEX w logicznym zestawie słuchawkowym.

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

Obsługa kolekcji interfejsów CDC i WMCDC

Ogólny sterownik nadrzędny USB obsługuje bezprzewodowy model sterowania słuchawkami (WHCM) w specjalny sposób.

Poniższa lista zawiera podsumowanie najważniejszych sposobów, w jaki obsługa kolekcji interfejsów CDC i WMCDC różni się od innych kolekcji interfejsów:

• Klasa bezprzewodowego, mobilnego urządzenia komunikacyjnego umożliwia ograniczony poziom zagnieżdżania kolekcji interfejsów. W szczególności kolekcja interfejsu logicznego zestawu słuchawkowego (czyli kolekcja interfejsów WHCM) może zawierać inne kolekcje interfejsów podrzędnych. Na przykład telefon zgodny ze standardem WMCDC może mieć kolekcję interfejsów WHCM, która z kolei zawiera abstrakcyjną kolekcję modelu sterowania i kolekcję OBEX.
• Ogólny sterownik nadrzędny USB można skonfigurować tak, aby nie wyliczał kolekcji interfejsów WHCM. Kolekcje interfejsów WHCM, które nie są wyliczane, pozostają ukryte, ale ogólny sterownik nadrzędny używa informacji z deskryptorów funkcji połączenia (UFD), które należą do kolekcji interfejsów WHCM, aby grupować i wyliczać podrzędne kolekcje interfejsów.
• Można skonfigurować ogólny sterownik nadrzędny USB, aby utworzyć oddzielne obiekty urządzeń fizycznych (PDO) dla kolekcji interfejsów modelu sterowania OBEX lub utworzyć jeden obiekt PDO dla wszystkich kolekcji interfejsów modelu sterowania OBEX.
• Lista numerów interfejsów w UFD może zawierać luki. Oznacza to, że numery interfejsów UFD mogą odnosić się do interfejsów, które nie są ciągłe. Ten typ numeracji jest nieprawidłowy, na przykład dla deskryptora skojarzeń interfejsu USB (IAD), którego interfejsy muszą być ciągłe i mają liczby sekwencyjne.
• Urządzenia UFD mogą zawierać powiązane kolekcje interfejsów audio
• Identyfikatory sprzętu (ID) dla kolekcji interfejsów CDC i WMCDC muszą zawierać podklasę interfejsu. Inne interfejsy USB, których identyfikatory sprzętowe zawierają sufiks MI_%02X określający numer interfejsu, nie zawierają informacji o podklasie interfejsu. Informacje o podklasie są zawarte w identyfikatorze sprzętu, aby umożliwić dostawcom dostarczanie plików INF zgodnych z identyfikatorami sprzętu dla określonych kolekcji interfejsów, zamiast polegać na pozycji interfejsu w układzie deskryptora do ustalenia, który sterownik należy załadować dla kolekcji. Informacje o podklasie w identyfikatorze sprzętu umożliwiają również stopniową ścieżkę migracji z bieżących sterowników dostarczonych przez dostawcę, które zarządzają kolekcjami interfejsów WMCDC do alternatyw, takich jak sterowniki trybu użytkownika. Aby zapoznać się z ogólnym omówieniem sposobu formatowania identyfikatorów sprzętu interfejsu USB, zobacz Identyfikatory urządzeń USB.

Modele sterowania CDC i WMCDC

W sekcji Modele sterowania cdC i WMCDC opisano właściwości kolekcji interfejsów obsługiwanych w systemach operacyjnych Microsoft Windows. Każdy opis zawiera między innymi listę identyfikatorów sprzętu i urządzeń generowanych przez ogólny sterownik nadrzędny USB dla kolekcji interfejsu.

Większość kolekcji interfejsów, które obsługuje system Windows, odpowiadają modelom sterującym należącym do klasy urządzenia komunikacyjnego (CDC) i bezprzewodowej klasy urządzeń komunikacyjnych (WMCDC), ale system operacyjny obsługuje również starsze kolekcje interfejsów audio i wideo oraz kolekcję interfejsów zdefiniowaną przez konsorcjum Mobile Computing Promotion Consortium (MCPC).

Kolekcje interfejsów opisane w tej sekcji są następujące:

Interfejsy klasy audio

Kolekcje interfejsu klasy audio USB, które występują na urządzeniach CDC i WMCDC, mają następujące właściwości.

Model kontroli abstrakcyjnej CDC

Istnieją dwie wersje modelu abstrakcyjnego sterowania (ACM). Oryginalna wersja jest zdefiniowana w specyfikacji USB Communication Device Class (CDC). Specyfikacja klasy bezprzewodowej komunikacji mobilnej USB (WMCDC) zawiera rozszerzoną definicję ACM.

Kolekcje interfejsów zgodne ze specyfikacją WMCDC są opisane na tej stronie.

Kolekcje interfejsów zgodne ze specyfikacją CDC mają następujące właściwości.

Model sterowania sieciami ATM CDC

Kolekcje interfejsów USB CDC ATM Networking Control Model (ANCM) mają następujące właściwości.

Model sterowania CDC CAPI

Kolekcje interfejsu modelu sterowania USB CDC Common ISDN API (CAPI) mają następujące właściwości.

Model sterowania linią bezpośrednią CDC

Kolekcje interfejsu DIRECT Line Model (DLCM) usb CDC mają następujące właściwości.

Model zarządzania siecią Ethernet zgodny z CDC

Kolekcje interfejsu USB CDC Ethernet Networking Control Model (ENCM) mają następujące właściwości.

Model sterowania wielokanałowego ISDN CDC

Kolekcje interfejsów modelu sterowania USB CDC z wieloma kanałami ISDN (MCCM) mają następujące właściwości.

Model sterowania telefonem CDC

Kolekcje interfejsu USB CDC modelu sterowania telefonem (TCM) mają następujące właściwości.

Interfejsy specyficzne dla dostawcy MCPC

Konsorcjum Mobile Computing Promotion Consortium (MCPC) zdefiniowało format kolekcji interfejsów przed udostępnieniem przez specyfikację klasy bezprzewodowej komunikacji mobilnej (WMCDC, Wireless Mobile Communication Device Class) formatu dla urządzeń CDC unikatowych dla dostawców. W związku z tym kolekcje interfejsów MCPC nie są zgodne ze standardem WMCDC.

Jednak ogólny sterownik nadrzędny USB może wyliczać kolekcje interfejsów MCPC, jeśli włączono usługę WMCDC. Kolekcje interfejsów MCPC mają następujące właściwości.

Interfejsy klas wideo (programowania)

Kolekcje interfejsów klasy urządzeń wideo USB, które występują na urządzeniach CDC i WMCDC mają następujące właściwości.

Model abstrakcyjnej kontrolki WMCDC

Istnieją dwie wersje abstrakcyjnego modelu sterowania (ACM). Oryginalna wersja jest zdefiniowana w specyfikacji USB Communication Device Class (CDC). Specyfikacja klasy bezprzewodowej komunikacji mobilnej USB (WMCDC) zawiera rozszerzoną definicję ACM. Kolekcje ACM, które zawierają funkcję faksu/modemu, powinny korzystać z definicji ACM według standardu WMCDC, zamiast oryginalnej definicji ACM według standardu CDC.

Kolekcje interfejsów zgodne ze specyfikacją CDC są opisane na tej stronie.

Kolekcje interfejsów zgodne ze specyfikacją usługi WMCDC mają następujące właściwości.

Model zarządzania urządzeniami WMCDC

Kolekcje interfejsu USB WMCDC device management model (DMM) mają następujące właściwości.

Model bezpośredniej linii mobilnej WMCDC

Kolekcje interfejsów USB WMCDC dla urządzeń przenośnych (MDLM) mają następujące właściwości:

Model sterowania WMCDC OBEX (wiele obiektów PDO)

Istnieją dwa sposoby wyliczania kolekcji interfejsów modelu sterowania protokołu OBEX (Object Exchange Protocol): ogólny sterownik nadrzędny USB może grupować wszystkie interfejsy OBEX razem i utworzyć jeden obiekt urządzenia fizycznego (PDO) dla wszystkich interfejsów OBEX lub sterownik nadrzędny może utworzyć oddzielne pdO dla każdego interfejsu OBEX.

Gdy ogólny sterownik nadrzędny USB przypisuje oddzielne obiekty PDOS do każdego interfejsu OBEX, obiekty PDO mają następujące właściwości.

Model sterowania WMCDC OBEX (pojedynczy PDO)

Istnieją dwa sposoby wyliczania kolekcji interfejsów modelu sterowania protokołu OBEX (Object Exchange Protocol): ogólny sterownik nadrzędny USB może grupować wszystkie interfejsy OBEX razem i utworzyć jeden obiekt urządzenia fizycznego (PDO) dla wszystkich interfejsów OBEX lub sterownik nadrzędny może utworzyć oddzielne pdO dla każdego interfejsu OBEX.

Kiedy ogólny sterownik nadrzędny USB przypisuje jeden obiekt PDO do wszystkich interfejsów OBEX, PDO ma następujące właściwości.

Model sterowania bezprzewodową słuchawką WMCDC

Ogólny sterownik nadrzędny USB nie zawsze wylicza kolekcje interfejsu modelu sterowania bezprzewodowym zestawem słuchawkowym (WHCM). Ustawienia rejestru skojarzone z wystąpieniem ogólnego sterownika nadrzędnego USB, zarządzającego kolekcją interfejsu WHCM, określają, czy ogólny sterownik nadrzędny USB tworzy, czy nie tworzy obiektu urządzenia fizycznego (PDO) dla kolekcji interfejsu. Aby uzyskać wyjaśnienie ustawień rejestru, które określają, jak ogólny sterownik nadrzędny USB wylicza interfejsy WHCM, zobacz Wyliczenie kolekcji interfejsów na urządzeniach złożonych USB.

Wyliczone kolekcje interfejsów WHCM mają następujące właściwości.

Formaty identyfikatorów sprzętu w poprzednich tematach używają następujących konwencji:

• specyfikator formatu printf języka C reprezentuje liczby całkowite. Na przykład "%04x" oznacza 4-cyfrową liczbę całkowitą szesnastkową "%02x" oznacza 2-cyfrową liczbę całkowitą szesnastkową itd.
• Liczba całkowita zgodna z ciągiem "Vid_" to 4-cyfrowa reprezentacja szesnastkowa kodu dostawcy, który komitet USB (<www.usb.org>) przypisuje do dostawcy.
• Liczba całkowita zgodna z ciągiem "Pid_" to 4-cyfrowa reprezentacja szesnastkowa kodu produktu, który dostawca przypisuje do urządzenia.
• Liczba całkowita, która występuje po ciągu "Rev_", to 4-cyfrowa reprezentacja szesnastkowa numeru wersji urządzenia.
• Liczba całkowita zgodna z ciągiem "Cdc_" jest podklasą interfejsu.
• Liczba całkowita zgodna z ciągiem "Prot_" jest numerem protokołu.
• Liczba całkowita zgodna z ciągiem "MI_" to dwucyfrowa reprezentacja szesnastkowa numeru interfejsu, która jest wyodrębniona z pola bInterfaceNumber deskryptora interfejsu.

Wyliczanie kolekcji interfejsów na urządzeniach USB z IADs

Jeśli urządzenie złożone USB ma w swoim oprogramowaniu układowym deskryptor skojarzenia interfejsu (IAD), system Windows wylicza kolekcje interfejsów, traktując każdą z nich jak osobne urządzenie, przypisując do każdej kolekcji jeden obiekt urządzenia fizycznego (PDO) i kojarzy identyfikatory sprzętowe oraz zgodne identyfikatory (ID) z PDO. Aby uzyskać szczegółowy opis deskryptorów interfejsów współdziałania, zobacz Deskryptor interfejsu współdziałania USB. W tej sekcji opisano identyfikatory sprzętu i identyfikatory zgodne przypisane do kolekcji interfejsów skojarzonych z identyfikatorem IAD.

Identyfikatory sprzętowe urządzeń USB z IAD

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

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

W tych identyfikatorach sprzętu

• v(4) to czterocyfrowy kod dostawcy, który komitet USB przypisuje do dostawcy i który jest wyodrębniony z pola idVendor deskryptora urządzenia.
• p(4) to czterocyfrowy kod produktu przypisywany przez dostawcę do urządzenia i wyodrębniony z pola idProduct deskryptora urządzenia.
• r(4) jest czterocyfrowym numerem wydania urządzenia w binarnej zakodowanej poprawce dziesiętnej, którą dostawca przypisuje do urządzenia i który jest wyodrębniony z pola bcdDevice deskryptora urządzenia.
• z(2) to dwucyfrowy numer interfejsu wyodrębniony z pola bFirstInterface IAD.

Kompatybilne identyfikatory urządzeń USB z identyfikatorami IAD

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

USB\Class_c(2)&SubClass_s(2)

USB\Class_c(2)

W tych zgodnych identyfikatorach, c(2), s(2) i p(2) zawierają wartości, które są pobierane odpowiednio z bFunctionClass, bFunctionSubClass i bFunctionProtocol pól IAD.

Nie można używać IAD do rekursywnego wiązania funkcji funkcji. W szczególności, jeśli urządzenie ma deskryptory IAD w swoim oprogramowaniu układowym, ogólny sterownik nadrzędny nie grupuje interfejsów według klasy urządzenia audio, zgodnie z opisem w sekcji Wyliczanie kolekcji interfejsów na urządzeniach złożonych USB.

Wyliczanie kolekcji interfejsów w urządzeniach audio bez IAD

W przypadku urządzeń audio system operacyjny Windows może wyliczać grupy interfejsów (kolekcje interfejsów), które są skojarzone z funkcją i przypisywać pojedynczy obiekt urządzenia fizycznego (PDO) do każdej grupy, nawet jeśli urządzenie nie ma deskryptora skojarzenia interfejsu (IAD).

System operacyjny grupuje interfejsy złożonych urządzeń audio w kolekcje interfejsów, jeśli interfejsy spełniają następujące warunki:

• Wszystkie interfejsy w kolekcji interfejsów muszą być następujące po sobie. Innymi słowy, interfejsy muszą sąsiadować ze sobą w pamięci oprogramowania układowego.
• Wszystkie interfejsy w kolekcji interfejsów muszą należeć do klasy urządzenia audio. Producent urządzenia określa, że interfejs należy do klasy urządzenia audio, przypisując wartość 0x01 do pola bInterfaceClass deskryptora interfejsu.
• Każdy interfejs w kolekcji interfejsów musi mieć inną podklasę od pierwszego interfejsu w kolekcji. Pole bInterfaceSubClass deskryptora interfejsu określa podklasę urządzenia interfejsu.

Jeśli interfejs nie spełnia wszystkich tych trzech warunków, system Windows podejmie próbę wyliczenia go oddzielnie zamiast grupować za pomocą innych interfejsów klasy audio.

System operacyjny nie grupuje interfejsów klasy audio w specjalny sposób, jeśli deskryptor skojarzenia interfejsu (IAD) jest obecny w oprogramowaniu układowym urządzenia. Metoda IAD jest zawsze preferowaną metodą grupowania interfejsów USB.

W tej sekcji opisano sprzętowe i zgodne identyfikatory (ID) powiązane z PDO, które jest utworzone przez system operacyjny dla kolekcji interfejsów, gdzie interfejsy należą do klasy urządzenia audio.

Identyfikatory sprzętowe urządzeń audio bez IAD

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

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

W tych identyfikatorach sprzętu

• v(4) to czterocyfrowy kod dostawcy, który komitet standardów USB przypisuje do dostawcy i który jest wyodrębniony z pola idVendor deskryptora urządzenia.
• p(4) to czterocyfrowy kod produktu przypisywany przez dostawcę do urządzenia i wyodrębniony z pola idProduct deskryptora urządzenia.
• r(4) jest czterocyfrowym numerem wydania urządzenia w binarnej zakodowanej poprawce dziesiętnej, którą dostawca przypisuje do urządzenia i który jest wyodrębniony z pola bcdDevice deskryptora urządzenia.
• z(2) to dwucyfrowy numer interfejsu wyodrębniony z pola bInterfaceNumber deskryptora interfejsu.

Zgodne ID urządzeń audio bez IAD

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

USB\Class_c(2)&SubClass_s(2)

USB\Class_c(2)

W tych zgodnych identyfikatorach, c(2), s(2) i p(2) zawierają wartości, które są pobierane odpowiednio z bInterfaceClass, bInterfaceSubClass i bInterfaceProtocol pól pierwszego deskryptora interfejsu USB w każdej kolekcji interfejsu.

Tematy pokrewne

• Ogólny sterownik nadrzędny USB (Usbccgp.sys)
• sterowniki USB dostarczone przez firmę Microsoft