Compartilhar via


Drivers de cliente HID

Se um minidriver HID fornecido pelo sistema não der suporte à porta ou ao barramento de um dispositivo, um minidriver fornecido pelo fornecedor será necessário.

A figura a seguir ilustra uma pilha de driver para um dispositivo HIDClass genérico (que pode usar componentes opcionais e necessários fornecidos pelo fornecedor).

diagrama ilustrando uma pilha de driver para um dispositivo hidclass genérico.

O Windows cria a pilha de driver da seguinte maneira:

  • A pilha de transporte cria um PDO (objeto de dispositivo físico) para cada dispositivo HID anexado e carrega o driver de transporte HID apropriado que, por sua vez, carrega o Driver de Classe HID.
  • O driver de classe HID cria um PDO para o TLC . Para dispositivos complexos com vários TLC, o driver de classe HID cria um PDO para cada TLC e garante que a ID de hardware associada ao TLC inclua um identificador para representar cada objeto de dispositivo.
  • Uma função fornecida pelo fornecedor ou um driver de filtro cria um FDO ou um FILTRO DO para uma coleção HID.
  • Como alternativa, um aplicativo fornecido pelo fornecedor pode abrir o dispositivo usando APIs SetupDI* para identificar o dispositivo e, em seguida, rotinas compatíveis com HID para se comunicar com o dispositivo. Esses dispositivos são considerados abertos no modo RAW.

Se as Operações do Minidriver fornecidas pelo sistema não derem suporte a um dispositivo, um minidriver HID fornecido pelo fornecedor será necessário. Você pode implementar esse minidriver de duas maneiras:

  • Driver de cliente HID
  • O aplicativo acessa o HID diretamente

Se um fornecedor fornecer um driver (diferente de um minidriver), esse driver:

  • Deve estar em conformidade com os requisitos mínimos no driver do Windows. Idealmente, isso deve ser baseado na UMDF (estrutura de driver de modo de usuário) ou na estrutura de driver do modo kernel (KMDF). Uma solução menos ideal é criar um driver de função WDM, conforme descrito em Modelo de Driver do Windows.
  • Normalmente dá suporte a uma interface de dispositivo definida pelo fornecedor – consulte Classes de interface do dispositivo. Drivers de nível superior ou aplicativos de modo de usuário usam a interface personalizada para acessar os dispositivos que o driver do fornecedor opera. A interface personalizada pode adicionar funcionalidade ou, talvez, simplificar a interface para o driver de classe HID.

Se o driver não for um driver de função ou driver de filtro, ele poderá usar Plug and Play notificação para localizar coleções HID. Depois de localizar uma coleção, o driver abre a coleção e a opera da mesma maneira que um driver de função ou filtro.

Observação importante:

  • Se um driver de função fornecido pelo fornecedor criar um FDO ou filtrar DO para uma coleção HID, ele não deverá usar o campo FsContext de FILE_OBJECT para armazenar dados específicos do objeto de arquivo. O campo FsContext é reservado para o driver de classe HID. Se outro driver na pilha precisar armazenar dados de contexto específicos do objeto de arquivo, ele deverá usar o campo FsContext2.
  • Se houver vários dispositivos anexados ao PDO, não haverá mecanismo interno para determinar qual dispositivo pode usar o campo FsContext2.