Drivers de cliente HID de teclado e mouse
Observação
Este tópico é para desenvolvedores que estão criando drivers para clientes HID de teclado e mouse. Se você estiver procurando corrigir um mouse ou teclado, confira:
Este artigo discute drivers de cliente HID de teclado e mouse. Teclados e mouses representam o primeiro conjunto de clientes HID que foram padronizados nas tabelas de uso hid e implementados em sistemas operacionais Windows.
Os drivers de cliente HID de teclado e mouse são implementados na forma de Drivers mapeados hid. Um driver mapeador HID é um driver de filtro WDM no modo kernel que fornece uma interface bidirecional para solicitações de E/S entre um driver de classe não HID e o driver de classe HID. O driver mapeador mapeia as solicitações de E/S e os protocolos de dados de um para o outro.
O Windows fornece drivers de mapeador HID fornecidos pelo sistema para o teclado HID e dispositivos mouse HID.
Arquitetura e visão geral
A figura a seguir ilustra as pilhas de driver fornecidas pelo sistema para dispositivos usb de teclado, mouse e touchpad.
A figura mostra os seguintes componentes:
- KBDHID.sys: driver de mapeador de cliente HID para teclados. Converte os usos de HID em códigos de verificação para interface com o driver de classe de teclado existente.
- MOUHID.sys: driver mapeador de cliente HID para mouses/touchpads. Converte os usos de HID em comandos de mouse (X/Y, botões, roda) para interface com o driver de classe de teclado existente.
- KBDCLASS.sys: o driver de classe de teclado fornece funcionalidade para todos os teclados e teclados no sistema de maneira segura.
- MOUCLASS.sys: o driver de classe do mouse fornece funcionalidade para todos os mouses e touchpads no sistema. O driver dá suporte a dispositivos de apontamento absolutos e relativos. MOUCLASS.sys não é o driver do Windows para telas sensíveis ao toque.
- HIDCLASS.sys: o driver de classe HID. O driver da Classe HID é a cola entre KBDHID.sys e MOUHID.sys clientes HID e vários transportes, como USB, Bluetooth e assim por diante.
O sistema compila 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 cada TLC de teclado ou mouse. Dispositivos HID complexos (mais de um TLC) são expostos como vários PDOs criados pelo driver de classe HID. Por exemplo, um teclado com um mouse integrado pode ter uma coleção para os controles de teclado padrão e uma coleção diferente para o mouse.
- Os drivers de mapeador do cliente HID do teclado ou mouse são carregados no FDO apropriado.
- Os drivers mapeadores HID criam FDOs para teclado e mouse e carregam os drivers de classe.
Observações importantes
- Os drivers de fornecedor não são necessários para teclados e mouses compatíveis com os usos de HID com suporte e coleções de nível superior.
- Opcionalmente, os fornecedores fornecem drivers de filtro na pilha HID para alterar/aprimorar a funcionalidade desses TLC específicos.
- Os fornecedores devem criar TLCs separadas, específicas do fornecedor, para trocar dados proprietários entre o cliente HID e o dispositivo. Evite usar drivers de filtro, a menos que seja crítico.
- O sistema abre todas as coleções de teclado e mouse para seu uso exclusivo.
- O sistema impede desabilitar/habilitar um teclado.
- O sistema fornece suporte para rodas horizontais/verticais com funcionalidades de rolagem suave.
Diretrizes do driver
A Microsoft fornece estas diretrizes para drivers de gravação de IHVs:
Os desenvolvedores de driver têm permissão para adicionar mais drivers na forma de um driver de filtro ou um novo driver de cliente HID.
Drivers de filtros: os desenvolvedores de driver devem garantir que seu driver value-add seja um driver de filtro e não substitua (ou seja usado no lugar de) drivers existentes do Windows HID na pilha de entrada.
- Os drivers de filtro são permitidos nestes cenários:
- Como um filtro superior para kbdhid/mouhid
- Como um filtro superior para kbdclass/mouclass
- Os drivers de filtro não são recomendados como um filtro entre minidrivers de transporte HIDCLASS e HID
- Os drivers de filtro são permitidos nestes cenários:
Drivers de função: como alternativa, os fornecedores podem criar um driver de função (em vez de um driver de filtro), mas apenas para PDOs HID específicos do fornecedor (com um serviço de modo de usuário, se necessário).
Os drivers de função são permitidos nestes cenários:
- Carregar apenas no hardware do fornecedor específico
Motoristas de transporte: a equipe do Windows não recomenda criar mais minidrivers de transporte HID. São drivers complexos para escrever e manter. Se um parceiro estiver criando um minidriver de transporte HID, especialmente em sistemas SoC, recomendamos uma revisão arquitetônica detalhada para entender o raciocínio e garantir que o driver seja desenvolvido corretamente.
Os desenvolvedores de driver devem usar estruturas de driver (KMDF ou UMDF) e não depender do WDM para seus drivers de filtro.
Os desenvolvedores de driver devem reduzir o número de transições kernel-user entre o serviço e a pilha de driver.
Os desenvolvedores de driver devem garantir a capacidade de ativar o sistema por meio da funcionalidade de teclado e touchpad (ajustável pelo usuário final (gerenciador de dispositivos) ou pelo fabricante do computador). Além dos sistemas SoC, esses dispositivos devem ser capazes de se ativar de um estado mais baixo, enquanto o sistema está em um estado S0 em funcionamento.
Os desenvolvedores de driver devem garantir que seu hardware seja gerenciado com eficiência.
- O dispositivo pode entrar em seu estado de energia mais baixo quando o dispositivo está ocioso.
- O dispositivo está no estado de energia mais baixo quando o sistema está em um estado de baixa potência (por exemplo, em espera (S3) ou em espera conectado).
Layout do teclado
Um layout de teclado descreve totalmente as características de entrada de um teclado para o Microsoft Windows 2000 e versões posteriores. Por exemplo, um layout de teclado especifica o idioma, o tipo de teclado e a versão, modificadores, códigos de verificação e assim por diante.
Consulte estes recursos para obter informações sobre layouts de teclado:
Arquivo de cabeçalho do teclado, kdb.h, no DDK (Kit de Desenvolvimento de Driver do Windows), que documenta informações gerais sobre layouts de teclado.
Layouts de teclado de exemplo.
Para visualizar o layout de um teclado específico, consulte Layouts de teclado do Windows.
Para obter mais detalhes sobre o layout do teclado, visite Painel de Controle\Relógio, Idioma e Região\Idioma.
Botões e rodas com suporte em mouses
A tabela a seguir identifica os recursos com suporte em diferentes versões de cliente do sistema operacional Windows.
| Recurso | Windows XP | Windows Vista | Windows 7 | Windows 8 e posterior |
|---|---|---|---|---|
| Botões de 1 a 5 | Com suporte (P/2 & HID) | Com suporte (PS/2 & HID) | Com suporte (PS/2 & HID) | Com suporte (PS/2 & HID) |
| Roda de Rolagem Vertical | Com suporte (PS/2 & HID) | Com suporte (PS/2 & HID) | Com suporte (PS/2 & HID) | Com suporte (PS/2 & HID) |
| Roda de Rolagem Horizontal | Sem suporte | Com suporte (somente HID) | Com suporte (somente HID) | Com suporte (somente HID) |
| Suporte a roda de rolagem suave (horizontal e vertical) | Sem suporte | Parcialmente compatível | Com suporte (somente HID) | Com suporte (somente HID) |
Ativando botões 4-5 e roda em mouses PS/2
O método usado pelo Windows para ativar o novo modo de quatro e cinco botões e roda é uma extensão do método usado para ativar o terceiro botão e a roda em mouses compatíveis com IntelliMouse:
O mouse é definido como o modo de roda de três botões definindo a taxa de relatório como 200 relatórios por segundo e, em seguida, para 100 relatórios por segundo e, em seguida, para 80 relatórios por segundo. Em seguida, lendo a ID do mouse. O mouse deve relatar uma ID de 3 quando essa sequência for concluída.
Em seguida, o mouse é definido como o modo de roda de cinco botões definindo a taxa de relatório como 200 relatórios por segundo e, em seguida, para 200 relatórios por segundo novamente e, em seguida, para 80 relatórios por segundo. Em seguida, lendo a ID do mouse. Depois que a sequência for concluída, um mouse de roda de cinco botões deverá relatar uma ID de 4 (enquanto um mouse de roda de três botões compatível com IntelliMouse ainda relataria uma ID de 3).
Esse método é aplicável somente a mouses PS/2, não a ratos HID. Os mouses hid devem relatar usos precisos em seu descritor de relatório.
Formato de pacote de dados de mouse compatível com PS/2 padrão (dois botões)
| Byte | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | Comentário |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Yover | Xover | Ysign | Xsign | Marca | M | R | L | Estouros e sinais X/Y, botões |
| 2 | X7 | X6 | X5 | X4 | X3 | X2 | X1 | X0 | Byte de dados X |
| 3 | Y7 | Y6 | S5 | Y4 | S3 | S2 | S1 | Y0 | Bytes de dados Y |
Observação
Os drivers de mouse do Windows não marcar os bits de estouro. Em caso de estouro, o mouse deve simplesmente enviar o valor máximo de deslocamento assinado.
Formato de pacote de dados do mouse compatível com PS/2 padrão (três botões + roda vertical)
| Byte | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | Comentário |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 0 | Ysign | Xsign | 1 | M | R | L | Sinais X/Y e botões R/L/M |
| 2 | X7 | X6 | X5 | X4 | X3 | X2 | X1 | X0 | Byte de dados X |
| 3 | Y7 | Y6 | S5 | Y4 | S3 | S2 | S1 | Y0 | Bytes de dados Y |
| 4 | Z7 | Z6 | Z5 | Z4 | Z3 | Z2 | Z1 | Z0 | Byte de dados Z/wheel |
Formato de pacote de dados do mouse compatível com PS/2 padrão (cinco botões + roda vertical)
| Byte | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | Comentário |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 0 | Ysign | Xsign | 1 | M | R | L | Sinais X/Y e botões R/L/M |
| 2 | X7 | X6 | X5 | X4 | X3 | X2 | X1 | X0 | Byte de dados X |
| 3 | Y7 | Y6 | S5 | Y4 | S3 | S2 | S1 | Y0 | Bytes de dados Y |
| 4 | 0 | 0 | B5 | B4 | Z3 | Z2 | Z1 | Z0 | Dados e botões Z/wheel 4 e 5 |
Importante
Observe que os dados Z/wheel de um mouse de roda de cinco botões foram reduzidos para quatro bits em vez dos 8 bits usados no modo de roda de três botões compatível com IntelliMouse. Essa redução é possível pelo fato de que a roda normalmente não pode gerar valores além do intervalo +7/-8 durante um determinado período de interrupção. Os drivers de mouse do Windows assinarão estender os quatro bits de dados Z/roda quando o mouse estiver no modo de roda de cinco botões e o byte completo de dados Z/roda quando o mouse operar no modo de roda de três botões.
Os botões 4 & 5 ativados são mapeados para WM_APPCOMMAND mensagens e correspondem a App_Back e App_Forward.
Dispositivos que não exigem drivers de fornecedor
Os drivers de fornecedor não são necessários para os seguintes dispositivos:
- Dispositivos que estão em conformidade com o HID Standard.
- Dispositivos de teclado, mouse ou porta de jogo operados pelos drivers não HIDClass fornecidos pelo sistema.
Exemplo de Kbfiltr
Kbfiltr é usado com kbdclass, o driver de classe do sistema para dispositivos de teclado e I8042prt, o driver de função para um teclado de estilo PS/2. Kbfiltr demonstra como filtrar solicitações de E/S e como adicionar rotinas de retorno de chamada que modificam a operação de Kbdclass e I8042prt.
Para obter mais informações sobre a operação Kbfiltr, consulte:
O arquivo de cabeçalho WDK ntddkbd.h .
O código-fonte Kbfiltr de exemplo.
Códigos de controle de E/S do Kbfiltr
Os IOCTLs a seguir são usados por Kbfiltr.
IOCTL_INTERNAL_I8042_HOOK_KEYBOARD
A solicitação IOCTL_INTERNAL_I8042_HOOK_KEYBOARD:
- Adiciona uma rotina de retorno de chamada de inicialização à rotina de inicialização de teclado I8042prt.
- Adiciona uma rotina de retorno de chamada ISR ao ISR do teclado I8042prt.
A inicialização e os retornos de chamada ISR são opcionais e são fornecidos por um driver de filtro de nível superior para um dispositivo de teclado no estilo PS/2.
Depois que o I8042prt recebe uma solicitação IOCTL_INTERNAL_KEYBOARD_CONNECT , ele envia uma solicitação de IOCTL_INTERNAL_I8042_HOOK_KEYBOARD síncrona para a parte superior da pilha de dispositivos de teclado.
Depois que kbfiltr recebe a solicitação de teclado gancho, Kbfiltr filtra a solicitação da seguinte maneira:
- Salva as informações de nível superior passadas para Kbfiltr, que inclui o contexto de um objeto de dispositivo de nível superior, um ponteiro para um retorno de chamada de inicialização e um ponteiro para um retorno de chamada ISR.
- Substitui as informações de nível superior por suas próprias.
- Salva o contexto de I8042prt e ponteiros para retornos de chamada que o retorno de chamada ISR do Kbfiltr pode usar.
IOCTL_INTERNAL_KEYBOARD_CONNECT
A solicitação IOCTL_INTERNAL_KEYBOARD_CONNECT conecta o serviço Kbdclass ao dispositivo de teclado. O Kbdclass envia essa solicitação para baixo na pilha do dispositivo de teclado antes de abrir o dispositivo de teclado.
Depois que kbfiltr recebeu a solicitação de conexão de teclado, Kbfiltr filtra a solicitação de conexão da seguinte maneira:
- Salva uma cópia da estrutura de CONNECT_DATA (Kbdclass) da Kbdclass que é passada para o driver de filtro por Kbdclass.
- Substitui suas próprias informações de conexão para as informações de conexão do driver de classe.
- Envia a solicitação IOCTL_INTERNAL_KEYBOARD_CONNECT para baixo na pilha do dispositivo.
Se a solicitação não for bem-sucedida, kbfiltr concluirá a solicitação com um erro apropriado status.
O Kbfiltr fornece um modelo para uma rotina de retorno de chamada de serviço de filtro que pode complementar a operação de KeyboardClassServiceCallback, a rotina de retorno de chamada do serviço de classe Kbdclass. O retorno de chamada do serviço de filtro pode filtrar os dados de entrada transferidos do buffer de entrada do dispositivo para a fila de dados de classe.
IOCTL_INTERNAL_KEYBOARD_DISCONNECT
A solicitação de IOCTL_INTERNAL_KEYBOARD_DISCONNECT é concluída com um status de STATUS_NOT_IMPLEMENTED. O gerenciador de Plug and Play pode adicionar ou remover um teclado Plug and Play.
Para todas as outras solicitações de controle de dispositivo, o Kbfiltr ignora a pilha IRP atual e envia a solicitação para baixo na pilha do dispositivo sem processamento adicional.
Rotinas de retorno de chamada implementadas pelo Kbfiltr
O Kbfiltr implementa as seguintes rotinas de retorno de chamada.
KbFilter_InitializationRoutine
Consulte PI8042_KEYBOARD_INITIALIZATION_ROUTINE
O KbFilter_InitializationRoutine não será necessário se a inicialização padrão I8042prt de um teclado for suficiente.
Chamadas I8042prt KbFilter_InitializationRoutine quando inicializa o teclado. A inicialização de teclado padrão inclui as seguintes operações:
- redefinir o teclado
- definir a taxa tipática e o atraso
- definir os diodos emissores de luz (LED)
/*
Parameters
DeviceObject [in]
Pointer to the device object that is the context for this callback.
SynchFuncContext [in]
Pointer to the context for the routines pointed to by ReadPort and Writeport.
ReadPort [in]
Pointer to the system-supplied PI8042_SYNCH_READ_PORT callback that reads from the port.
WritePort [in]
Pointer to the system-supplied PI8042_SYNCH_WRITE_PORT callback that writes to the port.
TurnTranslationOn [out]
Specifies, if TRUE, to turn translation on. Otherwise, translation is turned off.
Return value
KbFilter_InitializationRoutine returns an appropriate NTSTATUS code.
*/
NTSTATUS KbFilter_InitializationRoutine(
In PDEVICE_OBJECT DeviceObject,
In PVOID SynchFuncContext,
In PI8042_SYNCH_READ_PORT ReadPort,
In PI8042_SYNCH_WRITE_PORT WritePort,
Out PBOOLEAN TurnTranslationOn
);
KbFilter_IsrHook
Consulte PI8042_KEYBOARD_ISR. Esse retorno de chamada não será necessário se a operação padrão do I8042prt for suficiente.
O ISR do teclado I8042prt chama KbFilter_IsrHook depois de validar a interrupção e ler o código de verificação.
KbFilter_IsrHook é executado no modo kernel no IRQL do teclado I8042prt.
/*
Parameters
DeviceObject [in]
Pointer to the filter device object of the driver that supplies this callback.
CurrentInput [in]
Pointer to the input KEYBOARD_INPUT_DATA structure that is being constructed by the ISR.
CurrentOutput [in]
Pointer to an OUTPUT_PACKET structure that specifies the bytes that are being written to the hardware device.
StatusByte [in, out]
Specifies the status byte that is read from I/O port 60 when an interrupt occurs.
DataByte [in]
Specifies the data byte that is read from I/O port 64 when an interrupt occurs.
ContinueProcessing [out]
Specifies, if TRUE, to continue processing in the I8042prt keyboard ISR after this callback returns; otherwise, processing is not continued.
ScanState [in]
Pointer to a KEYBOARD_SCAN_STATE structure that specifies the keyboard scan state.
Return value
KbFilter_IsrHook returns TRUE if the interrupt service routine should continue; otherwise it returns FALSE.
*/
KbFilter_IsrHook KbFilter_IsrHook(
In PDEVICE_OBJECT DeviceObject,
In PKEYBOARD_INPUT_DATA CurrentInput,
In POUTPUT_PACKET CurrentOutput,
Inout UCHAR StatusByte,
In PUCHAR DataByte,
Out PBOOLEAN ContinueProcessing,
In PKEYBOARD_SCAN_STATE ScanState
);
KbFilter_ServiceCallback
Veja PSERVICE_CALLBACK_ROUTINE.
A rotina de conclusão de expedição isr do driver de função chama KbFilter_ServiceCallback, que, em seguida, chama a implementação do driver de classe de teclado de PSERVICE_CALLBACK_ROUTINE. Um fornecedor pode implementar um retorno de chamada de serviço de filtro para modificar os dados de entrada transferidos do buffer de entrada do dispositivo para a fila de dados de classe. Por exemplo, o retorno de chamada pode excluir, transformar ou inserir dados.
/*
Parameters
DeviceObject [in]
Pointer to the class device object.
InputDataStart [in]
Pointer to the first keyboard input data packet in the input data buffer of the port device.
InputDataEnd [in]
Pointer to the keyboard input data packet that immediately follows the last data packet in the input data buffer of the port device.
InputDataConsumed [in, out]
Pointer to the number of keyboard input data packets that are transferred by the routine.
Return value
None
*/
VOID KbFilter_ServiceCallback(
In PDEVICE_OBJECT DeviceObject,
In PKEYBOARD_INPUT_DATA InputDataStart,
In PKEYBOARD_INPUT_DATA InputDataEnd,
Inout PULONG InputDataConsumed
);
Exemplo de Moufiltr
O Moufiltr é usado com o Mouclass, o driver de classe do sistema para dispositivos mouse usados com o Windows 2000 e versões posteriores, e o I8042prt, o driver de função para um mouse no estilo PS/2 usado com o Windows 2000 e posterior. Moufiltr demonstra como filtrar solicitações de E/S e adicionar rotinas de retorno de chamada que modificam a operação de Mouclass e I8042prt.
Para obter mais informações sobre a operação Moufiltr, consulte estes recursos:
O arquivo de cabeçalho WDK ntddmou.h .
O código-fonte Moufiltr de exemplo .
Códigos de controle de E/S Moufiltr
Os IOCTLs a seguir são usados por Moufiltr.
IOCTL_INTERNAL_I8042_HOOK_MOUSE
A solicitação IOCTL_INTERNAL_I8042_HOOK_MOUSE adiciona uma rotina de retorno de chamada ISR ao ISR do mouse I8042prt. O retorno de chamada ISR é opcional e é fornecido por um driver de filtro de mouse de nível superior.
O I8042prt envia essa solicitação depois de receber uma solicitação de IOCTL_INTERNAL_MOUSE_CONNECT . O I8042prt envia uma solicitação de IOCTL_INTERNAL_I8042_HOOK_MOUSE síncrona para a parte superior da pilha de dispositivos do mouse.
Depois que moufiltr recebe a solicitação do mouse gancho, ele filtra a solicitação da seguinte maneira:
- Salva as informações de nível superior passadas para Moufiltr, que inclui o contexto de um objeto de dispositivo de nível superior e um ponteiro para um retorno de chamada ISR.
- Substitui as informações de nível superior por suas próprias.
- Salva o contexto de I8042prt e ponteiros para retornos de chamada que os retornos de chamada ISR do Moufiltr podem usar.
IOCTL_INTERNAL_MOUSE_CONNECT
A solicitação IOCTL_INTERNAL_MOUSE_CONNECT conecta o serviço Mouclass a um dispositivo mouse.
IOCTL_INTERNAL_MOUSE_DISCONNECT
Moufiltr conclui a solicitação de IOCTL_INTERNAL_MOUSE_DISCONNECT com um erro status de STATUS_NOT_IMPLEMENTED.
Para todas as outras solicitações, o Moufiltr ignora a pilha IRP atual e envia a solicitação para baixo na pilha do dispositivo sem processamento adicional.
Rotinas de retorno de chamada Moufiltr
As rotinas de retorno de chamada a seguir são implementadas pelo MouFiltr.
MouFilter_IsrHook
Consulte PI8042_MOUSE_ISR.
/*
Parameters
DeviceObject
Pointer to the filter device object of the driver that supplies this callback.
CurrentInput
Pointer to the input MOUSE_INPUT_DATA structure being constructed by the ISR.
CurrentOutput
Pointer to the OUTPUT_PACKET structure that specifies the bytes being written to the hardware device.
StatusByte
Specifies a status byte that is read from I/O port 60 when the interrupt occurs.
DataByte
Specifies a data byte that is read from I/O port 64 when the interrupt occurs.
ContinueProcessing
Specifies, if TRUE, that the I8042prt mouse ISR continues processing after this callback returns. Otherwise, processing is not continued.
MouseState
Pointer to a MOUSE_STATE enumeration value, which identifies the state of mouse input.
ResetSubState
Pointer to MOUSE_RESET_SUBSTATE enumeration value, which identifies the mouse reset substate. See the Remarks section.
Return value
MouFilter_IsrHook returns TRUE if the interrupt service routine should continue; otherwise it returns FALSE.
*/
BOOLEAN MouFilter_IsrHook(
PDEVICE_OBJECT DeviceObject,
PMOUSE_INPUT_DATA CurrentInput,
POUTPUT_PACKET CurrentOutput,
UCHAR StatusByte,
PUCHAR DataByte,
PBOOLEAN ContinueProcessing,
PMOUSE_STATE MouseState,
PMOUSE_RESET_SUBSTATE ResetSubState
);
Um retorno de chamada MouFilter_IsrHook não será necessário se a operação padrão do I8042prt for suficiente.
O ISR do mouse I8042prt chama MouFilter_IsrHook depois de validar a interrupção.
Para redefinir um mouse, i8042prt passa por uma sequência de subestados operacionais. Um valor de enumeração MOUSE_RESET_SUBSTATE identifica cada subestado. Para obter mais informações sobre como o I8042prt redefine um mouse e os subestados de redefinição de mouse correspondentes, consulte a documentação de MOUSE_RESET_SUBSTATE em ntdd8042.h.
MouFilter_IsrHook é executado no modo kernel no IRQL do ISR do mouse I8042prt.
MouFilter_ServiceCallback
Consulte PSERVICE_CALLBACK_ROUTINE
/*
Parameters
DeviceObject [in]
Pointer to the class device object.
InputDataStart [in]
Pointer to the first mouse input data packet in the input data buffer of the port device.
InputDataEnd [in]
Pointer to the mouse input data packet immediately following the last data packet in the port device's input data buffer.
InputDataConsumed [in, out]
Pointer to the number of mouse input data packets that are transferred by the routine.
Return value
None
*/
VOID MouFilter_ServiceCallback(
_In_ PDEVICE_OBJECT DeviceObject,
_In_ PMOUSE_INPUT_DATA InputDataStart,
_In_ PMOUSE_INPUT_DATA InputDataEnd,
_Inout_ PULONG InputDataConsumed
);
O ISR DPC de I8042prt chama MouFilter_ServiceCallback, que chama MouseClassServiceCallback. Um retorno de chamada do serviço de filtro pode ser configurado para modificar os dados de entrada transferidos do buffer de entrada do dispositivo para a fila de dados de classe. Por exemplo, o retorno de chamada pode excluir, transformar ou inserir dados.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de