Compartilhar via

Usando WinUSB em um driver WBDI

  • Artigo

A Microsoft recomenda que os drivers WBDI usem o destino de E/S USB que está incorporado no UMDF (User-Mode Driver Framework).

Configurando o UmdfDispatcher

Um arquivo INF que instala um driver UMDF deve conter uma seção DDInstall específica do WDF. Se você usar o destino de E/S USB no UMDF, deverá definir a diretiva do Registro UmdfDispatcher nesta seção DDInstall .

A seção a seguir de WudfBioUsbSample.inx no exemplo WudfBioUsbSample mostra como definir essa diretiva:

[Biometric_Install.NT.Wdf]
KmdfService=WINUSB, WinUsb_Install
UmdfDispatcher=WinUsb
UmdfService=WudfBioUsbSample, WudfBioUsbSample_Install
UmdfServiceOrder=WudfBioUsbSample

Para obter informações específicas sobre o UmdfDispatcher, consulte Especificando a diretiva INF do UmdfDispatcher. Para obter informações gerais sobre diretivas do Registro WDF, consulte Especificando diretivas WDF.

Solicitações de leitura assíncronas pendentes

WinUsb pode lidar com várias solicitações de leitura pendentes. Os dispositivos que exigem latência mínima entre as operações de leitura durante uma varredura devem manter algum número de solicitações de leitura assíncronas pendentes pendentes. Se o driver fizer solicitações assíncronas, o WinUsb emitirá essas solicitações antes da transferência de volta ao modo de usuário para as rotinas de conclusão de solicitações de leitura anteriores.

Você pode consultar o CBiometricDevice::InitiatePendingRead método em Device.cpp em WudfBioUsbSample para ver um exemplo de código de como pender uma solicitação de leitura.

O código para pender uma solicitação de leitura deve ser um loop das seguintes etapas:

  1. Crie um objeto de memória de estrutura pré-alocado chamando IWDFDriver::CreatePreallocatedWdfMemory.

  2. Forneça código de retorno de chamada em uma rotina OnComplete . Veja CBiometricDevice::OnCompletion no exemplo.

  3. Adquira um ponteiro para a interface IRequestCallbackRequestCompletion do objeto proprietário.

  4. Registre a função de retorno de chamada chamando IWDFIoRequest::SetCompletionCallback e passando o ponteiro para IRequestCallbackRequestCompletion que foi obtido na etapa anterior. A estrutura agora chamará o retorno de chamada quando uma solicitação de E/S for concluída.

  5. Chame IWDFIoRequest::Send para enviar a solicitação de leitura para o dispositivo.

  6. Processar a solicitação de leitura quando ocorrer a conclusão do retorno de chamada. Antes que a rotina OnCompletion inicie uma nova solicitação de leitura pendente, ela deve verificar o estado do destino de E/S. Para fazer isso, consulte IWDFUsbTargetPipe para obter um ponteiro para sua interface IWDFIoTargetStateManagement . Em seguida, chame IWDFIoTargetStateManagement::GetState:

    IWDFIoTarget * pTarget
IWDFIoTargetStateManagement * pStateMgmt = NULL;
WDF_IO_TARGET_STATE state;

HRESULT hrQI = pTarget->QueryInterface(IID_PPV_ARGS(&pStateMgmt));
WUDF_TEST_DRIVER_ASSERT((SUCCEEDED(hrQI) && pStateMgmt));

state = pStateMgmt->GetState();

Quando a verificação estiver concluída, cancele todas as solicitações de leitura pendentes.

Se você usar o destino UMDF-USB, poderá permitir que as solicitações de leitura permaneçam pendentes durante a desativação e a inicialização.

Se você não usar o destino UMDF-USB, o driver deve parar de enviar solicitações de leitura pendentes em D0Exit e reiniciar em D0Entry.

Suspensão seletiva

Um driver WBDI deve suportar suspensão seletiva USB.

Um dispositivo que ofereça suporte à ativação do sistema e à ociosidade do dispositivo deve habilitar as configurações do Registro para suspensão seletiva no WinUsb, conforme mostrado neste exemplo de código de WudfBioUsbSample.inx:

HKR,,"SystemWakeEnabled",0x00010001,1
HKR,,"DeviceIdleEnabled",0x00010001,1

A pilha USB do sistema operacional não pode garantir o tempo entre a ativação do sistema e quando o driver pode começar a ler a partir do dispositivo.

Idealmente, o dispositivo deve ser deixado em um estado pronto para capturar uma varredura quando o sistema é suspenso. Se ocorrer uma varredura enquanto o sistema estiver suspenso, o dispositivo deverá armazenar em cache os dados de entrada para uma verificação de impressão digital inteira. Quando o sistema é ativado, o motorista lê os dados do dispositivo. Ao oferecer suporte a esse cenário, você pode habilitar cenários de ativação e desbloqueio/login do sistema.